Manual Modelamiento de Datos - UML PDF

Facultad de Ingeniera Industrial y de Sistemas
CAPITULO 1
Introduccin al Anlisis y Diseo Orientado a Objetos.
Ciclo de Vida del Software.
Proceso de desarrollo utilizando UML.
Descripcin del Proceso Actual: El Modelo de Negocios.
Modelamiento de Datos Pg. 1

Universidad Nacional de Ingeniera
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 trminos POO, AOO, DOO, BDOO.
Existen evidencias de que la industria informtica est dirigindose en conjunto a la
Tecnologa Orientada a Objetos, alejndose de la tecnologa estructurada que ha
prevalecido por ms de 20 aos. A todo esto le aadimos la proyeccin del desarrollo
de aplicaciones para Internet, denominados Intranets, Extranets y otros, usando
justamente esta tecnologa.
La Tecnologa Orientada a Objetos es un nuevo enfoque sobre la manera de organizar

las diferentes piezas que componen un sistema de informacin (software), como en el
hardware (equipo fsico), la base de datos e incluso, en organizaciones todas estas
piezas se denominan "objetos", los cuales son pequeos subsistemas independientes
con datos propios sobre estos elementos y sus clases y tipos, rigen tales propiedades
como herencia, comunicacin con lenguajes, polimorfismos y otros que en conjunto
permiten ventajas prcticas.
Estas estn incluidas en las versiones orientadas a objetos de metodologa para

anlisis y diseo de programacin y base de datos. Con esto, nos hemos referido a la
tecnologa orientada a objetos aplicada a software. Sin embargo este enfoque tambin
es aplicado en la construccin de hardware, as como tambin es vlido en el diseo
organizativo.
La TOO se fundamenta en el proceso de construccin y utilizacin de conocimientos,

por lo tanto, objetos y clases son los pasos ms importantes en la bsqueda de una
nueva revolucin que reemplace, esta vez, parte del esfuerzo que implica la
organizacin y utilizacin del conocimiento, del mismo modo que en la primera, las
mquinas reemplazaron el esfuerzo fsico del hombre y de los animales, permitiendo el
vertiginoso avance del mundo.
El Desarrollo de la Estructura del Pensamiento y la

Construccin del Conocimiento
Desde muy temprana edad, aproximadamente hasta los siete aos, en los
denominados perodos Senso-motriz y Preparatorio de la inteligencia, en los que se
afirma el esquema del objeto permanente, los seres humanos, a partir de la
experiencia de la observacin y captacin de cosas y hechos del mundo que nos
rodea, construimos conceptos "concretos". Estos nos permiten ser consistentes y
razonar. Por ejemplo: Pelusa es un elemento del mundo real que es conceptualizado
como Pelusa. En l almacenamos sus caractersticas (DATOS), por ejemplo: tiene
pelos, cuatro patas, dos orejas, dos aos de edad, es de color blanco, otros. Junto con
los datos tambin almacenamos sus acciones (COMPORTAMIENTO), es decir, lo que
puede o no hacer (ladrar, correr, saltar, comer, etc.). Como consecuencia de este
hecho (almacenamiento de los datos y comportamiento en una sola unidad
conceptual), entre las muchas operaciones de nuestra mente, podemos razonar que
Pelusa no tiene alas, ni plumas, ni puede volar.
Pg. 2 Modelamiento de Datos

A las acciones que, cualquier elemento del mundo real, realiza como reaccin frente a
un estmulo las denominaremos Operaciones. Algunos comportamientos complejos
son el resultado de la interaccin o sucesin de varias operaciones, a stos los
denominaremos Procesos. Sin embargo en nuestro enfoque, en la mayora de los
casos y de manera genrica utilizaremos el trmino OPERACION.
Los conceptos se construyen modelando los aspectos y caractersticas de cualquier

objeto real, extrayendo los detalles (datos y comportamiento) necesarios y
descartando lo menos til. Este proceso, natural en los seres humanos, compuesto por
diversas operaciones tales como observar, captar, fijar, comparar, conceptualizar y
otros son denominados abstraccin.
Cuando pensamos en un auto, no visualizamos cada mnimo detalle que lo describa,

lo ms probable es que tengamos en mente slo las principales caractersticas fsicas
y, dependiendo de nuestra experiencia, algunos de los subsistemas importantes como
la caja de cambios, o los sistemas de direccin y frenos.
En Tecnologa Orientado a Objetos (TO) a los conceptos se les llama objetos, en

consecuencia, los OBJETOS son MODELOS de entes del mundo real. Los percibimos
porque tienen lmites que los esperan de su medio ambiente y de los dems
(IDENTIDAD). Se encuentran en un ESTADO especfico 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 organizacin

Una figura en un programa para dibujar
Una pantalla con la cual el usuario interacta
Un campo o nodo en la pantalla de una herramienta CASE
Un avin, el vuelo de un avin, una reserva de avin
Un icono en la pantalla, a la que se puede sealar y abrir
Continuando con el desarrollo de la estructura del pensamiento, encontraremos que

aproximadamente a partir de los siete aos, en la denominada etapa de las
operaciones concretas, el ser humano aprende a CLASIFICAR (separar y agrupar
objetos de acuerdo a caractersticas y comportamientos comunes) y ORDENAR
(establecer criterios de jerarqua que permitan la organizacin).
Por ejemplo: conocemos a Pluto y Valentino, y descubrimos que tambin tienen cuatro
patas, ladran, muerden, etc. Y a partir de estos conceptos "concretos" formamos un
nuevo concepto "abstracto" al que denominamos PERRO. Este contiene las
caractersticas y el comportamiento de todos los semejantes a Pelusa. En otras
palabras, construimos conceptos tipos o Modelos.
As construiremos los modelos GATO, CONEJO, y an sin la experiencia directa de la

observacin, TIGRE, ORNITORRINCO, etc. Este proceso es una consecuencia de la
funcin simblica (imitacin diferida, juegos simblicos, etc.).

De estos modelos se construirn otros, cada vez ms abstractos, que contendrn a los
anteriores, por ejemplo: CARNIVOROS, MAMIFEROS, VERTEBRADOS, ANIMALES,
SERES VIVOS, etc. generndose una estructura muy organizada de CLASIFICACION
Y ORDEN.
La clasificacin es un medio por el cual organizamos el

conocimiento.
Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemas

representativos (MODELOS), los cuales permiten: por un lado, reconocer si un
concepto (OBJETO) tiene o no las caractersticas de dicho esquema; y por otro,
incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE).
Posteriormente organizamos jerrquicamente en clases y superclases, construyendo
en forma progresiva las grandes CLASIFICACIONES y las OPERACIONES DE
ORDEN.
Despus de los doce aos, en la etapa de las Operaciones combinatorias de la

inteligencia (Pensamiento formal), el hombre construye SISTEMAS y an TEORIAS
como producto del raciocinio de Hiptesis (propuestas de solucin a interrogantes o
problemas), y de la representacin en dimensiones simultneas.
Un Sistema es un conjunto de componentes (conceptos y modelos, y an de otros

sistemas) que interactan, en distintos planos, entre s para alcanzar objetivos
especficos. Cada Sistema construido es una manera de solucionar los diferentes
problemas que enfrenta el hombre a lo largo de su existencia, por ejemplo el Lenguaje,
uno de los sistemas ms elaborados, permite satisfacer la necesidad vital de la
comunicacin.
Cuando un sistema tiene por objetivo explicar un hecho o fenmeno, y es aceptado,

mientras no se demuestre lo contrario, u otro sistema lo explique mejor, se le
denomina TEORIA. Por ejemplo, la teora de la relatividad, la teora del conocimiento,
etc.
En sntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en

que los seres humanos captamos el mundo real y operamos en l. La tecnologa de
Objetos intenta simular este hecho y sus fundamentos se sostienen en l.
A continuacin desarrollaremos los tres ms importantes:
SIMULACIN.
Representacin 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 de
representarlo directamente. Por ello, en este enfoque, primero se identifican las
caractersticas de los elementos del mundo real, los que se organizan en las
denominadas ESTRUCTURAS DE DATOS. Luego se captan los comportamientos u
operaciones, los cuales se imitan o simulan mediante pequeos programas
(procedimientos) a los que en adelante denominaremos METODOS. Y as como en la
vida real conceptualizamos en una sola unidad (datos y comportamiento), en TO

simulamos este hecho colocando en una especie de "cpsula" las estructuras de datos
y los mtodos, a esta unidad denominamos OBJETO.
Tambin se simula la manera en que los entes del mundo real se comunican entre s,
envindose seales o "mensajes" a los que responden con una conducta o
comportamiento especfico, de la misma manera se simulan las clasificaciones,
ordenamiento, organizacin, e incluso la herencia de los seres vivos.
En sntesis, se trata de actuar de la misma manera en que los humanos, a los que en
informtica, en general, se nos denomina usuarios, "manejamos" y operamos el
mundo real.
ENCAPSULAMIENTO.
Utilizacin del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar
datos y operaciones en forma conjunta se llama ENCAPSULACION.
La encapsulacin es el resultado (o acto) de ocultar, al usuario, los detalles de la

implementacin de un objeto. El objeto oculta sus datos a otros objetos y slo permite
accesar a sus datos va sus propios mtodos mediante mensajes especficos, es decir,
se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llama
ocultamiento de informacin. La encapsulacin protege los datos de un objeto de la
corrupcin. Si todos los programas pudieran accesar a los datos (como actualmente
sucede con la tecnologa estructurada), fcilmente puede corromperse o perderse. La
encapsulacin protege los datos del objeto del uso arbitrario y no intencionado. As la
creacin est protegida y la competencia garantizada.
La encapsulacin tiene dos beneficios primordiales:
MODULARIDAD. El cdigo de un objeto puede ser escrito y se puede mantener

independiente del cdigo de otros objetos. Un objeto se puede mover de sistema en
sistema, se puede quitar, modificar y volver a colocar sin alterar el sistema general.
ESCONDER LA INFORMACIN ( INFORMATION HIDING ). Un objeto tiene una interfaz con la

que otros objetos se pueden comunicar, pero puede mantener informacin privada
para s misma que puede cambiar en cualquier momento, sin afectar a los objetos que
dependen de sta
REUTILIZACION.
Capacidad de reutilizar cdigo sin alterarlo, programando solo lo adicional o diferente.
Base de la Herencia.
Durante la vida de un sistema, las estructuras de datos se mantienen relativamente

estables, mientras que las operaciones sobre dichas estructuras cambian,
dependiendo de situaciones. Por ello en el Anlisis y Diseo Orientado a Objetos, se
da nfasis primordial a los DATOS y al COMPORTAMIENTO de los objetos y tipos de
objetos (modelos).Los datos, como son relativamente estables, pueden ser utilizados
muchas veces, modificando nicamente aquello que sea necesario para tal o cual
situacin, en la misma forma se procede con los comportamientos. En cambio, en el

Anlisis y Diseo Estructurado, se da nfasis a la descomposicin funcional orientada

al proceso, en consecuencia, cualquier modificacin requiere de una reconstruccin,
normalmente, a partir de cero.
Conceptos Bsicos
La ingeniera de software comprende las tcnicas de desarrollo formal para el diseo

de software. Problemas frecuentes del software tales como: Aumento de la
complejidad, cambios continuos, no confiable, dificultad para verificarlo, dificultad para
especificar los requerimientos, Estas son algunas de las razones por lo cual la
programacin orientada a objetos sea tan popular.
Qu son los objetos? Qu no son los objetos?

Objetos son "cosas": Space shuttle, Si tomamos como ejemplo el Objeto
empleado, paciente, casa, carro, objeto carro. Atributos de un objeto: velocidad,
empleado, puede ser simple o complejo, color, tamao. Funciones del objeto: ir,
puede ser real o imaginario. parar, girar a la derecha, girar a la
izquierda.
ENCAPSULAMIENTO DE OBJETOS
El encapsulamiento es combinar las funciones relacionadas, atributos y estados para
formar "objetos". El encapsulamiento implica autocontinencia, por ejemplo el objeto
"Carro" encapsula o "rene" sus atributos, funciones y estados en una unidad
autocontenida, el encapsulamiento usa informacin oculta. Algunas partes del objeto
son visibles a todas es decir, pblicas.
La funcin "steering wul" en el objeto "Carro" representa una interface pblica la cual
"enciende" el carro. Algunas partes del objeto son ocultas (privadas), "encender" es
nicamente visible a la funcin "steering wheel", por lo tanto privada.
La informacin oculta permite al detalle del objeto cambiar sin afectar los programas
que usan la clase, la informacin oculta elimina los problemas que se presentan al
modificar el cdigo y promueve la reutilizacin del cdigo.
Objeto
Es cualquier cosa real o abstracta, acerca de la cual
almacenamos datos y los mtodos que controlan
dichos datos.
Ejm.- una factura, una organizacin, una figura en un

