Manual UML - HICOR PDF

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

➢ Ciclo de Vida del Software.
➢ Proceso de desarrollo utilizando UML.
➢ Descripción del Proceso Actual: El Modelo de Negocios.
Walter Hidalgo Córdova Pág. 1

I N T R O D U C C I Ó N A L A N Á L I S I S Y D I S E Ñ O
O R I E N T A D O A O B J E T O S .
Últimamente escuchamos con frecuencia los términos POO, AOO, DOO, BDOO.
Existen evidencias de que la industria informática está dirigiéndose en conjunto a la
Tecnología Orientada a Objetos, alejándose de la tecnología estructurada que ha
prevalecido por más de 20 años. A todo esto le añadimos la proyección del desarrollo
de aplicaciones para Internet, denominados Intranets, Extranets y otros, usando
justamente esta tecnología.
La Tecnología Orientada a Objetos es un nuevo enfoque sobre la manera de organizar

las diferentes piezas que componen un sistema de información (software), como en el
hardware (equipo físico), la base de datos e incluso, en organizaciones todas estas
piezas se denominan "objetos", los cuales son pequeños subsistemas independientes
con datos propios sobre estos elementos y sus clases y tipos, rigen tales propiedades
como herencia, comunicación con lenguajes, polimorfismos y otros que en conjunto
permiten ventajas prácticas.
Estas están incluidas en las versiones orientadas a objetos de metodología para

análisis y diseño de programación y base de datos. Con esto, nos hemos referido a la
tecnología orientada a objetos aplicada a software. Sin embargo este enfoque también
es aplicado en la construcción de hardware, así como también es válido en el diseño
organizativo.
La TOO se fundamenta en el proceso de construcción y utilización de conocimientos,

por lo tanto, objetos y clases son los pasos más importantes en la búsqueda de una
nueva revolución que reemplace, esta vez, parte del esfuerzo que implica la
organización y utilización del conocimiento, del mismo modo que en la primera, las
máquinas reemplazaron el esfuerzo físico del hombre y de los animales, permitiendo el
vertiginoso avance del mundo.
El Desarrollo de la Estructura del Pensamiento y la

Construcción del Conocimiento
Desde muy temprana edad, aproximadamente hasta los siete años, en los
denominados períodos 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 observación y captación 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 características (DATOS), por ejemplo: tiene pelos, cuatro
patas, dos orejas, dos años de edad, es de color blanco, otros. Junto con los datos
también 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.
Pág. 2 Modelamiento de Datos

A las acciones que, cualquier elemento del mundo real, realiza como reacción frente a
un estímulo las denominaremos Operaciones. Algunos comportamientos complejos
son el resultado de la interacción o sucesión de varias operaciones, a éstos los
denominaremos Procesos. Sin embargo en nuestro enfoque, en la mayoría de los
casos y de manera genérica utilizaremos el término OPERACION.
Los conceptos se construyen modelando los aspectos y características 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 abstracción.
Cuando pensamos en un auto, no visualizamos cada mínimo detalle que lo describa,

lo más probable es que tengamos en mente sólo las principales características físicas
y, dependiendo de nuestra experiencia, algunos de los subsistemas importantes como
la caja de cambios, o los sistemas de dirección y frenos.
En Tecnología Orientado a Objetos (TO) a los conceptos se les llama objetos, en

consecuencia, los OBJETOS son MODELOS de entes del mundo real. Los percibimos
porque tienen límites que los esperan de su medio ambiente y de los demás
(IDENTIDAD). Se encuentran en un ESTADO específico en el mundo.
Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo;

pero siempre estará compuesto de DATOS y OPERACIONES.
En los siguientes ejemplos podemos reconocer sus componentes y entender porqué

son objetos:
• Un libro, una factura, una organización

• Una figura en un programa para dibujar
• Una pantalla con la cual el usuario interactúa
• Un campo o nodo en la pantalla de una herramienta CASE
• Un avión, el vuelo de un avión, una reserva de avión
• Un icono en la pantalla, a la que se puede señalar y abrir
Continuando con el desarrollo de la estructura del pensamiento, encontraremos que

aproximadamente a partir de los siete años, en la denominada etapa de las
operaciones concretas, el ser humano aprende a CLASIFICAR (separar y agrupar
objetos de acuerdo a características y comportamientos comunes) y ORDENAR
(establecer criterios de jerarquía que permitan la organización).
Por ejemplo: conocemos a Pluto y Valentino, y descubrimos que también tienen cuatro
patas, ladran, muerden, etc. Y a partir de estos conceptos "concretos" formamos un
nuevo concepto "abstracto" al que denominamos PERRO. Este contiene las
características y el comportamiento de todos los semejantes a Pelusa. En otras
palabras, construimos conceptos tipos o Modelos.
Así construiremos los modelos GATO, CONEJO, y aún sin la experiencia directa de la
observación, TIGRE, ORNITORRINCO, etc. Este proceso es una consecuencia de la
función simbólica (imitación diferida, juegos simbólicos, etc.).

De estos modelos se construirán otros, cada vez más abstractos, que contendrán a los
anteriores, por ejemplo: CARNIVOROS, MAMIFEROS, VERTEBRADOS, ANIMALES,
SERES VIVOS, etc. generándose una estructura muy organizada de CLASIFICACION
Y ORDEN.
La clasificación 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 características de dicho esquema; y por otro,
incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE).
Posteriormente organizamos jerárquicamente en clases y superclases, construyendo
en forma progresiva las grandes CLASIFICACIONES y las OPERACIONES DE
ORDEN.
Después de los doce años, en la etapa de las Operaciones combinatorias de la

inteligencia (Pensamiento formal), el hombre construye SISTEMAS y aún TEORIAS
como producto del raciocinio de Hipótesis (propuestas de solución a interrogantes o
problemas), y de la representación en dimensiones simultáneas.
Un Sistema es un conjunto de componentes (conceptos y modelos, y aún de otros

sistemas) que interactúan, en distintos planos, entre sí para alcanzar objetivos
específicos. 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 más elaborados, permite satisfacer la necesidad vital de la
comunicación.
Cuando un sistema tiene por objetivo explicar un hecho o fenómeno, y es aceptado,

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

que los seres humanos captamos el mundo real y operamos en él. La tecnología de
Objetos intenta simular este hecho y sus fundamentos se sostienen en él.
A continuación desarrollaremos los tres más importantes:
SIMULACIÓN.
Representación directa de elementos que "maneja" el usuario en el mundo real.

Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino de
representarlo directamente. Por ello, en este enfoque, primero se identifican las
características 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 pequeños 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 "cápsula" las estructuras de datos
y los métodos, a esta unidad denominamos OBJETO.
También se simula la manera en que los entes del mundo real se comunican entre sí,
enviándose señales o "mensajes" a los que responden con una conducta o
comportamiento específico, de la misma manera se simulan las clasificaciones,
ordenamiento, organización, e incluso la herencia de los seres vivos.
En síntesis, se trata de actuar de la misma manera en que los humanos, a los que en
informática, en general, se nos denomina usuarios, "manejamos" y operamos el mundo
real.
ENCAPSULAMIENTO.
Utilización del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar
datos y operaciones en forma conjunta se llama ENCAPSULACION.
La encapsulación es el resultado (o acto) de ocultar, al usuario, los detalles de la

implementación de un objeto. El objeto oculta sus datos a otros objetos y sólo permite
accesar a sus datos vía sus propios métodos mediante mensajes específicos, es decir,
se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llama
ocultamiento de información. La encapsulación protege los datos de un objeto de la
corrupción. Si todos los programas pudieran accesar a los datos (como actualmente
sucede con la tecnología estructurada), fácilmente puede corromperse o perderse. La
encapsulación protege los datos del objeto del uso arbitrario y no intencionado. Así la
creación está protegida y la competencia garantizada.
La encapsulación tiene dos beneficios primordiales:
MODULARIDAD. El código de un objeto puede ser escrito y se puede mantener