programa como Corel Draw, una pantalla con la que
interacta un usuario, un campo o nodo de la
pantalla de una herramienta CASE, una avin, todo
un plano de ingeniera, el proceso para llenar un
pedido, etc. Daniel Ramos tambin sera un objeto, por las caractersticas que posee.

Tipo de Objeto
Es una categora 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 una
organizacin; algunas instancias de empleado podran ser Viviana Rivasplata, Maju
Mantilla, etc.
Mtodos
Especifican la forma en que se controlan los datos de un objeto. Los mtodos en un
tipo de objeto slo hacen referencia a las estructuras de datos de ese tipo de objeto.
Un objeto es entonces una cosa cuyas propiedades estn representadas por tipo de
datos y su comportamiento por mtodos.
Ejm.- Un mtodo asociado con el tipo de objeto factura podra ser aqul que calcule el
total de una factura. Otro podra transmitir la factura a un cliente, etc.
Encapsulado
El empaque conjunto de
datos y mtodos se llama
encapsulado. El objeto
esconde sus datos de los
dems objetos y permite
el acceso a los datos
mediante sus propios
mtodos, esto recibe el
nombre de ocultamiento
de la informacin. El
encapsulado evita la
corrupcin de los datos
de un objeto,
protegindolos del uso
arbitrario y no pretendido.
Ejm.- Un Cajero Automtico es un ejemplo de objeto. Tiene tipos especficos de

comportamiento. Un cajero globalnet es un tipo de objeto y un cajero automtico
individual sera una instancia de dicho objeto. Todas los Cajeros Automticos del
mismo tipo tienen los mismos mtodos. Los cajeros contienen muchos componentes
complejos, la mayora de los cuales tambin contienen otros componentes, pero uno
no necesita conocerlos.
Mensajes
Para que un objeto haga algo, le enviamos una solicitud, esta hace que se produzca
una operacin. El mensaje que constituye la solicitud contiene el nombre del objeto, el
nombre de una operacin y, a veces, un grupo de parmetros.
Un mensaje es una solicitud para que se lleve a cabo la operacin indicada y se

produzca el resultado; en consecuencia, las implantaciones OO se refieren a los
mensajes como solicitudes.

Una solicitud invoca una operacin especfica, con uno o ms objetos como
parmetros.
Ejm.- se puede comunicar con el TV al enviarle solicitudes por medio de un

sintonizador de control remoto. Responde el aparato mediante determinada accin y
presenta las respuestas en pantalla.
Clase
El trmino clase se refiere a la implantacin en software de un tipo
de objeto. Especifica una estructura de datos y los mtodos Ave
operativos permisibles que se aplican a cada uno de sus objetos. El
mtodo es parte de la clase, pero no parte del objeto. El mtodo ni
siquiera podra ser parte de la clase; pero podra ser parte de la
clase de mayor nivel en la jerarqua de clases.
Ejm.- una clase empleado incluira datos del seguro social, puesto, salario, extensin
telefnica, etc. Adems, cada clase define un conjunto de operaciones permisibles que
permiten el acceso y modificacin de los datos del objeto.
Herencia Ave
Un tipo de objeto de alto nivel
puede especializarse en tipos de
objeto de bajo nivel. Un tipo de
objeto puede tener subtipos. Una
clase implanta el tipo de objeto.
Una sub-clase hereda Faisan Pato Gallina
propiedades de su clase padre;
una sub-clase hereda propiedades
de las subclases, etc.
Ejm.- Un tipo de objeto persona puede tener subtipos civil y militar. Militar puede tener
subtipos oficial y subalterno. Oficial puede tener subtipos teniente, capitn, mayor, etc.
Herencia de Clase
Es una implantacin de la generalizacin. La generalizacin establece que las
propiedades de un tipo se aplican a sus subtipos. La herencia de clase hace que la
estructura de datos y operaciones sean disponibles para sus reutilizacin por parte de
sus subclases.
Polimorfismo
Se aplica a una operacin que adopta varias formas de implantacin. Una de las
ventajas del polimorfismo es que se puede hacer una solicitud de una operacin sin
conocer el mtodo que debe ser llamado. Estos detalles quedan ocultos para el
usuario; la responsabilidad descansa en el mecanismo de seleccin de la implantacin
OO.

Abstraccin
Es el acto o resultado de eliminar diferencias entre los objetos, de modo que podamos
ver los aspectos comunes. Todo objeto es nico, sin embargo, la abstraccin elimina
algunas distinciones para que podamos ver los aspectos comunes entre los objetos.
Se debe considerar lo siguiente:
Caractersticas 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.
Generalizacin
Es el acto o el resultado de distinguir un concepto que es ms general que otro. La
generalizacin nos permite examinar si los conceptos tienen algo en comn.
Evento
Es un cambio en el estado de un objeto. En el anlisis orientado a objetos el mundo se
describe en trminos de los objetos y sus estados, as como de los eventos que
modifican esos eventos. As, los eventos sirven como indicadores de los instantes en
que ocurren los cambios de estado.
Modularidad
Es la propiedad de un sistema que ha sido dividido en componentes. Los mdulos son
la divisin fsica de la abstraccin lgica. Hay que considerar lo siguiente:
Criterios de descomposicin: Encapsulacin vs. Visibilidad, Reusabilidad y

Segmentacin; y Necesidades no tcnicas.
Los diseadores lgicos y fsicos involucran decisiones independientes.
Ciclo de Vida del Software.

Para iniciar, debemos de tener en cuenta que, el software, es un elemento del sistema
que es de tipo lgico, a diferencia del hardware que es de tipo fsico.
Otro, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehculo

para entregarlo. Como producto, hace entrega de la potencia informtica que incorpora
el hardware informtico o, ms ampliamente, una red de computadoras que es
accesible por hardware local. Si reside dentro de un telfono celular (como el
BlackBerry de mi amigo Carlitos Chunga) u opera dentro de una computadora central,
el software es un transformador de informacin, produciendo, gestionando,
adquiriendo, modificando, mostrando o transmitiendo informacin que puede ser tan
simple como un solo bit, o tan complejo como una presentacin en multimedia. Como
vehculo utilizado para hacer entrega del producto, el software acta como la base de

control de la computadora (sistemas operativos), la comunicacin de informacin

(redes) y la creacin y control de otros programas (herramientas de software).
Quizs algunas caractersticas que debemos de tener en cuenta al momento de

desarrollar un software, son las siguientes:
El software se desarrolla, no se fabrica en un sentido clsico.
El software no se estropea o malogra, pero si se puede deteriorar segn las
actualizaciones que este pudiera tener.
Aunque hoy en da se habla de construir ensamblados o componentes, la
mayora del software se construye a medida.
El software puede aplicarse en cualquier situacin en la que se haya definido
previamente un conjunto especfico de pasos procedimentales (es decir, un
algoritmo), claro, excepciones notables a esta regla son el software de los
sistemas expertos y de redes neuronales. El contenido y el determinismo de la
informacin son factores importantes a considerar para determinar la
naturaleza de una aplicacin de software. El contenido se refiere al significado
y a la forma de la informacin de entrada y salida.
Sobre los sistemas
Algo que debemos de tener en cuenta es, que todo sistema a desarrollar, por mas
pequeo o grande que sea, siempre va a requerir de datos para poder funcionar, estos
sern procesados, para poder obtener la informacin.
A su vez, nuestro sistema puede retomar la informacin generada, para devolver

informacin mas refinada, en un proceso conocido como Feedback o
Retroalimentacin, 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 de
partida para todo este desarrollo, y ese es cuando el especialista en desarrollo de
sistemas interacta (Analista) con el Cliente (el cual, habitualmente es el Dueo de la
Empresa, el Gerente General o algn Gerente de rea, quienes son los que tienen la
potestad de desembolso de dinero). Aqu es donde se determina si hay posibilidades
de poder desarrollar un sistema de informacin
En el Anlisis de Requerimientos se realiza la comprobacin de lo recopilado en el

Estudio Preliminar, atravs de entrevistas que se realizaran al personal del rea
involucrada, de tal manera que se puedan conocer sus requerimientos reales, las
funciones que desempean y el procedimiento que siguen, as como los documentos
que utilizan.
Todo esto debe de reflejarse en un documento que muestre la situacin actual de la

empresa, los problemas y las causas que las originan, as como las soluciones
propuestas.
Proceso de desarrollo utilizando UML.

UML ha nacido como un lenguaje, pero es mucho ms que un lenguaje de
programacin. Aunque en su gnesis se parece a C++ o a Java, en realidad se ha
diseado y construido un lenguaje que ha nacido con una madurez muy acentuada si
se le compara, incluso, con los ltimos desarrollos de HTML, Java y XML, los
lenguajes por excelencia del mundo Internet.

UML se ha diseado realizando

combinaciones de una gran cantidad
de estndares, si bien se rige a
travs de tres metodologas
procedentes de la colaboracin de
los tres creadores de UML, que son:
James Rumbaugh, Grady Booch e
Ivar Jacobson, as como del
anlisis y estudio de alrededor de 20
mtodos estndares que a su vez se
han integrado en otro estndar, en
este caso, UML; esta fue una gran
iniciativa de los tres creadores que
pusieron las especificaciones de
UML a la consideracin de la
comunidad informtica mundial,
antes de su publicacin. El diseo
de UML ha sido completo desde el
principio, al contrario que HTML que
ha cambiado gradualmente, de
forma que XML ha tratado de
resolver los problemas de HTML y Java, que sigue todava en el proceso de
estandarizacin con la nueva versin 2.0. Al contrario que HTML/XML que son
lenguajes de marcacin (markup), UML es un lenguaje para modelar; que es el
procedimiento que emplean los ingenieros para el diseo de software antes de pasar a
su construccin, al igual que sucede con cualquier producto manufacturado o
fabricado en serie.
UMIL ayuda al usuario a entender la calidad de la tecnologa y la posibilidad de que

reflexione antes de invertir y gastar grandes cantidades en proyectos que no estn
seguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construccin
de las piezas que constituirn el modelo.
Sin embargo, desde el punto de vista puramente tecnolgico, UML tiene una gran
cantidad de propiedades que han sido las que, realmente, han contribuido a hacer de
UML el estndar de facto de la industria que es en realidad. Algunas de las
propiedades de UML como lenguaje de modelado estndar son:
Concurrencia, es un lenguaje distribuido y adecuado a las necesidades de

conectividad actuales y futuras.
Ampliamente utilizado por la industria desde su adopcin por OMG.
Reemplaza a decenas de notaciones empleadas con otros lenguajes.
Modela estructuras complejas.
Las estructuras ms importantes que soportan tienen su fundamento en las
tecnologas orientadas a objetos tales como: objetos, clases, componentes y
nodos.
Emplea operaciones abstractas como gua para variaciones futuras, aadiendo
variables si acaso es necesario.
Comportamiento del sistema: casos de uso, diagramas de secuencia y de
colaboraciones, que sirven para evaluar el estado de las mquinas.

Descripcin del Proceso Actual: El Modelo de Negocios.

La importancia que tiene el elaborar un modelo de negocios, antes de modelar el
sistema informtico, es el siguiente:
Maneja informacin que le pertenece al negocio.

Ser utilizado en organizaciones que ejecutan procesos del negocio cada vez
ms automatizable.
Se adaptar al entorno de la organizacin que lo usar.
Para identificar con facilidad donde estn los problemas y oportunidades de
crecimiento y mejora.
Porque desde la perspectiva de los sistemas, no es posible automatizar
procesos que no estn 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 lgico.
Emplean recursos de la organizacin.
Ofrece resultados de inters a alguien.
Apoya algn objetivo de la organizacin.
rea Funcional
Grupo de Trabajo.
Objetivos
Comprender la estructura y la dinmica de la organizacin objetivo.

Comprender los problemas actuales del organizacin objetivo e identificar el

campo de accin incluido en donde hay un potencial de crecimiento y mejoras.
Evaluar el impacto del cambio en la organizacin objetivo.
Asegurar que los clientes, usuarios finales, desarrolladores y otros roles tengan
un entendimiento comn de la organizacin objetivo.
Obtener, de forma preliminar, los requerimientos del sistema que necesita la
organizacin objetivo.
ESTEREOTIPOS
Actividades del Modelo de Negocio.

Evaluar la organizacin 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 anlisis del negocio.
Mantener las reglas del negocio.
Capturar un vocabulario comn.
Definir las actividades a automatizar.
El actor del negocio representa un rol ejecutado por alguien o

algo externo al negocio, pero que interacta 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 de
informacin localizados fuera del negocio.
NO debe representar reas, departamentos o partes de una
organizacin, sino roles de ejecucin.

El caso de uso del negocio, identifica un proceso especfico del

negocio que produce un resultado de valor medible, y esperado
por un actor en particular.
Representa la secuencia de actividades desarrolladas para
lograr ese valor.
Reconoce los procesos del tipo de giro del negocio, por
comparacin con el de otras empresas o a partir del estudio de
la cadena de valor.
Son procesos complejos del negocio, no son actividades
simples.
El trabajador del negocio, representa aquel personaje que tiene

algn tipo de responsabilidad dentro del rea de estudio, vale
decir, que realiza algn tipo de tarea dentro de la misma, o tiene
alguna responsabilidad.
Creacin del Modelo en Rational Rose
Para poder implementar el modelo antes mencionado, haremos uso de la Herramienta

CASE Rational Rose.
1. una vez instalado el producto, boton Inicio, luego Ejecutar y escribir ROSE,
mostrndose la siguiente pantalla.
2. para trabajar con un modelo de anlisis, seleccionaremos Rational Unified

Process.

3. una vez que nos encontremos en la pantalla principal, pondremos especial

atencin al rea del Browser, que se encuentra al lado izquierdo, donde
desplegaremos el elemento Use Case View.

4. realizar un doble click sobre el objeto Main, abriendose una nueva venta, de
tipo Use Case Diagram.
5. seguidamente, crearemos un paquete de nombre Modelo de Negocio, sobre

la ventana que se muestra, ver lo que ocurre en el Browser.

6. luego, hacer doble clic sobre el paquete Modelo de Negocio, debindose abrir
una nueva ventana, donde empezaremos a desarrollar nuestro modelo.

CAPITULO 2
Del Modelo de Negocios al Modelo del Sistema.
Funcionalidad del Sistema: Use Case Diagram.
Tipos de asociacin entre CUs.
Documentando los CUs.

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, nos
dedicaremos a tratar de automatizar la mayor cantidad de procesos posibles, para ello
tengamos en cuenta lo siguiente:
Para poder representar la funcionalidad que va a tener nuestro sistema de

informacin, 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 del
sistema en transacciones significativas para los actores-usuarios ideales de un
sistema. Las piezas de funcionalidad interactiva se llaman casos de uso. Un caso de
uso describe una interaccin con los actores como secuencia de mensajes entre el
sistema y uno o ms actores. El trmino actor incluye a los seres humanos, as como a
otros sistemas informticos y procesos.

ACTOR
Un actor es una idealizacin de una persona externa, de un proceso, o
de una cosa que interacta con un sistema, un subsistema, o una clase.
Un actor caracteriza las interacciones que los usuarios exteriores pueden
tener con el sistema. En tiempo de ejecucin, un usuario fsico puede
estar limitado a los actores mltiples dentro del sistema. Diferentes
usuarios pueden estar ligados al mismo actor y por lo tanto pueden
representar casos mltiples de la misma definicin de actor.
Cada actor participa en uno o ms casos de uso. Interacta con el caso de USO (y por
lo tanto con el sistema o la clase que posee el caso de uso), intercambiando
mensajes. La implementacin interna de un actor no es relevante en el caso de uso;
un actor puede ser caracterizado suficientemente por un conjunto de atributos que
definen su estado.
Los actores pueden ser definidos en jerarquas de generalizacin, en las cuales una
descripcin abstracta del actor es compartida y aumentada por una o ms
descripciones especficas del actor.
Un actor puede ser un ser humano, otro sistema informtico, o un cierto proceso
ejecutable. Se dibuja a un actor como una persona pequea con trazos lineales y el
nombre debajo de l.
CASO DE USO
Un caso de uso es una unidad coherente de funcionalidad,
externamente visible, proporcionada por una unidad del sistema
y expresada por secuencias de mensajes intercambiados por la
unidad del sistema y uno o ms actores. El propsito de un caso
de uso es definir una pieza de comportamiento coherente, sin
revelar la estructura interna del sistema. La definicin de un caso de uso incluye todo
el comportamiento que implica: las lneas principales, las diferentes variaciones sobre
el comportamiento normal, y todas las condiciones excepcionales, que pueden ocurrir
con tal comportamiento, junto con la respuesta deseada. Desde el punto de vista de
los usuarios, stas pueden ser situaciones anormales. Desde el punto de vista de los
sistemas, son las variaciones adicionales que deben ser descritas y manejadas.
En el modelo, la ejecucin de cada caso de uso es independiente de las dems,

aunque una implementacin de casos de uso puede crear dependencias implcitas
entre ellas, debido a los objetos compartidos. Cada Caso de Uso representa una pieza
ortogonal de la funcionalidad, cuya ejecucin se puede mezclar con la ejecucin de
otros casos de uso.
La dinmica de un caso de uso se puede especificar por las interacciones de UML,

mostradas como diagramas de estado, diagramas de secuencia, diagramas de
colaboracin, o descripciones informales de texto. Cuando se implementan, los casos
de uso son realizados mediante colaboraciones entre clases del sistema. Una clase
puede participar en mltiples colaboraciones y, por lo tanto, en mltiples casos de uso.
En el nivel de sistema, los casos de uso representan el comportamiento externo de
todo sistema tal y como se muestra a los usuarios exteriores. Un caso de uso es como

una operacin de sistema, una operacin invocada por un usuario exterior. Sin
embargo, a diferencia de una operacin, un caso de uso puede continuar recibiendo la
entrada de sus actores durante su ejecucin. Los casos de uso tambin se pueden
aplicar internamente a unidades ms pequeas de un sistema, tales como
subsistemas y clases individuales. Un caso interno de uso representa el
comportamiento 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 que
una clase proporciona a otras clases que desempeen ciertos roles dentro del
sistema. Una clase puede tener ms de un caso de uso.
Un caso de uso es una descripcin lgica de una parte de funcionalidad del sistema.
No es una construccin manifiesta en la implementacin 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 operaciones

de las clases. Ya que una clase puede desempear roles mltiple en la
implementacin de un sistema, puede por lo tanto realizar porciones de mltiples
casos de uso. Una parte de la tarea del diseo es encontrar las clases de
implementacin que combinen claramente los roles apropiados para implementar
todos los casos de uso, sin introducir complicaciones innecesarias. La implementacin
de un caso de uso se puede modelar como un conjunto de una o ms colaboraciones.
Una colaboracin es una realizacin de un caso de uso.
Un caso de uso puede participar en varias relaciones, adems de poderse asociar con
actores.
Un caso de uso se dibuja como una elipse con su nombre dentro o debajo de ella. Se
conecta por lneas con trazo continuo con los actores que se comunican con ella.
Tipos de asociacin entre CUs.

Un caso de uso es una descripcin lgica de una parte de funcionalidad del sistema.
Un caso de uso puede participar en varias relaciones con otros casos de uso, adems
de poderse asociar con actores.
Aunque cada instancia de un caso de uso es independiente, la descripcin de un caso

de uso se puede descomponer en factores de otros casos de uso ms simples. Esto
es similar a la manera en que la descripcin de una clase se puede definir
incrementalmente a partir de la descripcin de las superclases. Un caso de uso puede
incorporar simplemente el comportamiento de otros casos de uso como fragmentos de
su propio comportamiento. Esto se llama relacin de inclusin. En este caso, el nuevo
caso de uso no es un caso especial del caso de uso original, y no se puede sustituir
por l.
Un caso de uso se puede tambin definir como una extensin incremental de un caso
de uso base. Esto se llama relacin de extensin. Puede haber varias extensiones del
mismo caso de uso base, que pueden ser aplicadas conjuntamente. Las extensiones a
un caso de uso base se agregan a su semntica; que es el caso de uso base instancia
do, no los casos de uso de la extensin.

Las relaciones de inclusin y extensin se dibujan como flechas de lneas discontinuas

con la palabra clave include o extend. La relacin de inclusin apunta al caso de
uso a ser incluido; la relacin de extensin seala el caso de uso que se extender.
Relacin Funcin Notacin
Solo se produce entre un Actor y un

Comunicacin
Caso de Uso.
La insercin de comportamiento
Extensin adicional en un CU base que no tiene
conocimiento sobre l.
Relacin entre un CU general y un CU

Generalizacin ms especfico, que hereda y aade
propiedades.
Insercin de comportamiento adicional

Inclusin en un CU base, que describe
explcitamente la insercin.
Comunicacin
Las instancias de actores se comunican con el sistema mediante el envo y recepcin

de instancias de mensajes (seales y llamadas) desde y hacia instancias de casos de
uso, y en el nivel de realizacin, desde y hacia
los objetos que implementan el caso de uso.
Todo lo anterior se expresa mediante
asociaciones entre el actor y el caso de uso.
Un actor puede listar el conjunto de seales

que enva y que recibe, y mantener una lista de
las interfaces que ofrece y que requiere. Las interfaces de un actor deben ser
compatibles con las de los casos de uso con los que se comunica. En otras palabras,
un actor debe recibir todas las seales que un Caso de uso sea capaz de enviarle y no
debe mandarle al caso de uso seales que ste no sea capaz de recibir. Las interfaces
de un actor restringen las clases con las que pueda corresponderse (que puedan
implementar su comportamiento). Un actor puede tambin tener una lista de atributos
que caracterice su estado.

Generalizacin
Pueden existir semejanzas entre dos o ms actores;

esto es, pueden comunicarse COn el mismo conjunto de
casos de uso de la misma manera. Esta semejanza se
expresa mediante la generalizacin en otro actor,
posiblemente abstracto, que modele los aspectos
comunes. Los actores descendientes heredaran los roles
y relaciones con casos de uso del actor antecesor. Una
instancia de un actor descendiente siempre se puede
utilizar en aquellos casos en los que se espera una
instancia del actor antecesor (principio de capacidad de
sustitucin). Un descendiente incluye los atributos y
operaciones de sus antecesores.
Inclusin
La relacin de inclusin conecta un caso de uso base con un caso de uso incluido. El
caso de uso incluido que figura en esta relacin no es un clasificador instanciable
independientemente. Lo que hace es describir explcitamente una secuencia adicional
de 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 aplicar
mltiples relaciones de inclusin. El mismo caso de uso incluido se puede incluir en
mltiples casos de uso base. Esto no indica ninguna relacin entre los casos de uso
base. Puede haber, incluso, mltiples relaciones de inclusin entre el mismo caso de
USO incluido y casos de uso base, siempre y cuando cada insercin se haga en una
posicin diferente de la base.
El caso de uso incluido puede acceder a atributos o a operaciones del caso de uso
base. La inclusin representa un comportamiento encapsulado que, potencialmente,
puede reutilizarse en mltiples casos de uso base. El caso de uso base ve al caso de
uso incluido, que puede dar valores a los atributos del caso de uso base. Pero el caso
de uso base no debe acceder a los atributos del caso de uso incluido, porque el caso
de uso incluido habr concluido cuando el caso de USO base recupere el control.
Obsrvese que se pueden anidar las adiciones (sea cual fuere su clase). Por tanto,
una inclusin puede servir como base para otra inclusin, extensin o generalizacin
posterior.

Extensin
Una relacin desde un caso de uso extensor a un caso de uso base, que especifica
cmo se puede insertar el comportamiento definido para el caso de uso extensor en el
comportamiento definido para el caso de uso base. El caso de uso extensor modifica
incrementalmente el caso de uso base de forma modular.
El caso de uso extensor en esta relacin, no es necesariamente un clasificador