independiente del código 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 INFORMACIÓN ( INFORMATION HIDING ). Un objeto tiene una interfaz con la

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

estables, mientras que las operaciones sobre dichas estructuras cambian,
dependiendo de situaciones. Por ello en el Análisis y Diseño 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
situación, en la misma forma se procede con los comportamientos. En cambio, en el

Análisis y Diseño Estructurado, se da énfasis a la descomposición funcional orientada
al proceso, en consecuencia, cualquier modificación requiere de una reconstrucción,
normalmente, a partir de cero.
Conceptos Básicos
La ingeniería de software comprende las técnicas de desarrollo formal para el diseño

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
programación 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, tamaño. 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 "reúne" sus atributos, funciones y estados en una unidad
autocontenida, el encapsulamiento usa información oculta. Algunas partes del objeto
son visibles a todas es decir, públicas.
La función "steering wul" en el objeto "Carro" representa una interface pública la cual
"enciende" el carro. Algunas partes del objeto son ocultas (privadas), "encender" es
únicamente visible a la función "steering wheel", por lo tanto privada.
La información oculta permite al detalle del objeto cambiar sin afectar los programas
que usan la clase, la información oculta elimina los problemas que se presentan al
modificar el código y promueve la reutilización del código.
Objeto
Es cualquier cosa real o abstracta, acerca de la cual
almacenamos datos y los métodos que controlan
dichos datos.
Ejm.- una factura, una organización, una figura en un

programa como Corel Draw, una pantalla con la que
interactúa un usuario, un campo o nodo de la pantalla
de una herramienta CASE, una avión, todo un plano
de ingeniería, el proceso para llenar un
pedido, etc. Daniel Ramos también sería un objeto, por las características que posee.

Tipo de Objeto
Es una categoría de un objeto; y un objeto es una instancia de un tipo de objeto.
Ejm.- empleado se aplica a los objetos que son personas empleadas por una
organización; algunas instancias de empleado podrían ser Viviana Rivasplata, Maju
Mantilla, etc.
Métodos
Especifican la forma en que se controlan los datos de un objeto. Los métodos en un
tipo de objeto sólo hacen referencia a las estructuras de datos de ese tipo de objeto.
Un objeto es entonces una cosa cuyas propiedades están representadas por tipo de
datos y su comportamiento por métodos.
Ejm.- Un método asociado con el tipo de objeto factura podría ser aquél que calcule el
total de una factura. Otro podría transmitir la factura a un cliente, etc.
Encapsulado
El empaque conjunto de
datos y métodos se llama
encapsulado. El objeto
esconde sus datos de los
demás objetos y permite
el acceso a los datos
mediante sus propios
métodos, esto recibe el
nombre de ocultamiento
de la información. El
encapsulado evita la
corrupción de los datos
de un objeto,
protegiéndolos del uso
arbitrario y no pretendido.
Ejm.- Un Cajero Automático es un ejemplo de objeto. Tiene tipos específicos de

comportamiento. Un “cajero globalnet” es un tipo de objeto y un cajero automático
individual sería una instancia de dicho objeto. Todas los Cajeros Automáticos del
mismo tipo tienen los mismos métodos. Los cajeros contienen muchos componentes
complejos, la mayoría de los cuales también 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 operación. El mensaje que constituye la solicitud contiene el nombre del objeto, el
nombre de una operación y, a veces, un grupo de parámetros.
Un mensaje es una solicitud para que se lleve a cabo la operación indicada y se

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

Una solicitud invoca una operación específica, con uno o más objetos como
parámetros.
Ejm.- se puede comunicar con el TV al enviarle solicitudes por medio de un

sintonizador de control remoto. Responde el aparato mediante determinada acción y
presenta las respuestas en pantalla.
Clase
El término clase se refiere a la implantación en software de un tipo
de objeto. Especifica una estructura de datos y los métodos Ave
operativos permisibles que se aplican a cada uno de sus objetos. El
método es parte de la clase, pero no parte del objeto. El método ni
siquiera podría ser parte de la clase; pero podría ser parte de la
clase de mayor nivel en la jerarquía de clases.
Ejm.- una clase empleado incluiría datos del seguro social, puesto, salario, extensión
telefónica, etc. Además, cada clase define un conjunto de operaciones permisibles que
permiten el acceso y modificación de los datos del objeto.
Herencia Av e
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 Fa is a n Pa t o Ga l lin a
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, capitán, mayor, etc.
Herencia de Clase
Es una implantación de la generalización. La generalización 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 reutilización por parte de
sus subclases.
Polimorfismo
Se aplica a una operación que adopta varias formas de implantación. Una de las
ventajas del polimorfismo es que se puede hacer una solicitud de una operación sin
conocer el método que debe ser llamado. Estos detalles quedan ocultos para el
usuario; la responsabilidad descansa en el mecanismo de selección de la implantación
OO.

Abstracción
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 abstracción elimina
algunas distinciones para que podamos ver los aspectos comunes entre los objetos.
Se debe considerar lo siguiente:
• Características esenciales que distinguen un objeto de otro.
• Dependen del dominio del problema.
• Dependen del Observador.
• Definen conceptos.
• Distintos tipos: "Entidades" y "Asociaciones".
Un protocolo denota la manera en que un objeto puede actuar y reaccionar.
Generalización
Es el acto o el resultado de distinguir un concepto que es más general que otro. La
generalización nos permite examinar si los conceptos tienen algo en común.
Evento
Es un cambio en el estado de un objeto. En el análisis orientado a objetos el mundo se
describe en términos 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 módulos son
la división física de la abstracción lógica. Hay que considerar lo siguiente:
• Criterios de descomposición: Encapsulación vs. Visibilidad, Reusabilidad y

Segmentación; y Necesidades no técnicas.
• Los diseñadores lógicos y físicos involucran decisiones independientes.
Ciclo de Vida del Software.

Para iniciar, debemos de tener en cuenta que, el software, es un elemento del sistema
que es de tipo lógico, a diferencia del hardware que es de tipo físico.
Otro, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículo

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

control de la computadora (sistemas operativos), la comunicación de información
(redes) y la creación y control de otros programas (herramientas de software).
Quizás algunas características que debemos de tener en cuenta al momento de