instanciable separado. Consiste en uno o ms segmentos que describen las
secuencias adicionales de comportamiento que modifican incrementalmente el
comportamiento del caso de uso base. Cada segmento en un caso de uso extensor se
puede insertar en una localizacin separada en el caso de uso base. La relacin de
extensin tiene una lista de los nombres de los puntos de extensin, igual en nmero
al nmero de segmentos en el caso de uso extensor. Cada punto de extensin se
debe definir en el caso de uso base.
Un caso de uso extensor en una relacin de extensin puede tener acceso y modificar
los atributos definidos por el caso de uso base. El caso de uso base, sin embargo, no
puede ver las extensiones y puede no tener acceso a sus atributos u operaciones. El
caso de uso base define un marco modular en el cual puedan ser agregadas
extensiones, pero la base no tiene visibilidad sobre las extensiones. Las extensiones
modifican implcitamente el comportamiento del caso de uso base.
Como identificar un Actor
1. Quin est interesado en un requerimiento concreto?

2. En qu dominios de la organizacin se usar el sistema?
3. Quin ser beneficiario de la nueva funcionalidad?
4. Quin proveer, usar y/o retirar informacin?
5. Quin dar soporte y administrar el sistema?
6. Usar el sistema un recurso externo?
7. Un usuario actuar con diferentes roles?
8. Diferentes usuarios actuarn con un mismo rol?
9. Interaccionar el nuevo sistema con un sistema antiguo?

Como identificar un Caso de Uso
1. Cules son las tareas y responsabilidades de cada actor?

2. Algn actor crear, almacenar, cambiar, borrar o leer informacin del
sistema?
3. Qu casos de uso crearn, almacenarn, cambiarn, borrarn o leern esta
informacin?
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 darn soporte y mantendrn el sistema?
7. Pueden ser realizados por los CU todos los requerimientos funcionales
documentados?
Ventajas de los Casos de Uso
1. Lenguaje de comunicacin entre usuarios y desarrolladores.

2. Comprensin detallada de la funcionalidad del sistema.
3. Acotacin precisa de las habilidades de los usuarios.
4. Gestin de riesgo ms eficiente para gobernar la complejidad.
5. Estimacin ms exacta para determinar tiempo, recursos y prioridades en la
dosificacin de esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traduccin de requerimientos en cdigo
ejecutable.
7. Mayor control para mantener las sucesivas revisiones de los programas.
8. Certificacin contractual cliente-desarrollador.
9. Documentacin orientada al usuario: help, manual de procedimientos, reglas
del negocio.
10. Documentacin orientada al administrador del sistema: soporte de
mantenimiento.

Documentando los CUs.

Los casos de uso representan funcionalidades que va a tener el sistema, sin embargo,
estos agrupan varias tareas o actividades, razn por la cual es necesario describirlas,
con el objetivo de que los dems miembros del proyecto, puedan conocer los detalles
de cada una de las tareas y/o responsabilidades que los actores podrn hacer posible
con el uso del sistema.
A continuacin, se proceder a describir el CU Identificando Riesgos, tener en cuenta

que esta informacin, luego se observar en el diagrama de Actividad, el cual mostrar
la lgica que tiene el sistema.

Para poder retomar nuestro proyecto de sistema, lo primero que haremos ser abrir el
archivo donde se encuentra nuestro Modelo de Negocio, para luego seguir los
siguientes pasos:
1. desplegar desde el Browser el paquete Use Case View, y hacer doble clic
sobre el objeto Main, al abrirse la ventana, crearemos un nuevo paquete, de
nombre CU del Sistema.

2. seguidamente haremos un doble clic sobre dicho paquete, de tal manera que
se abra una nueva ventana, donde empezaremos a disear nuestro modelo.


CAPITULO 3
Capturando el Modelo de Objetos.
Uso de: Objetos, Clases, Encapsulamiento, Herencia, Polimorfismo.
Diagramas de Clases.
Tipos de Asociacin 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 continuacin conjugaremos las caractersticas del UML con los conceptos de la
orientacin a objetos.
Aqu refinarn su conocimiento de la orientacin a objetos al tiempo que aprendemos

otras cosas del UML.
Uso de: Objetos, Clases, Encapsulamiento, Herencia,

Polimorfismo.
Clase
En el UML un rectngulo es el smbolo que representa una clase. El nombre de la

clase es por convencin una palabra con la primera letra en mayscula y
normalmente se coloca en la parte superior del rectngulo. Si el nombre de su clase
consta de dos palabras nalas e inicie cada una con mayscula.
Otra estructura del UML el paquete, puede jugar un papel en el nombre de la clase un
paquete es la manera en que el UML organiza un diagrama de elementos. Tal vez
recuerde que el UML representa un paquete como una carpeta tabular cuyo nombre
es una cadena de texto.
Si la clase "GuaCompra" es parte de paquete llamado "DocumentosContables",

podr darle el nombre " DocumentosContables:: GuaCompra ", El par de dos
puntos 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 caracterstica de una clase y describe un rango de

valores que la propiedad podr contener en los objetos (esto es, instancias) de la
clase. Una clase podr contener varios o ningn atributo Por convencin, si el atributo
consta de una sola palabra se escribe en minsculas; por otro lado, si el nombre
contiene ms de una palabra cada palabra ser unida a la anterior y comenzar con
una letra mayscula, a excepcin de la primer palabra que comenzar en minscula

La lista de nombres de atributos iniciar luego de una lnea que la separe del nombre
de la clase como se aprecia en la figura.
Todo objeto de la clase tiene un valor especfico en cada atributo. La figura le

muestra un ejemplo. Observe que el nombre de un objeto inicia con una letra
minscula y est procedido de dos puntos que a su vez estn procedidos del nombre
de la clase y todo el nombre est subrayado.
El UML le da la opcin de indicar informacin adicional de los atributos. En el smbolo

de la clase podr especificar un tipo para cada valor del atributo. Entre los posibles
tipos se encuentran cadena (string) nmero de punto flotante (float), entero (integer)
y booleano (boolean) as como otros tipos enumerados. Para indicar un tipo, utilice
dos puntos (:) para separar el nombre del atributo de su tipo. Tambin podr indicar un
valor predeterminado para un atributo La figura le muestra las formas de establecer
atributos.
Operaciones
Una operacin es algo que la clase puede realizar, o que

usted (u otra clase) pueden hacer a una clase. De la
misma manera que el nombre de un atributo el nombre de
una operacin se escribe en minsculas si consta de una
sola palabra.
Si el nombre constara de ms de una palabra nalas e

inicie todas con mayscula exceptuando la primera. La
lista de operaciones se inicia debajo de una Lnea que
separa al de las operaciones de los atributos como se
muestra en la figura.
As como es posible establecer informacin adicional de

los atributos, tambin lo es en lo concerniente a las
operaciones En los parntesis que preceden al nombre de
la operacin podr mostrar el parmetro con el que

funcionar la operacin junto con su tipo de funcin, que es un tipo de operacin,

devuelve un valor luego que finaliza su trabajo. En una funcin podr mostrar el tipo de
valor que regresar,
Estas secciones de informacin acerca de una operacin se conocen como la firma de

la operacin.
Si usted tiene una larga lista de atributos u operaciones podr utilizar un estereotipo
para organizarla de forma que sea ms comprensible. Un estereotipo es el modo en
que el UML le permite extenderlo es decir crear nuevos elementos que son
especficos de un problema en particular que intente resolver Como lo mencion en la
hora l. usted muestra un estereotipo como un nombre bordeado por dos pares de
parntesis angulares. Para una lista de atributos podr utilizar un estereotipo como
encabezado de un subconjunto de atributos como en la figura.
La idea es incluir informacin suficiente para describir una clase de forma inequvoca
Una manera ms formal es agregar una restriccin un texto libre. Bordeado por
llaves; este texto especifica una o varias reglas que sigue la clase.
Notas Adjuntas
Por encima y debajo de los atributos, operaciones responsabilidades Y

restricciones puede agregar mayor informacin a una clase en la figura de notas
adjuntas
Con frecuencia agregar una nota a un atributo u operacin. La figura le muestra una
nota que se refiere a una norma gubernamental que indica dnde encontrar la manera
en que se generan los nmeros de serie para los objetos de la clase Lavadora
GuiaCompra
nroGuia
fechaEmision documento que se
condicionPago emite al Prov eedor
observaciones
nuevaGuia()
imprimir()
cerrar()
anular()

Diagramas de Clases.
Las clases son el vocabulario y tecnologa de un rea del conocimiento conforme
hable con los clientes, analice su rea de conocimiento y disee sistemas de
computacin que resuelvan los problemas de dicha rea, comprender la terminologa
y modelar los trminos como clases en el UML.
En sus conversaciones con los clientes preste atencin a los sustantivos que utilizan
para describir las entidades de sus negocios; ya que dichos sustantivos se convertirn
en las clases de su modelo Tambin preste atencin a los verbos que escuche dado
que constituirn las operaciones de sus clases .Los atributos surgirn como
sustantivos relacionados con los nombres de la clase. Una vez que tenga una lista
bsica de las clases pregunte a los clientes que es lo que cada clase hace dentro
del negocio. Sus respuestas le indicarn las responsabilidades de la clase
Suponga que usted es un analista que generar un modelo del juego de
baloncesto. y que entrevista a un entrenador para comprender el juego La
conversacin podra surgir como sigue:
Analista: "Entrenador, de que se trata el juego?

Entrenador: "Consiste en anotar el baln a travs de un aro, conocido como cesto, y
hacer una mayor puntuacin que el oponente, Cada equipo consta de cinco jugadores
dos defensas dos delanteros y un central. Cada equipo lleva el baln al cesto del
equipo oponente con el objetivo de hacer que el baln sea encestado."
Analista: "Cmo se hace para llevar el baln al cesto?"
Entrenador: "Mediante pases y dribles. Pero el equipo tendr que encestar antes de
que termine el lapso para tirar."
Analista: "El lapso para tirar?"
Entrenador: "As es, son 24 segundos en el baloncesto profesional, 30 en un juego
internacional, y 35 en el colegial para tirar el baln luego de que un equipo toma
posesin de l."
Analista: "Cmo funciona el puntaje?"
Entrenador: "Cada canasta vale dos puntos, a menos que el tiro baya sido hecho
detrs de la Lnea de los tres puntos En tal caso, tres puntos Un tiro libre contar como
un punto. A propsito, un tiro libre es la Penalizacin que paga un equipo por cometer
una infraccin Si un jugador infracciona a un oponente. se detiene el juego y el
oponente puede realizar diversos, tiros a! cesto desde la Lnea de tiro libre."
Analista: "Hbleme ms acerca de lo que hace cada jugador,"

Entrenador: "Quienes juegan de defensa son, en general, quienes realizan la mayor
parte 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 tambin se conoce como 'poste')
Se supone que Iodos los jugadores pueden burlar, pasar, tirar y rebotar los delanteros
realizan la mayora de los rebotes y los disparos de mediano alcance, mientras que el
central 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
cunto dura el juego?"
Entrenador: "En un juego internacional, la cancha mide 28 metros de longitud y 15 de
ancho; el cesto se encuentra a 3.05 m del piso, En un juego profesional, el juego dura
48 minutos, divididos en cuatro cuartos de 12 minutos cada uno, En un juego colegial
e internacional, la duracin es de 40 minutos, divididos en dos mitades de 20 minutos,
Un cronmetro del juego lleva un control del tiempo restante"

La pltica podra continuar, pero hagamos una pausa y veamos con qu contamos,
Aqu hay varios sustantivos que ha descubierto baln, cesto, equipo, jugadores,
defensas, delanteros, cesto (o poste), tiro, lapso para tirar, lnea de los 3 puntos, tiro
libre, infraccin, lnea de tiro libre, cancha, cronmetro del juego y los verbos: tirar,
avanzar, driblar (o burlar), pasar, infraccionar, rebotar. Tambin cuenta con cierta
informacin adicional respecto a algunos de los sustantivos (como las estaturas
relativas de los jugadores de cada posicin. las dimensiones de la cancha, la cantidad
total de tiempo en un lapso de tiro y la duracin de un juego)
Finalmente, su propio sentido comn podra entrar en accin para generar ciertos
atributos por usted mismo. Usted sabe, por ejemplo, que el baln cuenta con ciertos
atributos, como volumen y dimetro
A partir de esta informacin, podr crear un diagrama como el de la figura En l se