desarrollar un software, son las siguientes:
• El software se desarrolla, no se fabrica en un sentido clásico.
• El software no se estropea o malogra, pero si se puede deteriorar según las
actualizaciones que este pudiera tener.
• Aunque hoy en día se habla de construir ensamblados o componentes, la
mayoría del software se construye a medida.
• El software puede aplicarse en cualquier situación en la que se haya definido
previamente un conjunto específico de pasos procedimentales (es decir, 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
información son factores importantes a considerar para determinar la naturaleza
de una aplicación de software. El contenido se refiere al significado y a la forma
de la información de entrada y salida.
Sobre los sistemas
Algo que debemos de tener en cuenta es, que todo sistema a desarrollar, por mas
pequeño o grande que sea, siempre va a requerir de datos para poder funcionar, estos
serán procesados, para poder obtener la información.
A su vez, nuestro sistema puede retomar la información generada, para devolver

información mas refinada, en un proceso conocido como Feedback o
Retroalimentación, el cual es posible por el uso de las Bases de Datos.

Ciclo de Desarrollo
Hay que entender que, esto es un proceso, ahora, debemos de marcar un punto de
partida para todo este desarrollo, y ese es cuando el especialista en desarrollo de
sistemas interactúa (Analista) con el Cliente (el cual, habitualmente es el Dueño de la
Empresa, el Gerente General o algún 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 información
En el Análisis de Requerimientos se realiza la comprobación de lo recopilado en el

Estudio Preliminar, através de entrevistas que se realizaran al personal del área
involucrada, de tal manera que se puedan conocer sus requerimientos reales, las
funciones que desempeñan y el procedimiento que siguen, así como los documentos
que utilizan.
Todo esto debe de reflejarse en un documento que muestre la situación 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 más que un lenguaje de
programación. Aunque en su génesis se parece a C++ o a Java, en realidad se ha
diseñado 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.
Modelamiento de Datos Pág. 11

UML se ha diseñado realizando
combinaciones de una gran cantidad
de estándares, si bien se rige a
través de tres metodologías
procedentes de la colaboración de
los tres creadores de UML, que son:
James Rumbaugh, Grady Booch e
Ivar Jacobson, así como del
análisis y estudio de alrededor de 20
métodos estándares que a su vez se
han integrado en otro estándar, en
este caso, UML; esta fue una gran
iniciativa de los tres creadores que
pusieron las especificaciones de
UML a la consideración de la
comunidad informática mundial,
antes de su publicación. El diseño 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 todavía en el proceso de
estandarización con la nueva versión 2.0. Al contrario que HTML/XML que son
lenguajes de marcación (markup), UML es un lenguaje para modelar; que es el
procedimiento que emplean los ingenieros para el diseño de software antes de pasar a
su construcción, al igual que sucede con cualquier producto manufacturado o fabricado
en serie.
UMIL ayuda al usuario a entender la calidad de la tecnología y la posibilidad de que

reflexione antes de invertir y gastar grandes cantidades en proyectos que no estén
seguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construcción
de las piezas que constituirán el modelo.
Sin embargo, desde el punto de vista puramente tecnológico, UML tiene una gran
cantidad de propiedades que han sido las que, realmente, han contribuido a hacer de
UML el estándar de facto de la industria que es en realidad. Algunas de las propiedades
de UML como lenguaje de modelado estándar son:
• Concurrencia, es un lenguaje distribuido y adecuado a las necesidades de

conectividad actuales y futuras.
• Ampliamente utilizado por la industria desde su adopción por OMG.
• Reemplaza a decenas de notaciones empleadas con otros lenguajes.
• Modela estructuras complejas.
• Las estructuras más importantes que soportan tienen su fundamento en las
tecnologías orientadas a objetos tales como: objetos, clases, componentes y
nodos.
• Emplea operaciones abstractas como guía para variaciones futuras, añadiendo
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 máquinas.

Descripción del Proceso Actual: El Modelo de Negocios.
La importancia que tiene el elaborar un modelo de negocios, antes de modelar el
sistema informático, es el siguiente:
• Maneja información que le pertenece al negocio.

• Será utilizado en organizaciones que ejecutan procesos del negocio cada vez
más automatizable.
• Se adaptará al entorno de la organización que lo usará.
• Para identificar con facilidad donde están los problemas y oportunidades de
crecimiento y mejora.
• Porque desde la perspectiva de los sistemas, no es posible automatizar
procesos que no estén claramente definidos.
Conceptos Fundamentales para Modelar Negocios
Proceso
• Conjunto de actividades que emplean un insumo.
• Agregan valor.
• Suministran un producto a un consumidor.
Proceso de Negocio
• Conjunto o grupo de tareas o actividades.
• Secuencia u orden lógico.
• Emplean recursos de la organización.
• Ofrece resultados de interés a alguien.
• Apoya algún objetivo de la organización.
Área Funcional
• Grupo de Trabajo.
Objetivos
• Comprender la estructura y la dinámica de la organización objetivo.

• Comprender los problemas actuales del organización objetivo e identificar el
campo de acción incluido en donde hay un potencial de crecimiento y mejoras.
• Evaluar el impacto del cambio en la organización objetivo.
• Asegurar que los clientes, usuarios finales, desarrolladores y otros roles tengan
un entendimiento común de la organización objetivo.
• Obtener, de forma preliminar, los requerimientos del sistema que necesita la
organización objetivo.
ESTEREOTIPOS
Actividades del Modelo de Negocio.

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

El caso de uso del negocio, identifica un proceso específico 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
comparación 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

algún tipo de responsabilidad dentro del área de estudio, vale
decir, que realiza algún tipo de tarea dentro de la misma, o tiene
alguna responsabilidad.
Creación 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,
mostrándose la siguiente pantalla.
2. para trabajar con un modelo de análisis, seleccionaremos “Rational Unified

Process”.

3. una vez que nos encontremos en la pantalla principal, pondremos especial
atención 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, debiéndose 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 asociación entre CU’s.
➢ Documentando los CU’s.

D E L M O D E L O D E N E G O C I O S A L M O D E L O
D E L S I S T E M A .
Una vez que hemos logrado interpretar la forma de trabajo de la empresa, 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

información, haremos uso del diagrama de casos de uso.
Funcionalidad del Sistema: Use Case Diagram.

La vista de casos de uso captura el comportamiento de un sistema, de un subsistema,
o de una clase, tal como se muestra a un usuario exterior. Reparte la funcionalidad 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 interacción con los actores como secuencia de mensajes entre el
sistema y uno o más actores. El término actor incluye a los seres humanos, así como a
otros sistemas informáticos y procesos.

ACTOR
Un actor es una idealización de una persona externa, de un proceso, o
de una cosa que interactúa 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 ejecución, un usuario físico puede
estar limitado a los actores múltiples dentro del sistema. Diferentes
usuarios pueden estar ligados al mismo actor y por lo tanto pueden
representar casos múltiples de la misma definición de actor.
Cada actor participa en uno o más casos de uso. Interactúa con el caso de USO (y por
lo tanto con el sistema o la clase que posee el caso de uso), intercambiando mensajes.
La implementación interna de un actor no es relevante en el caso de uso; un actor
puede ser caracterizado suficientemente por un conjunto de atributos que definen su
estado.
Los actores pueden ser definidos en jerarquías de generalización, en las cuales una
descripción abstracta del actor es compartida y aumentada por una o más
descripciones específicas del actor.
Un actor puede ser un ser humano, otro sistema informático, o un cierto proceso
ejecutable. Se dibuja a un actor como una persona pequeña 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 más actores. El propósito de un caso
de uso es definir una pieza de comportamiento coherente, sin
revelar la estructura interna del sistema. La definición de un caso de uso incluye todo
el comportamiento que implica: las líneas 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 ejecución de cada caso de uso es independiente de las demás,

aunque una implementación de casos de uso puede crear dependencias implícitas
entre ellas, debido a los objetos compartidos. Cada Caso de Uso representa una pieza
ortogonal de la funcionalidad, cuya ejecución se puede mezclar con la ejecución de
otros casos de uso.
La dinámica de un caso de uso se puede especificar por las interacciones de UML,

mostradas como diagramas de estado, diagramas de secuencia, diagramas de
colaboración, 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 múltiples colaboraciones y, por lo tanto, en múltiples casos de uso.
En el nivel de sistema, los casos de uso representan el comportamiento externo de
todo sistema tal y como se muestra a los usuarios exteriores. Un caso de uso es como

una operación de sistema, una operación invocada por un usuario exterior. Sin
embargo, a diferencia de una operación, un caso de uso puede continuar recibiendo la
entrada de sus actores durante su ejecución. Los casos de uso también se pueden
aplicar internamente a unidades más pequeñas 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 desempeñen ciertos roles dentro del sistema. Una clase puede tener
más de un caso de uso.
Un caso de uso es una descripción lógica de una parte de funcionalidad del sistema.
No es una construcción manifiesta en la implementación de un sistema. En su lugar,
cada caso de uso se debe corresponder con las clases que implementan un sistema.
El comportamiento del caso de uso se corresponde con las transiciones y operaciones

de las clases. Ya que una clase puede desempeñar roles múltiple en la implementación
de un sistema, puede por lo tanto realizar porciones de múltiples casos de uso. Una
parte de la tarea del diseño es encontrar las clases de implementación que combinen
claramente los roles apropiados para implementar todos los casos de uso, sin introducir
complicaciones innecesarias. La implementación de un caso de uso se puede modelar
como un conjunto de una o más colaboraciones. Una colaboración es una realización
de un caso de uso.
Un caso de uso puede participar en varias relaciones, además de poderse asociar con
actores.
Un caso de uso se dibuja como una elipse con su nombre dentro o debajo de ella. Se
conecta por líneas con trazo continuo con los actores que se comunican con ella.
Tipos de asociación entre CU’s.

Un caso de uso es una descripción lógica de una parte de funcionalidad del sistema.
Un caso de uso puede participar en varias relaciones con otros casos de uso, además
de poderse asociar con actores.
Aunque cada instancia de un caso de uso es independiente, la descripción de un caso

de uso se puede descomponer en factores de otros casos de uso más simples. Esto
es similar a la manera en que la descripción de una clase se puede definir
incrementalmente a partir de la descripción 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 relación de inclusión. 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 también definir como una extensión incremental de un caso
de uso base. Esto se llama relación de extensión. 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 semántica; que es el caso de uso base instancia
do, no los casos de uso de la extensión.

Las relaciones de inclusión y extensión se dibujan como flechas de líneas discontinuas
con la palabra clave «include» o «extend». La relación de inclusión apunta al caso de
uso a ser incluido; la relación de extensión señala el caso de uso que se extenderá.
Relación Función Notación
Solo se produce entre un Actor y un

Comunicación
Caso de Uso.
La inserción de comportamiento
Extensión adicional en un CU base que no tiene
conocimiento sobre él.
Relación entre un CU general y un CU

Generalización más específico, que hereda y añade
propiedades.
Inserción de comportamiento adicional

Inclusión en un CU base, que describe
explícitamente la inserción.
Comunicación
Las instancias de actores se comunican con el sistema mediante el envío y recepción

de instancias de mensajes (señales y llamadas) desde y hacia instancias de casos de
uso, y en el nivel de realización, 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 señales que

envía 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 señales que un Caso de uso sea capaz de enviarle y no
debe mandarle al caso de uso señales 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 también tener una lista de atributos
que caracterice su estado.

Generalización
Pueden existir semejanzas entre dos o más actores; esto

es, pueden comunicarse COn el mismo conjunto de
casos de uso de la misma manera. Esta semejanza se
expresa mediante la generalización 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
sustitución). Un descendiente incluye los atributos y
operaciones de sus antecesores.
Inclusión
La relación de inclusión conecta un caso de uso base con un caso de uso incluido. El
caso de uso incluido que figura en esta relación no es un clasificador instanciable
independientemente. Lo que hace es describir explícitamente 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 múltiples
relaciones de inclusión. El mismo caso de uso incluido se puede incluir en múltiples
casos de uso base. Esto no indica ninguna relación entre los casos de uso base. Puede
haber, incluso, múltiples relaciones de inclusión entre el mismo caso de USO incluido
y casos de uso base, siempre y cuando cada inserción se haga en una posición
diferente de la base.
El caso de uso incluido puede acceder a atributos o a operaciones del caso de uso
base. La inclusión representa un comportamiento encapsulado que, potencialmente,
puede reutilizarse en múltiples casos de uso base. El caso de uso base ve al caso 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.
Obsérvese que se pueden anidar las adiciones (sea cual fuere su clase). Por tanto,
una inclusión puede servir como base para otra inclusión, extensión o generalización
posterior.

Extensión
Una relación desde un caso de uso extensor a un caso de uso base, que especifica
cómo 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 relación, no es necesariamente un clasificador

instanciable separado. Consiste en uno o más 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 localización separada en el caso de uso base. La relación de
extensión tiene una lista de los nombres de los puntos de extensión, igual en número
al número de segmentos en el caso de uso extensor. Cada punto de extensión se debe
definir en el caso de uso base.
Un caso de uso extensor en una relación de extensión 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 implícitamente el comportamiento del caso de uso base.
Como identificar un Actor
1. ¿Quién está interesado en un requerimiento concreto?

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

Como identificar un Caso de Uso
1. ¿Cuáles son las tareas y responsabilidades de cada actor?

2. ¿Algún actor creará, almacenará, cambiará, borrará o leerá información del
sistema?
3. ¿Qué casos de uso crearán, almacenarán, cambiarán, borrarán o leerán esta
información?
4. ¿Es necesario que un Actor informe al sistema sobre cambios externos?
5. ¿Es necesario que un Actor sea informado sobre ciertas incidencias del
sistema?
6. ¿Qué Casos de Uso darán soporte y mantendrán el sistema?
7. ¿Pueden ser realizados por los CU todos los requerimientos funcionales
documentados?
Ventajas de los Casos de Uso
1. Lenguaje de comunicación entre usuarios y desarrolladores.

2. Comprensión detallada de la funcionalidad del sistema.
3. Acotación precisa de las habilidades de los usuarios.
4. Gestión de riesgo más eficiente para gobernar la complejidad.
5. Estimación más exacta para determinar tiempo, recursos y prioridades en la
dosificación de esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traducción de requerimientos en código
ejecutable.
7. Mayor control para mantener las sucesivas revisiones de los programas.
8. Certificación contractual cliente-desarrollador.
9. Documentación orientada al usuario: help, manual de procedimientos, reglas
del negocio.
10. Documentación orientada al administrador del sistema: soporte de
mantenimiento.

Documentando los CU’s.
Los casos de uso representan funcionalidades que va a tener el sistema, sin embargo,
estos agrupan varias tareas o actividades, razón por la cual es necesario describirlas,
con el objetivo de que los demás miembros del proyecto, puedan conocer los detalles
de cada una de las tareas y/o responsabilidades que los actores podrán hace r posible
con el uso del sistema.
A continuación, se procederá a describir el CU “Identificando Riesgos”, tener en cuenta

que esta información, luego se observará en el diagrama de Actividad, el cual mostrará
la lógica que tiene el sistema.

Para poder retomar nuestro proyecto de sistema, lo primero que haremos será abrir 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 diseñar nuestro modelo.

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

C A P T U R A N D O E L M O D E L O D E O B J E T O S .
A continuación conjugaremos las características del UML con los conceptos de la
orientación a objetos.
Aquí refinarán su conocimiento de la orientación a objetos al tiempo que aprendemos

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

Polimorfismo.
Clase
En el UML un rectángulo es el símbolo que representa una clase. El nombre de la clase

es por convención una palabra con la primera letra en mayúscula y normalmente se
coloca en la parte superior del rectángulo. Si el nombre de su clase consta de dos
palabras únalas e inicie cada una con mayúscula.
Otra estructura del UML el paquete, puede jugar un papel en el nombre de la clase 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 "GuíaCompra" es parte de paquete llamado "DocumentosContables",

podrá darle el nombre " DocumentosContables:: GuíaCompra ", 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 característica 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 ningún atributo Por convención, si el atributo
consta de una sola palabra se escribe en minúsculas; por otro lado, si el nombre
contiene más de una palabra cada palabra será unida a la anterior y comenzará c on
una letra mayúscula, a excepción de la primer palabra que comenzará en minúscula

La lista de nombres de atributos iniciará luego de una línea que la separe del nombre
de la clase como se aprecia en la figura.
Todo objeto de la clase tiene un valor específico en cada atributo. La figura le muestra
un ejemplo. Observe que el nombre de un objeto inicia con una letra minúscula y está
procedido de dos puntos que a su vez están procedidos del nombre de la clase y todo
el nombre está subrayado.
El UML le da la opción de indicar información adicional de los atributos. En el símbolo

de la clase podrá especificar un tipo para cada valor del atributo. Entre los posibles
tipos se encuentran cadena (string) número 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. También podrá indicar un
valor predeterminado para un atributo La figura le muestra las formas de establecer
atributos.
Operaciones
Una operación 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 operación se escribe en minúsculas si consta de una
sola palabra.
Si el nombre constara de más de una palabra únalas e

inicie todas con mayúscula exceptuando la primera. La
lista de operaciones se inicia debajo de una Línea que
separa al de las operaciones de los atributos como se
muestra en la figura.
Así como es posible establecer información adicional de

los atributos, también lo es en lo concerniente a las
operaciones En los paréntesis que preceden al nombre de
la operación podrá mostrar el parámetro con el que

funcionará la operación junto con su tipo de función, que es un tipo de operación,
devuelve un valor luego que finaliza su trabajo. En una función podrá mostrar el tipo de
valor que regresará,
Estas secciones de información acerca de una operación se conocen como la firma de

la operación.
Si usted tiene una larga lista de atributos u operaciones podrá utilizar un estereotipo
para organizarla de forma que sea más comprensible. Un estereotipo es el modo en
que el UML le permite extenderlo es decir crear nuevos elementos que son específicos
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 paréntesis
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 información suficiente para describir una clase de forma inequívoca
Una manera más formal es agregar una restricción un texto libre. Bordeado 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 información a una clase en la figura de notas
adjuntas
Con frecuencia agregará una nota a un atributo u operación. La figura le muestra una
nota que se refiere a una norma gubernamental que indica dónde encontrar la manera
en que se generan los números 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 tecnología de un área del conocimiento conforme hable
con los clientes, analice su área de conocimiento y diseñe sistemas de computación
que resuelvan los problemas de dicha área, comprenderá la terminología y modelará
los términos como clases en el UML.
En sus conversaciones con los clientes preste atención a los sustantivos que utilizan
para describir las entidades de sus negocios; ya que dichos sustantivos se convertirán
en las clases de su modelo También preste atención a los verbos que escuche dado
que constituirán las operaciones de sus clases .Los atributos surgirán como
sustantivos relacionados con los nombres de la clase. Una vez que tenga una lista
básica de las clases pregunte a los clientes que es lo que cada clase hace dentro
del negocio. Sus respuestas le indicarán 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
conversación podría surgir como sigue:
Analista: "Entrenador, ¿de que se trata el juego?

Entrenador: "Consiste en anotar el balón a través de un aro, conocido como cesto, y
hacer una mayor puntuación que el oponente, Cada equipo consta de cinco jugadores
dos defensas dos delanteros y un central. Cada equipo lleva el balón al cesto del
equipo oponente con el objetivo de hacer que el balón sea encestado."
Analista: "¿Cómo se hace para llevar el balón al cesto?"
Entrenador: "Mediante pases y dribles. Pero el equipo tendrá que encestar antes 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 balón luego de que un equipo toma
posesión de él."
Analista: "¿Cómo funciona el puntaje?"
Entrenador: "Cada canasta vale dos puntos, a menos que el tiro baya sido hecho
detrás de la Línea de los tres puntos En tal caso, tres puntos Un tiro libre contará como
un punto. A propósito, un tiro libre es la Penalización que paga un equipo por cometer
una infracción Si un jugador infracciona a un oponente. se detiene el juego y el
oponente puede realizar diversos, tiros a! cesto desde la Línea de tiro libre."
Analista: "Hábleme más acerca de lo que hace cada jugador,"

Entrenador: "Quienes juegan de defensa son, en general, quienes realizan la 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 también se conoce como 'poste')
Se supone que Iodos los jugadores pueden burlar, pasar, tirar y rebotar los delanteros
realizan la mayoría 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
¿cuánto 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 duración es de 40 minutos, divididos en dos mitades de 20 minutos,
Un cronómetro del juego lleva un control del tiempo restante"

La plática podría continuar, pero hagamos una pausa y veamos con qué contamos,
Aquí hay varios sustantivos que ha descubierto balón, cesto, equipo, jugadores,
defensas, delanteros, cesto (o poste), tiro, lapso para tirar, línea de los 3 puntos, tiro
libre, infracción, línea de tiro libre, cancha, cronómetro del juego y los verbos: tirar,
avanzar, driblar (o burlar), pasar, infraccionar, rebotar. También cuenta con cierta
información adicional respecto a algunos de los sustantivos (como las estaturas
relativas de los jugadores de cada posición. las dimensiones de la cancha, la cantidad
total de tiempo en un lapso de tiro y la duración de un juego)
Finalmente, su propio sentido común podría entrar en acción para generar ciertos
atributos por usted mismo. Usted sabe, por ejemplo, que el balón cuenta con ciertos
atributos, como volumen y diámetro
A partir de esta información, 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 también muestra las responsabilidades. Podría usar este diagrama como
fundamento para otra., conversaciones con el entrenador para obtener mayor
información.
Jugador Balon Equipo

nombre volumen
estatura diametro
peso
driblar()
dribalrBalon() tirar()
pasarBalon() pasar() Cancha
tirarBalon() avanzar()
rebotar()
infraccionarOponente()
TiroLibre Defensa Cesto Infraccion
Tipos de Asociación 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:
Asociación (Binaria)
Cuando una clase se vincula con otra clase, para ello se trazará una línea que la una,
donde, adicionalmente se indicará la multiplicidad entre ellos.

Cuando una clase se asocia con otra cada una de ellas juega un papel dentro de tal
asociación. Puede representar estos papeles en el diagrama escribiéndolos cerca de
la Línea que se encuentra junio ala clase que juega el papel correspondiente.
Clases de Asociación (Atributos de Enlace)
Una asociación al igual que una clase puede contener atributos y operaciones.
Cuando este sea el caso usted tendrá una clase de asociación.
Puede concebir a una clase de asociación de la misma forma en que lo haría con una
clase estándar y utilizará una línea discontinua para conectarla a la línea de asociación
Una clase de asociación puede tener asociaciones con otras clases
Factura
nroFactura Producto
fechaEmision nombre
0..* 1..*
subTotal
precioVenta
igv
stock
Total
fechaCancelado
DetalleFactura
cantidad
importe
Tener en cuenta que, esta asociación solo se produce cuando existe una relación con
multiplicidad de muchos a muchos, y adicionalmente, existan atributos que describan
la relación.

Asociaciones Reflexivas
En ocasiones una clase es una asociación 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 más OcupanteAutomovil quienes jugarán
el papel de pasajeros Esto lo representará mediante el trazo de una Línea de
asociación a partir del rectángulo de la clase hacia el mismo rectángulo de la clase. y
en la línea de asociación indicará los papeles nombre de la asociación dirección de la
asociación y multiplicidad corno ya lo hizo antes La figura le presenta este ejemplo:
+conductor 1 OcupanteAutomovil
0..*
+pasajero
conduce
Herencia Y Generalización
Uno de los sellos distintivos de la orientación a objetos es que captura uno de los
mayores aspectos del sentido común en cuanto a la vida diaria: si usted conoce algo
de una categoría de cosas automáticamente sabrá algunas cosas que podrá
transferir a otras categorías Si usted sabe que algo es un electrodoméstico, ya sabrá
que contará con un interruptor, una marca y un numero de serie
La jerarquía de la herencia no tiene que finalizar en dos niveles: una clase secundaria
puede ser principal para otra clase secundaria Un Mamífero es una clase secundaria
de Animal y Caballo es una clase secundaria de Mamífero 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 podría listar si pensara en
ello por algunos instantes.

VehiculoTransporte
Terrestre Maritimo Aereo
Automovil Tren Barco Avion
La orientación a objetos se refiere a esto como herencia. El UML también lo

denomina generalización. 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 más genérica que la secundaria (o hija).
Agregación / Composición
Un objeto no es algo compacto ni indivisible, por el contrario, el objeto puede 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 razón de ser, se dice que la relación es por Agregación.
Automóvil Radio
Pero cuando el objeto pierde sus facultades o esencia ante la ausencia de algún otro
objeto, entonces se dice que la relación es por Composición.
Automóvil 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.

Pág. 42 Taller de Modelamiento de Software
CAPITULO 4
➢ Definiendo la Lógica del Sistema.
➢ Utilizando el Diagrama de Actividad.
➢ Definiendo Escenarios.
➢ Diagramas de Interacción: Secuencia y Colaboración.

D E F I N I E N D O L A L Ó G I C A D E L S I S T E M A .
Ahora veremos un tipo de diagrama que podría parecerle familiar, este diagrama le
muestra los pasos en una operación o proceso
En este tema se tratarán los siguientes temas:
• Que es un diagrama de actividades

• Aplicación de los diagramas de actividades
• Marcos de responsabilidad
• Adiciones al panorama
Si alguna vez ha tomado algún curso básico de programación, ya conocerá los

diagramas de flujo Siendo uno de los primeros modelos visuales que se aplicaron a la
computación el diagrama de flujo muestra una secuencia de pasos, procesos, puntos
de decisión 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 código con sus diversas características 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 decisión y bifurcaciones es útil para mostrar lo que ocurre en un proceso de
negocios u operación. Los encontrará como parte integral del análisis de un sistema
Utilizando el Diagrama de Actividad.

Para empezar, un diagrama de actividades ha sido diseñado
para mostrar una visión simplificada de lo que ocurre durante
una operación o proceso es una extensión 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 rectángulo con las

esquinas redondeadas (más angosto y ovalado que la NewActivity2
representación del estado). El procesamiento dentro de una
actividad se lleva a cabo y. al realizarse se continúa con la
siguiente actividad Una flecha representa la transición 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).

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

los pasos, puntos de decisión 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 extensión 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 rectángulo con esquinas redondeadas, más ovalados en
apariencia que la representación de un estado. El diagrama de actividades utiliza los
mismos símbolos que el de estados para los puntos de inicio y final.
Diagramas de Interacción: Secuencia y Colaboración.

Los diagramas de interacción, permiten mostrar como los objetos interactúan 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
rectángulos con nombre (subrayado), mensajes representados por líneas continuas
con una punta de flecha y el tiempo representado como una progresión vertical
OBJETOS
Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha
y se acomodan de manera que simplifiquen al diagrama La extensión que esta debajo
(y en forma descendente) de cada objeto será una línea discontinua conocida como
la Línea de vida de un objeto. Junto con la línea de vida de un objeto se encuentra un
pequeño rectángulo conocido como activación, el cual representa la ejecución de una
operación que realiza el objeto. La longitud del rectángulo se interpreta como la
duración de la activación. La figura muestra un objeto, su línea de vida y su activación.
MENSAJE
Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a la de

otro .Un objeto puede envía un mensaje a si mismo es decir desde su Línea de vida
hacia su propia línea de vida Un mensaje puede ser simple, sincrónico o asincrónico
Un mensaje simple es la transferencia del control de un objeto a otro. Si un objeto envía