muestra las clases y se proporcionan ciertos atributos, operaciones y restricciones
El diagrama tambin muestra las responsabilidades. Podra usar este diagrama
como fundamento para otra., conversaciones con el entrenador para obtener mayor
informacin.
Jugador Balon Equipo

nombre volumen
estatura diametro
peso
driblar()
dribalrBalon() tirar()
pasarBalon() pasar() Cancha
tirarBalon() avanzar()
rebotar()
infraccionarOponente()
TiroLibre Defensa Cesto Infraccion
Tipos de Asociacin entre Clases

Una 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:
Asociacin (Binaria)
Cuando una clase se vincula con otra clase, para ello se trazar una lnea 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 tal
asociacin. Puede representar estos papeles en el diagrama escribindolos cerca de
la Lnea que se encuentra junio ala clase que juega el papel correspondiente.
Clases de Asociacin (Atributos de Enlace)
Una asociacin al igual que una clase puede contener atributos y operaciones.
Cuando este sea el caso usted tendr una clase de asociacin.
Puede concebir a una clase de asociacin de la misma forma en que lo hara con una
clase estndar y utilizar una lnea discontinua para conectarla a la lnea de asociacin
Una clase de asociacin puede tener asociaciones con otras clases
Factura
nroFactura Producto
fechaEmision
0..* 1..* nombre
subTotal
precioVenta
igv
stock
Total
fechaCancelado
DetalleFactura
cantidad
importe
Tener en cuenta que, esta asociacin solo se produce cuando existe una relacin con
multiplicidad de muchos a muchos, y adicionalmente, existan atributos que
describan la relacin.

Asociaciones Reflexivas
En ocasiones una clase es una asociacin consigo misma Esto puede ocurrir cuando
una clase tiene objetos que pueden jugar diversos papeles Un OcupanteAutomovil
puedo ser un Conductor o un Pasajero. En el papel del conductor el
OcupanteAutomovil puede llevar ninguno o ms OcupanteAutomovil quienes jugarn
el papel de pasajeros Esto lo representar mediante el trazo de una Lnea de
asociacin a partir del rectngulo de la clase hacia el mismo rectngulo de la clase. y
en la lnea de asociacin indicar los papeles nombre de la asociacin direccin de la
asociacin y multiplicidad corno ya lo hizo antes La figura le presenta este ejemplo:
+conductor 1 OcupanteAutomovil
0..*
+pasajero
conduce
Herencia Y Generalizacin
Uno de los sellos distintivos de la orientacin a objetos es que captura uno de los
mayores aspectos del sentido comn en cuanto a la vida diaria: si usted conoce algo
de una categora de cosas automticamente sabr algunas cosas que podr
transferir a otras categoras Si usted sabe que algo es un electrodomstico, ya
sabr que contar con un interruptor, una marca y un numero de serie
La jerarqua de la herencia no tiene que finalizar en dos niveles: una clase secundaria
puede ser principal para otra clase secundaria Un Mamfero es una clase secundaria
de Animal y Caballo es una clase secundaria de Mamfero que algo es un animal
dar por hecho que come, duerme, tiene una forma de nacer de trasladarse de un
lugar a otro y algunos otros atributos (y operaciones) que podra listar si pensara en
ello por algunos instantes.

VehiculoTransporte
Terrestre Maritimo Aereo
Automovil Tren Barco Avion
La orientacin a objetos se refiere a esto como herencia. El UML tambin lo

denomina generalizacin. Una clase (la clase secundaria o subclase) puede heredar
los atributos y operaciones de otra (la clase principal o superclase). La clase
principal (o madre) es ms genrica que la secundaria (o hija).
Agregacin / Composicin
Un objeto no es algo compacto ni indivisible, por el contrario, el objeto puede estar

conformado por otros objetos, ocasionando que existan relaciones mas fuertes que
otras.
Cuando un objeto esta conformado por otros objetos, pero si prescinde de ellos no
pierde su esencia o razn de ser, se dice que la relacin es por Agregacin.
Automvil Radio
Pero cuando el objeto pierde sus facultades o esencia ante la ausencia de algn otro
objeto, entonces se dice que la relacin es por Composicin.
Automvil Motor
Para poder crear nuestro Diagrama de Clases, empecemos abriendo nuestro

proyecto en Rational, luego:
1. desplegar desde el Browser el Logical View y hacer doble clic sobre el objeto
Welcome.

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 con
sus asociaciones.



CAPITULO 4
Definiendo la Lgica del Sistema.
Utilizando el Diagrama de Actividad.
Definiendo Escenarios.
Diagramas de Interaccin: Secuencia y Colaboracin.

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 podra parecerle familiar, este diagrama le
muestra los pasos en una operacin o proceso
En este tema se tratarn los siguientes temas:
Que es un diagrama de actividades

Aplicacin de los diagramas de actividades
Marcos de responsabilidad
Adiciones al panorama
Si alguna vez ha tomado algn curso bsico de programacin, ya conocer los

diagramas de flujo Siendo uno de los primeros modelos visuales que se aplicaron a la
computacin el diagrama de flujo muestra una secuencia de pasos, procesos, puntos
de decisin y bifurcaciones. A los programadores novatos se les invita a que utilicen
este diagrama para conceptualizar problemas y derivar sus soluciones. La idea es
convertir al diagrama de flujo en la base del cdigo con sus diversas caractersticas y
tipos 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 los
viejos diagramas de flujo. Le muestra los pasos (conocidos como actividades) as
como puntos de decisin y bifurcaciones es til para mostrar lo que ocurre en un
proceso de negocios u operacin. Los encontrar como parte integral del anlisis de
un sistema
Utilizando el Diagrama de Actividad.

Para empezar, un diagrama de actividades ha sido diseado
para mostrar una visin simplificada de lo que ocurre
durante una operacin o proceso es una extensin de un
diagrama de estados mismo que ya conoci El diagrama de
estados muestra los estados de un objeto y representa las
actividades como flechas que conectan a los estados. El
diagrama de actividades resalta precisamente a las NewActivity
actividades
A cada actividad se le representa por un rectngulo con las

esquinas redondeadas (ms angosto y ovalado que la NewActivity2
representacin del estado). El procesamiento dentro de una
actividad se lleva a cabo y. al realizarse se contina con la
siguiente actividad Una flecha representa la transicin de
una a otra actividad Al igual que el diagrama de estados el
de actividad cuenta con un punto inicial (representado por
un circulo relleno) y uno final (representado por una
diana).

Decisiones
Casi siempre una secuencia de actividades llegar a un punto donde se realizar

alguna decisin ciertas condiciones le llevaran por un camino y otras por otro (pero
ambas son mutuamente exclusivas).
Podr representar un punto de decisin de una de dos formas: la primera es mostrar

las rutas posibles que pasen directamente de una actividad y la segunda es llevar la
transicin hacia un rombo reminiscencias del smbolo de decisin en un diagrama de
flujo y que de all salgan las rutas de decisin (como usuario de los antiguos
diagramas de flujo. prefiero la segunda opcin). De cualquier forma, indicar la
condicin con una instruccin entre corchetes junto a la ruta correspondiente La figura
le muestra las posibilidades.
NewActivity
NewActivity2 NewActivity4
NewActivity3
Rutas Concurrentes
Conforme modele actividades tendr la

oportunidad de separar una transicin en
dos rutas que se ejecuten al mismo tiempo
(es decir de forma concurrente) y luego NewActivity
se renan para representar esta divisin
utilizar una lnea gruesa perpendicular a la
transicin y las rutas partirn de ella. Para
representar la reincorporacin ambas
rutas apuntarn a otra lnea gruesa. NewActivity2 NewActivity3

Teniendo en cuanta lo antes mencionado, procederemos a mostrar el diagrama de

secuencia para la funcionalidad Validar Ingreso al Sistema.
intentos=0 fracaso
no
mostrar intentos < 3
formulario
si
ingresar datos intentos++

usuario
vlido?
no
verificar autenticidad mostrar
de datos mensaje error
si
mostrar formulario
proncipal
exito
Definiendo Escenarios (Calles).

En algunas ocasiones, es til organizar las actividades en un modelo segn su
responsabilidad, por ejemplo, agrupando juntas todas las actividades manejadas por
una organizacin del negocio. Esta clase de asignacin puede mostrarse organizando
las actividades en regiones distintas separadas por lneas en el diagrama. Debido a su
aspecto, cada regin se llama calle.

RESUMEN
El diagrama de actividades del UML es muy parecido a un diagrama de flujo muestra

los pasos, puntos de decisin y bifurcaciones Este tipo de diagrama es til para
representar las operaciones de un objeto y los procesos de negocios
El diagrama de actividades es una extensin del diagrama de estados Los

diagramas de estados destacan los estados y representan actividades como flechas
entre los estados .Los de actividades se enfocan en las actividades Cada actividad
se representa como un rectngulo con esquinas redondeadas, ms ovalados en
apariencia que la representacin de un estado. El diagrama de actividades utiliza los
mismos smbolos que el de estados para los puntos de inicio y final.
Diagramas de Interaccin: Secuencia y Colaboracin.

Los diagramas de interaccin, permiten mostrar como los objetos interactan entre
si, para cumplir con la funcionalidad establecida.

Diagrama de Secuencia
El diagrama de secuencias consta de objetos que se representan del modo usual con
rectngulos con nombre (subrayado), mensajes representados por lneas continuas
con una punta de flecha y el tiempo representado como una progresin vertical
OBJETOS
Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha
y se acomodan de manera que simplifiquen al diagrama La extensin que esta debajo
(y en forma descendente) de cada objeto ser una lnea discontinua conocida como
la Lnea de vida de un objeto. Junto con la lnea de vida de un objeto se encuentra un
pequeo rectngulo conocido como activacin, el cual representa la ejecucin de una
operacin que realiza el objeto. La longitud del rectngulo se interpreta como la
duracin de la activacin. La figura muestra un objeto, su lnea de vida y su activacin.
MENSAJE
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto a la de

otro .Un objeto puede enva un mensaje a si mismo es decir desde su Lnea de vida
hacia su propia lnea de vida Un mensaje puede ser simple, sincrnico o
asincrnico
Un mensaje simple es la transferencia del control de un objeto a otro. Si un objeto

enva un mensaje sincrnico esperara la respuesta a tal mensaje antes de continuar
con su trabajo. Si un objeto enva un mensaje asincrnico no esperar una respuesta
antes de continuar. En el diagrama de secuencias los smbolos del mensaje varan
por ejemplo la punta de la flecha de un mensaje simple est formada por dos o mas la
punta de la flecha de un mensaje sincrnico est llena y la de un asincrnico tiene
una sola lnea como se aprecia en la figura.

TIEMPO
El diagrama representa al tiempo en direccin vertical El tiempo se inicia en la parte

superior y avanza hacia la parte inferior Un mensaje que est ms cerca de la parte
superior ocurrir antes que uno que est cerca de la parte inferior
Con ello el diagrama de secuencias tiene dos dimensiones. La dimensin horizontal

es la disposicin de los objetos. y la dimensin vertical muestra el paso del tiempo La
figura muestra al conjunto bsico de smbolos del diagrama de secuencias con los
smbolos en funcionamiento conjunto La figura muestra a un actor que inicia la
secuencia aunque en sentido estricto la figura adjunta no es parte del conjunto de
smbolos del diagrama de secuencias.
Objeto1 Objeto2
: <Actor Name>
Para ver en accin a esta importante herramienta del UML apliqumosla en los
ejemplos que hemos visto anteriormente. Cada aplicacin le mostrar algunos
conceptos importantes que se relacionan con los diagramas de secuencias
LA SECUENCIA
Suponga que el usuario de una GUI presiona una tecla alfanumrica; si asumimos que
utiliza una aplicacin como un procesador de textos el carcter correspondiente
deber aparecer de inmediato en la pantalla Qu ocurre tras bambalinas para que
esto suceda?

Diagrama de actividad
1. abrir el paquete que contiene el diagrama de Casos de Uso.
2. hacer clic derecho sobre el caso de uso a describir su lgica, y luego del men
contextual, seleccionar Sub Diagrams, luego New Activity Diagram.

3. seguidamente, procederemos a colocar las actividades correspondientes,

segn la lgica adecuada para el caso de uso correspondiente.
Diagrama de Secuencia
1. 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 de
secuencia, luego, seleccionar la opcin Open Specification.
3. de la ventana que se muestra, seleccionar la ficha Diagrams, luego, en el rea

libre, hacer clic derecho, y del men contextual seleccionar Insert Sequence
Diagram.
4. darle un nombre al nuevo grfico, como se ve en la figura, seguidamente,

hacer un doble clic sobre el, para que se apertura una nueva ventana, donde
procederemos a realizar nuestro diagrama.



CAPITULO 5
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. Ahora
ver un elemento que le muestra cmo modificar los procedimientos con el tiempo
En esta parte se tratarn los siguientes temas:
Qu es un diagrama de estados
Sucesos, acciones y condiciones de seguridad
Subestados: secuenciales y concurrentes
Estados histricos
Por que son importantes los diagramas de estados
Adicin del diagrama de estados al panorama del UML
Cada ao trae consigo nuevos estilos en ropas y automviles las estaciones cambian
el color de las hojas de los rboles y cada ao que pasa deja entrever el crecimiento y
madurez de los nios. Al pasar el tiempo y conforme suceden las cosas hay cambios
que afectan a los objetos que nos rodean.
Esto tambin se aplica en cualquier sistema conforme el sistema interacta con los
usuarios y (posiblemente) con otros sistemas los objetos que lo conforman pasaran
por cambios necesarios para ajustar las interacciones. Si va a modelar sistemas
necesitar 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 lo
componen modificaron su estado como respuesta a los sucesos y al tiempo
He aqu algunos ejemplos rpidos
Cuando acciona el interruptor, la fuente de luz cambia su estado de apagada a

encendida.
Cuando presiona un botn de un control remoto, una televisin 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 estados
en los que puedo encontrarse un objeto junto con las transiciones entre los estados, y
muestra los puntos inicial y final de una secuencia de cambios de estado,
UN DIAGRAMA DE ESTADOS MUESTRA LAS CONDICIONES DE UN SOLO

OBJETO.

SIMBOLOGA
La figura le muestra el rectngulo de vrtices redondeados que representa a un estado

junto con una lnea continua y una punta de flecha mismas que representan a una
transicin. La punta de la flecha apunta hacia el estado donde se har la transicin. La
figura tambin muestra un crculo relleno que simboliza un punto inicial y la diana que
representa a un punto final.
SUCESOS Y ACCIONES
Tambin puede agregar ciertos detalles a las lneas de transicin. Puede indicar un
suceso que provoque una transicin (desencadenar un suceso), y la actividad de
cmputo (la accin) que se ejecute y haga que suceda la modificacin del estado. A
los sucesos y acciones los escribir cerca de la lnea de transicin mediante una
diagonal para separar un suceso desencadenando de una accin En ocasiones un
evento causar una transicin sin una accin asociada. y algunas veces una transicin
suceder dado que un estado finalizar una actividad (en lugar de hacerlo por un
suceso). A este tipo de transicin se le conoce como transicin no desencadenada La
GUI (interfaz grfica de usuario) con que interacte le dar ejemplos de detalles de la
transicin. Por el momento, asumamos que la GUI puede establecerse en uno de tres
estados:
Inicializacin
Operacin
Apagar
Cuando encienda su equipo se ejecutar un proceso de arranque. Al encender la PC

se desencadena un suceso que provoca que la GUI aparezca luego de una transicin
desde el estado de Inicializacin y el arranque es una accin que se realiza durante
tal transicin
Como resultado de las actividades en el estado de inicializacin la GUI entra al modo
de Operacin. Cuando desea apagar su PC desencadena un suceso que provoca la
transicin hacia el estado de Apagado y con ello la PC se apaga. La figura muestra el
diagrama de estados que captura los estados y transiciones en la GUI
Encender PC
Inicializacion Apagar
entry/ hacer Arrancar
...
Apagado
Operacion

CONDICIONES DE SEGURIDAD
La anterior secuencia de estados de la GUI deja mucho que desear Por ejemplo: si
deja solo su equipo o si realizara alguna actividad en la que no tocar al ratn o al
teclado podra aparecer un protector de pantallas que evitarla el desgaste de su
pantalla Para decir esto en trminos de cambio de estado si ha pasado cieno tiempo
sin que haya interaccin con el usuario. la GUI har una transicin del estado
Operacin a un estado que no aparece en la figura el estado de Protector de
pantallas .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 opresin de una
tecla o movimiento del ratn provocar una transicin del estado Protector de
pantallas al estado Operacin.
El intervalo de 15 minutos es una condicin de seguridad: cuando se llega a ella se

realiza la transicin. La figura muestra el diagrama de estados de la GUI con el
estado Protector de pantalla y la condicin de seguridad aludida. Vea que la
condicin de seguridad se establece como expresin booleana.
Encender PC
Inicializacion Apagar
entry/ hacer Arrancar
...
Apagado
Operacion
lapso transcurrido
Protector
de Pantalla
Por qu son Importantes los Diagramas de Estados?
Es necesario contar con diagramas de estados dado que permiten a los analistas,
diseadores y desarrolladores comprender el comportamiento de los objeto, de un
sistema Un diagrama de clases y el diagrama de objetos correspondiente slo
muestra lo, aspectos estticos de un sistema Muestran las jerarquas y asociaciones, y
le indican qu son la, operaciones Pero no le muestran los detalles dinmicos de las
operaciones
Los desarrolladores, en particular, deben saber la forma en que lo, objetos se supone
que se comportaran, ya que son ellos quienes tendrn que establecer tales
comportamientos en el software No es suficiente con implementar un objeto los
desarrolladores deben hacer que tal objeto haga algo, Los diagramas de estados se

aseguran que no tendrn que adivinar lo que se supone que harn lo, objetos, Con
una clara representacin del comportamiento del objeto, aumenta la probabilidad de
que el equipo de desarrollo produzca un sistema que cumpla con los requerimientos.
Diagrama de Componentes.
Un componente de software es una parte fsica de un sistema, y se encuentra en la
computadora, no en la mente del analista. Qu puede tomarse como componente?
Una tabla, archivo de datos, ejecutable, biblioteca de vnculos dinmicos, documentos
y cosas por el estilo.
Cul es la relacin entre un componente y una clase? Imagine a un componente

como la personificacin en software de una clase. La clase representa una abstraccin
de un conjunto de atributos y operaciones. Un importante punto por recordar de los
componentes y clases es que un componente puede ser la implementacin de ms de
una clase.
Si el componente se encuentra en una computadora y es la parte funcional del

sistema, para qu preocuparse por l? Tendr que modelar componentes y sus
relaciones 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 tcnicas y La documentacin puedan entender de
qu escribirn.
4. Usted se aliste para volver a utilizar los componentes.
Exploremos el ltimo punto. Uno de los aspectos ms importantes de los componentes

es el potencial que tienen de volver a ser utilizados. Con las necesidades actuales de
los negocios de soluciones rpidas, entre ms rpido presente un sistema para
produccin, mayor ser su competitividad. Si puede crear un componente para un
sistema y puede volver a utilizarlo en otro, usted habr contribuido a esa
competitividad. Tmese el tiempo y esfuerzo para modelar un componente que lo
ayude a que esta reutilizacin pueda llevarse a cabo.
NewComponent
TIPOS DE COMPONENTES
Conforme avance en su carrera como modelador, se encontrar con tres tipos de
componentes:
1. Componentes de distribucin, que conforman el fundamento de los sistemas

ejecutables (por ejemplo, DLL, ejecutables, controles ActiveX y Java Bcans).

2. Componentes para trabajar en e! producto, a partir de los cuales se han creado

los componentes de distribucin (como archivos de base de datos y de cdigo).
3. Componentes de ejecucin, creados como resultado de un sistema en

ejecucin.
Si es usted un usuario de Windows, encontrar ejemplos de los tres tipos de

componentes cuando utilice la ayuda, aunque tal vez no lo sepa. El componente de
distribucin es el archivo .HLP (Archivo de Ayuda): Cuando haga clic en uno, se abrir
el cuadro de dilogo 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 pequea animacin que le
indicar que se est creando un ndice. Un archivo .CNT (tema de contenido) describe
el esquema del contenido. Dado que este archivo le ayuda a crear un componente de
distribucin (puede utilizar la pgina de ndice por siempre), es un componente para
trabajar en el producto. A su vez, el ndice creado se encuentra en un archivo .FTS
(btsqueda de texto completo). Finalmente, la primera vez que abra la ayuda, se crear
un archivo .GID (ndice general), que es resultado de un anlisis del sistema de ayuda
de Windows que agiliza el acceso a los temas del archivo de ayuda. Con ello, los
archivos .FTS y .GID son componentes de ejecucin.
Animacion.html
VBScript <<ActiveX>>
Disposicion
Animacion
<<ActiveX>>
BotonEjecutar
<<ActiveX>>
ImagenEsfera
<<ActiveX>>
BotonDetener
<<ActiveX>>
Cronometro
Esfera <<ActiveX>>
BotonReiniciar
esfera.jpg
<<ActiveX>> <<ActiveX>>
CuadroComb CuadroCom
oCronometro boDistancia

Diagrama de Despliegue.
Es momento de concentrarnos en el hardware. Como podr ver, hemos trascendido
desde los elementos (como las clases) que se encuentran en los anlisis, hasta los
componentes en los equipos de cmputo y al hardware existente.
Claro est que el hardware es un tema primordial en un sistema de varios

componentes. En el mundo actual de la computacin, un sistema podra abarcar
diversos tipos de plataformas en ubicaciones dispersas. Un diseo slido de
distribucin de hardware es bsico para el diseo del sistema. El UML nos da los
smbolos para crear una imagen clara de la forma en que deber lucir el hardware
final.
El elemento primordial del hardware es un nodo, que es un nombre genrico para todo
tipo de recurso de cmputo. Es posible usar dos tipos de nodos: un procesador, el cual
puede ejecutar un componente, y un dispositivo que no lo ejecuta. Normalmente, un
dispositivo (como impresora o monitor) tiene contacto de alguna forma con el mundo
exterior.
En el UML. un cubo representa a un nodo. Deber asignar un nombre para el nodo, y
podr 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 nombre

puede contener tambin el del paquete. Puede dividir al cubo en compartimientos que
agreguen informacin (como componentes colocados en el nodo).
<processor name>
<device name>
preempti ve
<process nam e>

<thread name>


CAPITULO 6
Del Modelo de Objetos al Modelo de Datos.
Refinando el Modelo de Datos.
El Proceso de Normalizacin.
Restricciones segn 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 implementar

directamente un diseo orientado a objetos de una base de datos, o, como extensin
de UML, puede ser referenciado en un diagrama de relacin de entidad para ms
anlisis de relaciones de entidad. Est en el diagrama de relacin de entidad el
cual relaciona entre entidades que pueden ser modeladas basadas en atributos clave.
El diagrama de relacin de entidad lgico ofrece una base desde la cual construir un
diagrama fsico representando las tablas y relaciones actuales de la base de datos
relacional.
Tengamos en cuenta algo, el modelo de objetos no es todava nuestra Base de Datos,

para ello hay que realizar un proceso de refinamiento y verificacin, puesto que las BD
que vamos a utilizar son de tipo relacional, y estas tienen una antigedad de mas de
30 aos (exactamente 39, contando desde 1970)
Lo primero que tendramos que realizar sera convertir el modelo de objetos a un

modelo de datos, para lo cual Rational tiene sus propias especificaciones.

Refinando el Modelo de Datos.

Tengan en cuenta que, esta es la interpretacin que realiza el Rational, nosotros
todava tenemos la potestad de poder mejorar este modelo.
Observemos este detalle, a nivel de objetos la concepcin es vlida, pero es

realmente aplicable en un modelo de dato?
ComprobantePago
fechaEmision : Date
total : Currency
Factura Boleta
nroFactura : String nroBoleta : String
subTotal : Currency
igv : Currency