un mensaje sincrónico esperara la respuesta a tal mensaje antes de continuar con su
trabajo. Si un objeto envía un mensaje asincrónico no esperará una respuesta antes
de continuar. En el diagrama de secuencias los símbolos del mensaje varían 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 sincrónico está llena y la de un asincrónico tiene una sola
línea como se aprecia en la figura.

TIEMPO
El diagrama representa al tiempo en dirección vertical El tiempo se inicia en la parte

superior y avanza hacia la parte inferior Un mensaje que esté más 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 dimensión horizontal

es la disposición de los objetos. y la dimensión vertical muestra el paso del tiempo La
figura muestra al conjunto básico de símbolos del diagrama de secuencias con los
símbolos 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
símbolos del diagrama de secuencias.
Objeto1 Objeto2
: <Actor Name>
Para ver en acción a esta importante herramienta del UML apliquémosla en los
ejemplos que hemos visto anteriormente. Cada aplicación 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 alfanumérica; si asumimos que
utiliza una aplicación como un procesador de textos el carácter 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 lógica, y luego del menú
contextual, seleccionar Sub Diagrams, luego New Activity Diagram.

3. seguidamente, procederemos a colocar las actividades correspondientes,
según la lógica adecuada para el caso de uso correspondiente.
Diagrama de 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 opción 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 gráfico, 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 cómo modificar los procedimientos con el tiempo
En esta parte se tratarán los siguientes temas:
• Qué es un diagrama de estados