Fjense como lo interpreta el Rational.
T_ComprobantePago
f echaEmision : DATETIME
total : MONEY
T_ComprobantePago_ID : INT
T_Cliente_ID : INT
<<PK>> PK_T_ComprobantePago10()
<<FK>> FK_T_ComprobantePago4()
<<Index>> TC_T_ComprobantePago15()
1
1
<<Identif y ing>>
<<Identif y ing>>
0..1 0..1
T_Factura T_Boleta
nroFactura : VARCHAR(255) nroBoleta : VARCHAR(255)
subTotal : MONEY T_ComprobantePago_ID : INT
igv : MONEY
T_ComprobantePago_ID : INT <<PK>> PK_T_Boleta15()
<<FK>> FK_T_Boleta8()
<<PK>> PK_T_Factura14() <<Index>> TC_T_Boleta17()
<<FK>> FK_T_Factura7()
<<Index>> TC_T_Factura16()
A nivel de BD no me resulta nada prctico, para este caso, lo mejor seria prescindir de
estas tablas, y manejarlo todo desde la tabla ComprobantePago.

De esta forma, nuestra base de datos tendra la siguiente forma:
Definicin de Base de Datos
Una Base de Datos es un conjunto de datos almacenados en una estructura fsica y

con otra lgica por la cual se relacionan, siendo independiente de las aplicaciones.
Tan importante como los datos, es la estructura conceptual con la que se relacionan
entre ellos. Un sistema de gestin de bases de datos (DBMS) consiste en una
coleccin de datos interrelacionados y un conjunto de programas para acceder a esos
datos. El objetivo primordial de un DBMS es proporcionar un entorno que sea a la vez
conveniente y eficiente para ser utilizado al extraer y almacenar informacin de la
bases de datos. Toda base de datos es una coleccin de datos tendiente a minimizar
la redundancia. Dicha coleccin de datos permite que los mismos se encuentren
1. Interrelacionados
2. Almacenados en conjuntos
3. Sin redundancias innecesarias o perjudiciales
4. Independientes de los programas que los utilizan
Todo modelo de bases de datos debe gozar de las siguientes caractersticas:

Independencia de datos
1. Regulacin de acceso
2. Proteccin de integridad
3. Sin redundancia
4. Facilidad de Ordenamiento

5. Manejo centralizado
Modelo Entidad Relacin ( E-R )
El modelo entidad-relacin se basa en una percepcin de un mundo real que

consiste en un conjunto de objetos bsicos llamados entidades y de relaciones entre
estos objetos.
Est pensado como una notacin orientada al diseo del esquema conceptual, pues
permite la descripcin del esquema conceptual sin preocuparse por problemas de
diseo fsico o de eficiencia.
Se supone que en una etapa posterior, los diagramas entidad-relacin son llevados a
otros modelos, ya sea manual o automticamente. Dentro del modelo entidad relacin
se tienen:
ENTIDADES
Una entidad est representada por un conjunto de atributos. Para cada atributo existe
un rango de valores permitidos, llamado dominio del atributo. Cualquier objeto
distinguible que pueda representarse en la Base de Datos.
Conjunto de entidades
Es un grupo de entidades del mismo tipo. Por ejemplo: un conjunto de alumnos.

RELACIONES
Es una asociacin entre (varias) entidades
Ejemplo: curso es-inscrito por alumno.
Conjunto de relaciones
Es un grupo de relaciones de un mismo tipo.
DIAGRAMA ENTIDAD-RELACIN
La estructura lgica general de una base de datos puede expresarse en forma grfica
por medio de un diagrama entidad relacin, que se integra con los siguientes
componentes:
Simbologa utilizada en el Diagrama Entidad / Relacin

El diagrama E/R se representa de dos formas, una para representar las entidades y
sus relaciones llamada Diagrama o Modelo Entidad Relacin y la otra, para
representar sus atributos, llamada Modelo Relacional:
Terminologa De Bases De Datos
ENTIDAD
Es algo que puede ser identificado por si mismo (personas, lugares, cosas o
conceptos) acerca de la cual se requiere guardar informacin. Un tipo de entidad
representa a una clase de entidades que tienen los mismos atributos.
RELACIN
Es una asociacin entre entidades, o sea es la forma en que se asocian las entidades.
ATRIBUTO
Es la caracterstica 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 relacin.
TIPO DE RELACIONES
Relacin uno a uno ( 1 : 1 )

Una entidad en A esta asociada a lo sumo con una entidad B, y una entidad B esta
asociada a lo sumo con una entidad A.
Relacin uno a muchos ( 1 : M )

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

Una entidad en A esta asociada con un numero cualquiera de entidades en B, y una
entidad en B esta asociada con un numero cualquiera de entidades en A.


Modelo De Datos
Concepto De Modelos De Datos

El principal proceso en el diseo de una base de datos es la creacin de un modelo de
datos. Un modelo de datos es la representacin en escala de la realidad. En este
modelo reflejaremos la estructura de negocio de la organizacin, por medio de datos y
relaciones.
MODELO CONCEPTUAL
El modelo conceptual deber reflejar todas las relaciones lgicas y es totalmente
independiente de su implementacin fsica. Este es un modelo de entidad relacin.
MODELO LGICO
Este modelo es el puente entre el modelo conceptual y el modelo fsico; describe como
se vern los datos. Existen en el diseo de bases de datos 3 modelos lgicos:
1. Jerrquico
2. Red
3. Relacional
MODELO FSICO
El modelo fsico esta construido sobre las bases del modelo lgico y describe como los
datos son almacenados. Este es el nivel mas bajo de abstraccin.
El Proceso de Normalizacin.
Es la tcnica utilizada para dividir las estructuras de datos en pequeas unidades. En
estas unidades, cada atributo es totalmente dependiente de la clave primaria de la
entidad a la cual pertenece.
La normalizacin nos permite:
Minimizar la redundancia
Minimizar el impacto de futuros cambios de datos
Minimiza el mantenimiento de datos

Dependencia Funcional
Es la relacin existente entre dos atributos, por lo que el conocimiento de uno de ellos
determina el valor del otro. Si un elemento A es funcionalmente dependiente de otro
elemento B, queda automticamente definido A. El nombre de un buque es
funcionalmente dependiente de su numero de matricula, pero no es cierto que al
conocer el nombre del buque se conozca su numero de matricula.
Dependencia Funcional Completa
Se produce la dependencia funcional completa cuando un atributo tiene dependencia

funcional 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 dependencia

de otro y este a su vez de un tercero. En este caso, el primero tendr dependencia
transitiva al tercero. Si se tiene los elementos A, B, C, si A es funcionalmente
dependiente de B, y B es funcionalmente dependiente de, entonces A es
transitivamente 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 todos
los atributos que no integran la clave estn en completa dependencia funcional
respecto de la clave.
TERCERA FORMA NORMAL

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




Restricciones segn las Reglas del Negocio.

Toda empresa se basa en sus Reglas de Negocio, esto es, las reglas y/o forma en
que esta se dirige, tanto sus empleados como aquellas otras personas que interactan
con ella, esto tambin se refleja en los documentos que utilizan.
Nosotros no podemos ir a tratar de inventar documentos, ni mucho menos crear

nuevos procesos, nuestra tarea es interpretar la forma de trabajo de ellos en nuestro
sistema, y algo que lo soporte, como sera la BD.
Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las polticas,
normas, operaciones, definiciones y restricciones presentes en una organizacin y que
son de vital importancia para alcanzar los objetivos misionales.
Ejemplos de reglas de negocio: "Un cliente al que facturamos ms de 10.000 al ao es

un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en
pedidos superiores a 3.000".
Las organizaciones funcionan siguiendo mltiples reglas de negocio, explcitas o

tcitas, que estn embebidas en procesos, aplicaciones informticas, documentos, etc.
Pueden residir en la cabeza de algunas personas o en el cdigo fuente de programas
informticos.
En los ltimos aos se viene observando una tendencia a gestionar de forma

sistemtica y centralizada las reglas de negocio, de modo que sea fcil y sencillo
consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un
motor de reglas de negocio. El motor de reglas de negocio es un sistema que se
configura para dar servicio a las necesidades de negocio a travs de la definicin de
objetos y reglas de negocio, el software se rige por flujos que derivan
responsabilidades a los distintos cargos de la empresa repartiendo as el trabajo
equitativamente y cuantitativamente, cuando, quien y donde tiene que desempear la
tarea asignada.
Las reglas de negocio son un medio por el cual la estrategia es implementada. Las
reglas especifican - en un nivel adecuado de detalle - lo que una organizacin debe
hacer.

CAPITULO 7
Del modelo de Datos a la Base de Datos.
El proceso de Migracin a la BD.
Ingeniera Inversa.
Desarrollo de Caso Prctico.

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, todava tenemos la posibilidad de mejorar nuestro

modelo de datos, generado a partir del modelo de objetos.
A continuacin procederemos a crear nuestra base de datos, tomando como base, el

modelo de datos refinado.
El proceso de Migracin a la BD.

El proceso lo iniciaremos, visualizando el modelo de datos, interpretado por el
Rational, seguidamente, haremos clic derecho sobre el schema que contiene el
modelo de datos.

Seguidamente, se activar el asistente para la generacin de la base de datos.
En esta pantalla, podremos seleccionar los tipos de elementos que conformarn

nuestra base de datos, todos ellos pueden ser creados directamente desde el
Rational.

A continuacin, especificaremos el lugar donde se guardar el script de la base de

datos, tener en cuenta que el archivo a generar, por defecto tendr la extensin ddl,
as que mejor le colocamos la extensin sql para identificarla rpidamente.

Finalmente, hacemos clic en el botn Finish, para que el modelo se complete.

Ingeniera Inversa.
El proceso de ingeniera inversa consiste en transformar una base de datos o en su
defecto 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 conexin de datos.
6. seleccionar el schema que proporcionar los datos.

7. seleccione los tipos de elementos que sern recuperados desde la base de

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

base de datos migrada.

11. inmediatamente, crearemos un paquete en el Logical View, con el objetivo de

que 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, luego
Transform to Object Model.
14. de la ventana, seleccionar el paquete que recibir las clases.

15. indicar algn tipo de prefijo para las clases, en este caso, no lo usaremos.
Adicionalmente, dejemos activado el check Include Primary Keys.
16. completada la transformacin, llevar el paquete a Welcome.

17. finalmente, procederemos a arrastrar las clases generadas a un Class

Diagram previamente creado.
Desarrollo de Caso Prctico.

Aqu se proponen los siguientes casos, para que puedan ser comparados con los
resultados que indique su profesor de curso.
1. Se trata de disear la base de datos para la administracin de un consorcio de

hospitales, que permita gestionar datos acerca del personal as como de los
pacientes de los mismos. De cada hospital interesa almacenar adems de su
nombre direccin, telfono, fax, etc.
El personal de los hospitales (del que interesa almacenar su DNI,

nombre, apellidos, direccin y telfono) se divide en personal
administrativo y personal sanitario (dentro de este se distingue a su
vez ATS y mdicos).
Los mdicos tienen una especialidad que interesa conocer (pediatra,
obstetricia, etc.) y slo trabajan, al igual que el resto del personal, en
un hospital.
Los pacientes pueden acudir a varios hospitales del consorcio,
pudiendo ser atendidos por varios mdicos.
Se desea conocer los datos personales de los pacientes que van a
ingresar en el hospital, as como el nmero de seguridad social,

compaa aseguradora, la fecha de admisin y la sala (habitacin)

en la que deben permanecer.
Cada sala se identifica por un nmero de sala dentro de cada hospital y
se desea conocer el nmero de camas de las que dispone cada sala.
Cada admisin de un paciente en el hospital lleva asociada una o
varias fichas de tratamiento en las que se indica la enfermedad y el
mdico que la atiende. Cada tratamiento se identifica por el nombre de
la enfermedad del tratamiento que es nico para cada admisin.
Adems, cada tratamiento da lugar a distintos resultados que permiten
realizar el seguimiento de cada enfermedad de un paciente. El
resultado debe indicar la fecha y hora en que ste tuvo lugar, as como
un comentario (por ejemplo, indicando si el paciente tiene fiebre etc.).
Para un mismo tratamiento slo puede haber un resultado en un mismo
da, a una misma hora.
2. La empresa X desea llevar un control de sus departamentos, empleados y

proyectos segn las siguientes especificaciones:
Se desea conocer el nombre, salario y nmero de la seguridad