• Sucesos, acciones y condiciones de seguridad
• Subestados: secuenciales y concurrentes
• Estados históricos
• Por que son importantes los diagramas de estados
• Adición del diagrama de estados al panorama del UML
Cada año trae consigo nuevos estilos en ropas y automóviles las estaciones cambian
el color de las hojas de los árboles y cada año que pasa deja entrever el crecimiento y
madurez de los niños. Al pasar el tiempo y conforme suceden las cosas hay cambios
que afectan a los objetos que nos rodean.
Esto también se aplica en cualquier sistema conforme el sistema interactúa 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 rápidos
• Cuando acciona el interruptor, la fuente de luz cambia su estado de apagada a

• encendida.
• Cuando presiona un botón de un control remoto, una televisión cambia su
estado para mostrarle un canal u otro
• Luego de un lapso adecuado una lavadora cambia su estado de "Lavar" a
"enjuagar'
El DIAGRAMA DE ESTADOS UML captura este tipo de cambios presenta los 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,

SIMBOLOGÍA
La figura le muestra el rectángulo de vértices redondeados que representa a un estado

junto con una línea continua y una punta de flecha mismas que representan a una
transición. La punta de la flecha apunta hacia el estado donde se hará la transición. La
figura también muestra un círculo relleno que simboliza un punto inicial y la diana que
representa a un punto final.
SUCESOS Y ACCIONES
También puede agregar ciertos detalles a las líneas de transición. Puede indicar un
suceso que provoque una transición (desencadenar un suceso), y la actividad de
cómputo (la acción) que se ejecute y haga que suceda la modificación del estado. A
los sucesos y acciones los escribirá cerca de la línea de transición mediante una
diagonal para separar un suceso desencadenando de una acción En ocasiones un
evento causará una transición sin una acción asociada. y algunas veces una transición
sucederá dado que un estado finalizará una actividad (en lugar de hacerlo por un
suceso). A este tipo de transición se le conoce como transición no desencadenada La
GUI (interfaz gráfica de usuario) con que interactúe le dará ejemplos de detalles de la
transición. Por el momento, asumamos que la GUI puede establecerse en uno de tres
estados:
• Inicialización
• Operación
• 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 transición
desde el estado de Inicialización y el arranque es una acción que se realiza durante
tal transición
Como resultado de las actividades en el estado de inicialización la GUI entra al modo
de Operación. Cuando desea apagar su PC desencadena un suceso que provoca la
transición 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 Arranc...
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 ratón o al
teclado podría aparecer un protector de pantallas que evitarla el desgaste de su
pantalla Para decir esto en términos de cambio de estado si ha pasado cieno tiempo
sin que haya interacción con el usuario. la GUI hará una transición del estado
Operación 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 opresión de una tecla o
movimiento del ratón provocará una transición del estado Protector de pantallas al
estado Operación.
El intervalo de 15 minutos es una condición de seguridad: cuando se llega a ella se

realiza la transición. La figura muestra el diagrama de estados de la GUI con el estado
Protector de pantalla y la condición de seguridad aludida. Vea que la condición de
seguridad se establece como expresión booleana.
Encender PC
Inicializacion Apagar
entry/ hacer Arranc...
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,
diseñadores y desarrolladores comprender el comportamiento de los objeto, de un
sistema Un diagrama de clases y el diagrama de objetos correspondiente sólo
muestra lo, aspectos estáticos de un sistema Muestran las jerarquías y asociaciones, y
le indican qué son la, operaciones Pero no le muestran los detalles dinámicos 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 tendrán 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 tendrán que adivinar lo que se supone que harán lo, objetos, Con una
clara representación 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 física 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 vínculos dinámicos, documentos
y cosas por el estilo.
¿Cuál es la relación entre un componente y una clase? Imagine a un componente como

la personificación en software de una clase. La clase representa una abstracción de un
conjunto de atributos y operaciones. Un importante punto por recordar de los
componentes y clases es que un componente puede ser la implementación de más 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 técnicas y La documentación puedan entender de
qué escribirán.
4. Usted se aliste para volver a utilizar los componentes.
Exploremos el último punto. Uno de los aspectos más importantes de los componentes
es el potencial que tienen de volver a ser utilizados. Con las necesidades actuales de
los negocios de soluciones rápidas, entre más rápido presente un sistema para
producción, 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. Tómese el tiempo y esfuerzo para modelar un componente que lo
ayude a que esta reutilización pueda llevarse a cabo.
NewComponent
TIPOS DE COMPONENTES
Conforme avance en su carrera como modelador, se encontrará con tres tipos de
componentes:
1. Componentes de distribución, que conforman el fundamento de los sistemas

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