social de cada empleado, as como el nombre, fecha de nacimiento
y estudios que cursa, de cada uno de sus hijos. Existen varios tipos de
empleados: directores (encargados de un departamento),
representantes de ventas (se ocupan de la representacin en un
nmero de regiones) e ingenieros (encargados de realizar los proyectos
de la empresa); hay, adems, otros empleados, como secretarios,
auxiliares de laboratorio, etc. Un director no puede ejercer ninguna otra
funcin; sin embargo, un representante de ventas puede desempear
tambin las funciones de un ingeniero y viceversa.
Los distintos departamentos concede becas de estudio a los hijos de
los empleados. Estas becas no estn tipificadas, sino que son ayudas
que se conceden dependiendo del presupuesto del que disponga el
departamento. Se desea conocer la fecha de concesin de cada
beca as como la cuanta de sta. Un ingeniero puede tener varias
especialidades que se desean conocer. De los departamentos se
necesita saber, el nombre, localizacin y empleados que trabajan en
l. Un departamento tiene, como mnimo 2 empleados y como mximo
30 y est al cargo de un nico director. Cada departamento tiene un
director distinto.
Un departamento puede controlar un nmero de proyectos, de los
que se desea conocer su nombre y fecha de comienzo.
En la realizacin de un proyecto no puede haber involucrados ms de 5
ingenieros. Todo ingeniero debe estar asociado a 1 proyecto como
mnimo y a 2 como mximo. En el caso de que un departamento no
tenga ningn proyecto, sus empleados podrn estar trabajando en
proyectos de otros departamentos.


CAPITULO 8
Publicando una Web de Documentacin.
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, una
web con todo nuestro proyecto, de tal manera que podamos compartir con todos los
integrantes del equipo de desarrollo, todos los diagramas que conforman nuestro
proyecto.
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 inicio

de la web.

3. podemos escoger el tipo de formato que van a tener las imgenes, para ello,
hacer clic en el botn Diagrams.
4. una vez realizados todos los cambios, hacer clic sobre el botn Publish, para
que se inicie el proceso de publicacin, una vez terminado, ir a la carpeta/ruta
especificada y ejecutar el archivo de inicio, luego puede ser enviado al Internet
o el sitio web especificado.
NOTA: Una vez completado el proceso de generacin del web, nos ubicamos en la
carpeta donde se guardo el archivo de inicio HTML, el cual se recomienda, tenga el
siguiente nombre: Index.html. Hacemos doble clic sobre el archivo, e inmediatamente
se abrir una ventana con el Browser que tenga instalado en su equipo (Internet
Explorer, Netscape Navigator, Mozilla, Chrome, FireFox, etc.)

5. Seguidamente, seleccionamos el cuadro de navegacin, desde donde

podremos seleccionar el grafico que deseamos ver, haciendo doble clic sobre
el mismo.

6. Luego, nos ubicamos sobre el paquete que deseamos ver, haciendo un clic
sobre l, tan igual como si fuera un hipervnculo.
7. Adicionalmente, se puede ver informacin detallada sobre cada uno de los

objetos que se muestran en el diagrama.

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

N D I C E
Capitulo 1.................................................................................................................... 1
Introduccin al Anlisis y Diseo Orientado a Objetos. ...................................... 2
El Desarrollo de la Estructura del Pensamiento y la Construccin del
Conocimiento ........................................................................................................ 2
La clasificacin es un medio por el cual organizamos el conocimiento. ............. 4
Simulacin. .................................................................................................... 4
Encapsulamiento............................................................................................ 5
Reutilizacion................................................................................................... 5
Conceptos Bsicos ............................................................................................ 6
Encapsulamiento de objetos .......................................................................... 6
Ciclo de Vida del Software. ................................................................................... 9
Sobre los sistemas ...........................................................................................10
Ciclo de Desarrollo ...........................................................................................11
Proceso de desarrollo utilizando UML. .................................................................11
Descripcin del Proceso Actual: El Modelo de Negocios......................................13
Conceptos Fundamentales para Modelar Negocios..........................................13
Estereotipos ..................................................................................................14
Creacin del Modelo en Rational Rose.............................................................15
Capitulo 2...................................................................................................................19
Del Modelo de Negocios al Modelo del Sistema..................................................20
Funcionalidad del Sistema: Use Case Diagram....................................................20
Actor .............................................................................................................21
Caso de uso..................................................................................................21
Tipos de asociacin entre CUs. ...........................................................................22
Comunicacin...................................................................................................23
Generalizacin..................................................................................................24
Inclusin ...........................................................................................................24
Extensin..........................................................................................................25
Como identificar un Actor..................................................................................25
Como identificar un Caso de Uso .....................................................................26
Ventajas de los Casos de Uso ..........................................................................26
Documentando los CUs.......................................................................................27
Creacin del Modelo en Rational Rose.............................................................28
Capitulo 3...................................................................................................................31
Capturando el Modelo de Objetos. .......................................................................32
Uso de: Objetos, Clases, Encapsulamiento, Herencia, Polimorfismo. ..................32
Clase ................................................................................................................32
Atributos ...........................................................................................................32
Operaciones .....................................................................................................33
Notas Adjuntas .................................................................................................34
Diagramas de Clases. ..........................................................................................35
Tipos de Asociacin entre Clases ........................................................................36
Asociacin (Binaria)..........................................................................................36
Clases de Asociacin (Atributos de Enlace)......................................................37
Asociaciones Reflexivas ...................................................................................38
Herencia Y Generalizacin ...............................................................................38
Agregacin / Composicin ................................................................................39

Creacin del Modelo en Rational Rose ............................................................ 39

Capitulo 4.................................................................................................................. 43
Definiendo la Lgica del Sistema. ....................................................................... 44
Utilizando el Diagrama de Actividad. ................................................................... 44
Decisiones ....................................................................................................... 45
Rutas Concurrentes......................................................................................... 45
Definiendo Escenarios (Calles). .......................................................................... 46
resumen ....................................................................................................... 47
Diagramas de Interaccin: Secuencia y Colaboracin......................................... 47
Diagrama de Secuencia................................................................................... 48
objetos ......................................................................................................... 48
mensaje ....................................................................................................... 48
tiempo .......................................................................................................... 49
la secuencia ................................................................................................. 49
Creacin del Modelo en Rational Rose ............................................................ 50
Capitulo 5.................................................................................................................. 55
El comportamiento de los objetos....................................................................... 56
Uso del Diagrama de Estados. ........................................................................... 56
SIMBOLOGA .................................................................................................. 57
SUCESOS Y ACCIONES ................................................................................ 57
CONDICIONES DE SEGURIDAD.................................................................... 58
Por qu son Importantes los Diagramas de Estados? ................................... 58
Diagrama de Componentes................................................................................. 59
Tipos de componentes ................................................................................. 59
Diagrama de Despliegue. .................................................................................... 61
Capitulo 6.................................................................................................................. 63
Del Modelo de Objetos al Modelo de Datos. ....................................................... 64
Refinando el Modelo de Datos. ........................................................................... 65
Definicin de Base de Datos............................................................................ 67
Modelo Entidad Relacin ( E-R )...................................................................... 68
entidades ..................................................................................................... 68
relaciones..................................................................................................... 69
diagrama entidad-relacin ............................................................................ 69
Terminologa De Bases De Datos.................................................................... 70
entidad ......................................................................................................... 70
relacin ........................................................................................................ 70
atributo......................................................................................................... 70
dato.............................................................................................................. 70
Dominio........................................................................................................ 71
tipo de relaciones ......................................................................................... 71
Modelo De Datos ............................................................................................. 73
Modelo Conceptual ...................................................................................... 73
Modelo Lgico.............................................................................................. 73
Modelo Fsico............................................................................................... 73
El Proceso de Normalizacin. ............................................................................. 73
Dependencia Funcional ................................................................................... 74
Dependencia Funcional Completa ................................................................... 74
Dependencia Funcional Transitiva ................................................................... 74
Primera Forma Normal................................................................................. 74
Segunda Forma Normal ............................................................................... 74

Tercera Forma Normal ..................................................................................74

Restricciones segn las Reglas del Negocio. .......................................................78
Capitulo 7...................................................................................................................79
Del modelo de Datos a la Base de Datos. ............................................................80
El proceso de Migracin a la BD. .........................................................................80
Ingeniera Inversa. ...............................................................................................84
Desarrollo de Caso Prctico.................................................................................92
Capitulo 8...................................................................................................................95
Publicando una Web de Documentacin. ............................................................96

Manual Modelamiento de Datos - UML PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Manual Modelamiento de Datos - UML PDF

Caricato da

Copyright:

Formati disponibili

Facultad de Ingeniera Industrial y de Sistemas

Modelamiento de Datos Pg. 1

La Tecnologa Orientada a Objetos es un nuevo enfoque sobre la manera de organizar

Estas estn incluidas en las versiones orientadas a objetos de metodologa para

La TOO se fundamenta en el proceso de construccin y utilizacin de conocimientos,

El Desarrollo de la Estructura del Pensamiento y la

Pg. 2 Modelamiento de Datos

Los conceptos se construyen modelando los aspectos y caractersticas de cualquier

Cuando pensamos en un auto, no visualizamos cada mnimo detalle que lo describa,

En Tecnologa Orientado a Objetos (TO) a los conceptos se les llama objetos, en

Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo;

En los siguientes ejemplos podemos reconocer sus componentes y entender porqu

Un libro, una factura, una organizacin

Continuando con el desarrollo de la estructura del pensamiento, encontraremos que

As construiremos los modelos GATO, CONEJO, y an sin la experiencia directa de la

Modelamiento de Datos Pg. 3

La clasificacin es un medio por el cual organizamos el

Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemas

Despus de los doce aos, en la etapa de las Operaciones combinatorias de la

Un Sistema es un conjunto de componentes (conceptos y modelos, y an de otros

Cuando un sistema tiene por objetivo explicar un hecho o fenmeno, y es aceptado,

En sntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en

A continuacin desarrollaremos los tres ms importantes:

Representacin directa de elementos que "maneja" el usuario en el mundo real.

Pg. 4 Modelamiento de Datos

La encapsulacin es el resultado (o acto) de ocultar, al usuario, los detalles de la

La encapsulacin tiene dos beneficios primordiales:

MODULARIDAD. El cdigo de un objeto puede ser escrito y se puede mantener

ESCONDER LA INFORMACIN ( INFORMATION HIDING ). Un objeto tiene una interfaz con la

Durante la vida de un sistema, las estructuras de datos se mantienen relativamente

Modelamiento de Datos Pg. 5

Anlisis y Diseo Estructurado, se da nfasis a la descomposicin funcional orientada

La ingeniera de software comprende las tcnicas de desarrollo formal para el diseo

Qu son los objetos? Qu no son los objetos?

Ejm.- una factura, una organizacin, una figura en un

Pg. 6 Modelamiento de Datos

Ejm.- Un Cajero Automtico es un ejemplo de objeto. Tiene tipos especficos de

Un mensaje es una solicitud para que se lleve a cabo la operacin indicada y se

Modelamiento de Datos Pg. 7

Ejm.- se puede comunicar con el TV al enviarle solicitudes por medio de un

Pg. 8 Modelamiento de Datos

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

Criterios de descomposicin: Encapsulacin vs. Visibilidad, Reusabilidad y

Ciclo de Vida del Software.

Otro, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehculo

Modelamiento de Datos Pg. 9

control de la computadora (sistemas operativos), la comunicacin de informacin

Quizs algunas caractersticas que debemos de tener en cuenta al momento de

Sobre los sistemas

A su vez, nuestro sistema puede retomar la informacin generada, para devolver

Pg. 10 Modelamiento de Datos

En el Anlisis de Requerimientos se realiza la comprobacin de lo recopilado en el

Todo esto debe de reflejarse en un documento que muestre la situacin actual de la

Proceso de desarrollo utilizando UML.

Modelamiento de Datos Pg. 11

UML se ha diseado realizando

UMIL ayuda al usuario a entender la calidad de la tecnologa y la posibilidad de que

Concurrencia, es un lenguaje distribuido y adecuado a las necesidades de

Pg. 12 Modelamiento de Datos

Descripcin del Proceso Actual: El Modelo de Negocios.

Maneja informacin que le pertenece al negocio.

Conceptos Fundamentales para Modelar Negocios

Modelamiento de Datos Pg. 13