Refinando el Modelo de Datos.
Tengan en cuenta que, esta es la interpretación que realiza el Rational, nosotros
todavía tenemos la potestad de poder mejorar este modelo.
Observemos este detalle, a nivel de objetos la concepción es válida, pero ¿es

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

Fíjense 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
<<Identif y ing>>
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 práctico, para este caso, lo mejor seria prescindir de
estas tablas, y manejarlo todo desde la tabla ComprobantePago.

De esta forma, nuestra base de datos tendría la siguiente forma:
Definición de Base de Datos
Una Base de Datos es un conjunto de datos almacenados en una estructura física y

con otra lógica por la cual se relacionan, siendo independiente de las aplicaciones.
Tan importante como los datos, es la estructura conceptual con la que se relacionan
entre ellos. Un sistema de gestión de bases de datos (DBMS) consiste en una
colección 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 información de la
bases de datos. Toda base de datos es una colección de datos tendiente a minimizar
la redundancia. Dicha colección 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 características:

Independencia de datos
1. Regulación de acceso
2. Protección de integridad
3. Sin redundancia
4. Facilidad de Ordenamiento

5. Manejo centralizado
Modelo Entidad Relación ( E-R )
El modelo entidad-relación se basa en una percepción de un mundo real que consiste

en un conjunto de objetos básicos llamados entidades y de relaciones entre estos
objetos.
Está pensado como una notación orientada al diseño del esquema conceptual, pues
permite la descripción del esquema conceptual sin preocuparse por problemas de
diseño físico o de eficiencia.
Se supone que en una etapa posterior, los diagramas entidad-relación son llevados a
otros modelos, ya sea manual o automáticamente. Dentro del modelo entidad relación
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 alumn os.

RELACIONES
Es una asociación entre (varias) entidades
Ejemplo: curso es-inscrito por alumno.
Conjunto de relaciones
Es un grupo de relaciones de un mismo tipo.
DIAGRAMA ENTIDAD-RELACIÓN
La estructura lógica general de una base de datos puede expresarse en forma gráfica
por medio de un diagrama entidad relación, que se integra con los siguientes
componentes:
Simbología utilizada en el Diagrama Entidad / Relación

El diagrama E/R se representa de dos formas, una para representar las entidades y
sus relaciones llamada Diagrama o Modelo Entidad Relación y la otra, para
representar sus atributos, llamada Modelo Relacional:
Terminología 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 información. Un tipo de entidad representa a una
clase de entidades que tienen los mismos atributos.
RELACIÓN
Es una asociación entre entidades, o sea es la forma en que se asocian las entidades.
ATRIBUTO
Es la característica de una entidad
DATO
Son los valores que se le asignan a un atributo de una determinada entidad.

DOMINIO
Es un conjunto de valores que puede tomar un atributo en una relación.
TIPO DE RELACIONES
Relación uno a uno ( 1 : 1 )

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

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

Una entidad en A esta asociada con un numero cualquiera de entidades en B, y 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 diseño de una base de datos es la creación de un modelo de
datos. Un modelo de datos es la representación en escala de la realidad. En este
modelo reflejaremos la estructura de negocio de la organización, por medio de datos y
relaciones.
MODELO CONCEPTUAL
El modelo conceptual deberá reflejar todas las relaciones lógicas y es totalmente
independiente de su implementación física. Este es un modelo de entidad relación.
MODELO LÓGICO
Este modelo es el puente entre el modelo conceptual y el modelo físico; describe como
se verán los datos. Existen en el diseño de bases de datos 3 modelos lógicos:
1. Jerárquico
2. Red
3. Relacional
MODELO FÍSICO
El modelo físico esta construido sobre las bases del modelo lógico y describe como los
datos son almacenados. Este es el nivel mas bajo de abstracción.
El Proceso de Normalización.
Es la técnica utilizada para dividir las estructuras de datos en pequeñas unidades. En
estas unidades, cada atributo es totalmente dependiente de la clave primaria de la
entidad a la cual pertenece.
La normalización nos permite:
• Minimizar la redundancia
• Minimizar el impacto de futuros cambios de datos
• Minimiza el mantenimiento de datos

Dependencia Funcional
Es la relación existente entre dos atributos, por lo que el conocimiento de uno de ellos
determina el valor del otro. Si un elemento A es funcionalmente dependiente de otro
elemento B, queda automáticamente 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 están 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 según 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 interactúan
con ella, esto también 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 sería la BD.
Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas,
normas, operaciones, definiciones y restricciones presentes en una organización y que
son de vital importancia para alcanzar los objetivos misionales.
Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año 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 múltiples reglas de negocio, explícitas o

tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc.
Pueden residir en la cabeza de algunas personas o en el código fuente de programas
informáticos.
En los últimos años se viene observando una tendencia a gestionar de forma

sistemática y centralizada las reglas de negocio, de modo que sea fácil 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 través de la definición 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 desempeñar 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 organización debe
hacer.

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

D E L M O D E L O D E D A T OS A L A B A S E D E
D AT O S .
Como se vio en el capitulo anterior, todavía tenemos la posibilidad de mejorar nuestro

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

modelo de datos refinado.
El proceso de Migración 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 generación de la base de datos.
En esta pantalla, podremos seleccionar los tipos de elementos que conformarán

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

A continuación, 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 extensión ddl,
así que mejor le colocamos la extensión sql para identificarla rápidamente.

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

Ingeniería Inversa.
El proceso de ingeniería inversa consiste en transformar una base de datos o en 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 conexión de datos.
6. seleccionar el schema que proporcionará los datos.

7. seleccione los tipos de elementos que serán recuperados desde la base 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 algún tipo de prefijo para las clases, en este caso, no lo usaremos.
Adicionalmente, dejemos activado el check Include Primary Keys.
16. completada la transformación, llevar el paquete a Welcome.

17. finalmente, procederemos a arrastrar las clases generadas a un Class
Diagram previamente creado.
Desarrollo de Caso Práctico.

Aquí se proponen los siguientes casos, para que puedan ser comparados con los
resultados que indique su profesor de curso.
1. Se trata de diseñar la base de datos para la administración 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 además de su
nombre dirección, teléfono, fax, etc.
• El personal de los hospitales (del que interesa almacenar su DNI,

nombre, apellidos, dirección y teléfono) se divide en personal
administrativo y personal sanitario (dentro de este se distingue a su
vez ATS y médicos).
• Los médicos tienen una especialidad que interesa conocer (pediatría,
obstetricia, etc.) y sólo trabajan, al igual que el resto del personal, en
un hospital.
• Los pacientes pueden acudir a varios hospitales del consorcio,
pudiendo ser atendidos por varios médicos.
• Se desea conocer los datos personales de los pacientes que van aingresar
en el hospital, así como el número de seguridad social,

compañía aseguradora, la fecha de admisión y la sala (habitación)
en la que deben permanecer.
• Cada sala se identifica por un número de sala dentro de cada hospital y
se desea conocer el número de camas de las que dispone cada sala.
• Cada admisión de un paciente en el hospital lleva asociada una o
varias fichas de tratamiento en las que se indica la enfermedad y el
médico que la atiende. Cada tratamiento se identifica por el nombre de
la enfermedad del tratamiento que es único para cada admisión.
• Además, 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 sólo puede haber un resultado en un mismo día, a
una misma hora.
2. La empresa “X” desea llevar un control de sus departamentos, empleados y

proyectos según las siguientes especificaciones:
• Se desea conocer el nombre, salario y número 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 representación en un
número de regiones) e ingenieros (encargados de realizar los proyectos
de la empresa); hay, además, otros empleados, como secretarios,
auxiliares de laboratorio, etc. Un director no puede ejercer ninguna otra
función; sin embargo, un representante de ventas puede desempeñar
también las funciones de un ingeniero y viceversa.
• Los distintos departamentos concede becas de estudio a los hijos de
los empleados. Estas becas no están tipificadas, sino que son ayudas
que se conceden dependiendo del presupuesto del que disponga el
departamento. Se desea conocer la fecha de concesión de cada beca
así como la cuantía de ésta. Un ingeniero puede tener varias
especialidades que se desean conocer. De los departamentos se
necesita saber, el nombre, localización y empleados que trabajan en
él. Un departamento tiene, como mínimo 2 empleados y como máximo
30 y está al cargo de un único director. Cada departamento tiene un
director distinto.
• Un departamento puede controlar un número de proyectos, de los que
se desea conocer su nombre y fecha de comienzo.
• En la realización de un proyecto no puede haber involucrados más de 5
ingenieros. Todo ingeniero debe estar asociado a 1 proyecto como
mínimo y a 2 como máximo. En el caso de que un departamento no
tenga ningún proyecto, sus empleados podrán estar trabajando en
proyectos de otros departamentos.

CAPITULO 8
➢ Publicando una Web de Documentación.
➢ Examen Final.

P U B L I C A N D O U N A W E B D E D O C U M E N T A C I Ó N .
Desde el Rational Rose, tenemos la posibilidad de poder publica en el internet, 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 imágenes, para ello,
hacer clic en el botón Diagrams.
4. una vez realizados todos los cambios, hacer clic sobre el botón Publish, para
que se inicie el proceso de publicación, 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.

5. Seguidamente, seleccionamos el cuadro de navegación, 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 hipervínculo.
7. Adicionalmente, se puede ver información 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 CE
Capitulo 1.......................................................................................................................1
Introducción al Análisis y Diseño Orientado a Objetos. .......................................2
El Desarrollo de la Estructura del Pensamiento y la Construcción del
Conocimiento ...........................................................................................................2
La clasificación es un medio por el cual organizamos el conocimiento ...............4
Simulación. .......................................................................................................4
Encapsulamiento. .............................................................................................5
Reutilizacion. ....................................................................................................5
Conceptos Básicos ..............................................................................................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
Descripción del Proceso Actual: El Modelo de Negocios .....................................13
Conceptos Fundamentales para Modelar Negocios .........................................13
Estereotipos....................................................................................................14
Creación 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 asociación entre CU’s .............................................................................22
Comunicación ....................................................................................................23
Generalización ...................................................................................................24
Inclusión .............................................................................................................24
Extensión ...........................................................................................................25
Como identificar un Actor ...................................................................................25
Como identificar un Caso de Uso ......................................................................26
Ventajas de los Casos de Uso ...........................................................................26
Documentando los CU’s ........................................................................................27
Creación 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 Asociación entre Clases .........................................................................36
Asociación (Binaria) ...........................................................................................36
Clases de Asociación (Atributos de Enlace) ......................................................37
Asociaciones Reflexivas ....................................................................................38
Herencia Y Generalización ................................................................................38
Agregación / Composición .................................................................................39

Creación del Modelo en Rational Rose ............................................................ 39
Capitulo 4 .................................................................................................................... 43
Definiendo la Lógica del Sistema. ........................................................................ 44
Utilizando el Diagrama de Actividad. .................................................................... 44
Decisiones ......................................................................................................... 45
Rutas Concurrentes .......................................................................................... 45
Definiendo Escenarios (Calles) ............................................................................ 46
resumen ......................................................................................................... 47
Diagramas de Interacción: Secuencia y Colaboración. ........................................ 47
Diagrama de Secuencia .................................................................................... 48
objetos ........................................................................................................... 48
mensaje ......................................................................................................... 48
tiempo ............................................................................................................ 49
la secuencia ................................................................................................... 49
Creación del Modelo en Rational Rose ............................................................ 50
Capitulo 5 .................................................................................................................... 55
El comportamiento de los objetos. ...................................................................... 56
Uso del Diagrama de Estados ............................................................................. 56
SIMBOLOGÍA .................................................................................................... 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
Definición de Base de Datos ............................................................................. 67
Modelo Entidad Relación ( E-R )....................................................................... 68
entidades ....................................................................................................... 68
relaciones ...................................................................................................... 69
diagrama entidad-relación ............................................................................. 69
Terminología De Bases De Datos..................................................................... 70
entidad ........................................................................................................... 70
relación .......................................................................................................... 70
atributo ........................................................................................................... 70
dato ................................................................................................................ 70
Dominio .......................................................................................................... 71
tipo de relaciones........................................................................................... 71
Modelo De Datos............................................................................................... 73
Modelo Conceptual ........................................................................................ 73
Modelo Lógico ............................................................................................... 73
Modelo Físico ................................................................................................ 73
El Proceso de Normalización. .............................................................................. 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 según las Reglas del Negocio. .......................................................78
Capitulo 7.....................................................................................................................79
Del modelo de Datos a la Base de Datos..............................................................80
El proceso de Migración a la BD ...........................................................................80
Ingeniería Inversa ..................................................................................................84
Desarrollo de Caso Práctico. .................................................................................92
Capitulo 8.....................................................................................................................95
Publicando una Web de Documentación. ............................................................96

Manual UML - HICOR PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manual UML - HICOR PDF

Загружено:

Авторское право:

Доступные форматы

CAPITULO 1

➢ Introducción al Análisis y Diseño Orientado a Objetos.

Walter Hidalgo Córdova Pág. 1

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

Estas están incluidas en las versiones orientadas a objetos de metodología para

La TOO se fundamenta en el proceso de construcción y utilización de conocimientos,

El Desarrollo de la Estructura del Pensamiento y la

Pág. 2 Modelamiento de Datos

Los conceptos se construyen modelando los aspectos y características de cualquier

Cuando pensamos en un auto, no visualizamos cada mínimo detalle que lo describa,

En Tecnología 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 organización

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

Walter Hidalgo Córdova Pág. 3

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

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

Después de los doce años, en la etapa de las Operaciones combinatorias de la

Un Sistema es un conjunto de componentes (conceptos y modelos, y aún de otros

Cuando un sistema tiene por objetivo explicar un hecho o fenómeno, y es aceptado,

En síntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en

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

Representación directa de elementos que "maneja" el usuario en el mundo real.

Pág. 4 Modelamiento de Datos

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

La encapsulación tiene dos beneficios primordiales:

MODULARIDAD. El código de un objeto puede ser escrito y se puede mantener

ESCONDER LA INFORMACIÓN ( INFORMATION HIDING ). Un objeto tiene una interfaz con la

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

Walter Hidalgo Córdova Pág. 5

La ingeniería de software comprende las técnicas de desarrollo formal para el diseño

¿Qué son los objetos? ¿Qué no son los objetos?

Ejm.- una factura, una organización, una figura en un

Pág. 6 Modelamiento de Datos

Ejm.- Un Cajero Automático es un ejemplo de objeto. Tiene tipos específicos de

Un mensaje es una solicitud para que se lleve a cabo la operación indicada y se

Walter Hidalgo Córdova Pág. 7

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

Pág. 8 Modelamiento de Datos

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

• Criterios de descomposición: Encapsulación vs. Visibilidad, Reusabilidad y

Ciclo de Vida del Software.

Otro, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículo

Walter Hidalgo Córdova Pág. 9

Quizás algunas características que debemos de tener en cuenta al momento de

Sobre los sistemas

A su vez, nuestro sistema puede retomar la información generada, para devolver

Pág. 10 Modelamiento de Datos

En el Análisis de Requerimientos se realiza la comprobación de lo recopilado en el

Todo esto debe de reflejarse en un documento que muestre la situación actual de la

Proceso de desarrollo utilizando UML.

Modelamiento de Datos Pág. 11

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

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

Pág. 12 Modelamiento de Datos

• Maneja información que le pertenece al negocio.

Conceptos Fundamentales para Modelar Negocios

Modelamiento de Datos Pág. 13

Actividades del Modelo de Negocio.

Pág. 14 Modelamiento de Datos

El trabajador del negocio, representa aquel personaje que tiene

Creación del Modelo en Rational Rose