modulo_1-_introduccion_al_desarrollo_de_aplicaciones

Desarrollo de Aplicaciones I

INICTEL-UNI 1 Módulo 1

CURSO 1: Desarrollo de Aplicaciones I

Objetivo General del Curso

Al término del curso el participante será capaz de: Modelar sistemas

de software empleando el lenguaje UML utilizando la herramienta

ArgoUML e Implementar y administrar aplicaciones Web realizadas

utilizando el lenguaje PHP que se conecten a bases de datos

PostgreSQL y/o MySQL para el almacenamiento y administración de

datos.

Objetivos Específicos

• Modelar aplicaciones comerciales utilizando el lenguaje UML

y la herramienta ArgoUML..

• Modelar bases de datos.

• Utilizar el lenguaje SQL para el manejo de bases de datos

como MySQL y PostgreSQL.

• Utilizar lenguajes para el desarrollo de aplicaciones Web

(HTML y PHP).

• Realizar conexiones a las bases de datos utilizando PHP.



Módulo 1: Introducción al Desarrollo de Aplicaciones

Objetivo General

Mostrar la situación actual de las aplicaciones comerciales y su

entorno metodológico.

Objetivos Específicos

• Identificar el entorno actual de aplicaciones comerciales.

• Entender y emplear el lenguaje UML para el modelamiento de

software orientado a objetos.

• Conocer y utilizar argoUML como herramienta para el diseño

con UML.



Introducción

La implementación y el desarrollo de aplicaciones ha sufrido grandes transformaciones; las

aplicaciones Web se han convertido en poco tiempo en el presente y el futuro. Ahora es común

encontrar en el sitio Web más pequeño alguna aplicación que acceda a una base de datos para

almacenar o mostrar información. Por lo tanto nos orientaremos al desarrollo y despliegue de tales

aplicaciones, utilizando diferentes herramientas que nos faciliten el cumplir dicho objetivo.

Nuestro camino comenzará seleccionando la metodología que utilizaremos para modelar, visualizar y

documentar cada una de las partes que comprende el desarrollo de nuestra aplicación..



Sumario

1.1 Aplicaciones Comerciales. 5

1.1.1 Introducción 5

1.1.2 ¿Qué son las Aplicaciones Comerciales? 5

1.2 Metodologías 7

1.2.1 Metodología Orientada a Objetos 8

1.2.2 Breve Historia de los Lenguajes de Programación OO 9

1.2.3 El Modelo OO 10

1.3 Tópicos de UML 14

1.3.1 Definición de UML 14

1.3.2 Características de UML 15

1.3.3 Objetivos de UML 16

1.3.4 Utilidad del UML 16

1.3.5 Diagramas de UML 17

1.3.6 Diagrama de Caso de Uso 17

1.3.7 Diagramas de Clases 17

1.3.8 Diagrama de Objetos 24

1.3.9 Diagrama de Secuencia 25

1.3.10 Diagrama de Colaboración 26

1.3.11 Diagrama de Estado 28

1.3.12 Diagramas de Actividad 30

1.3.13 Diagramas de Componente 32

1.3.14 Diagramas de Despliegue 34

1.4 ArgoUML 35

1.4.1 Partes de ArgoUML 38

1.5 Actividades 40

1.5.1 Auto evaluación 40

1.5.2 Laboratorio 41

1.6 Bibliografía y Enlaces Recomendados 44



1.1 Aplicaciones Comerciales

1.1.1 Introducción

Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la

solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las

actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se

realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción

de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema

de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de

un equipo de desarrollo formado por varias personas.

Una estadística muy importante nos dice que en un proyecto de desarrollo de software sólo el 15% es

codificación, entonces debemos pensar que todo se basa en planificar.

1.1.2 ¿Qué son las Aplicaciones Comerciales?

Las Aplicaciones comerciales son un conjunto de herramientas de software que buscan la

satisfacción general del usuario final. Un usuario final es el cliente que finalmente requiere de un

aplicativo que cubra sus necesidades y lo ayude a generar sus procesos de manera rápida, eficiente

y segura Un Sistema de Información es un conjunto formal del procesos que operando sobre una

colección de datos estructuradas según la necesidad de la empresa, recopilan, elaboran y distribuyen

la información necesaria para las operaciones de dicha empresa y para las actividades derivadas de

la misma.



Estructura Empresa

En todo desarrollo de software se tiene que entender cual es el rol del profesional informático frente a

la empresa, la Figura Nº 3 muestra la estructura clásica de cualquier empresa, lo importante no sólo

es entender el comportamiento de la misma sino definir en este punto un problema muy común en la

mayoría de entornos empresariales; el problema es originado cuando sólo se empiezan a realizar

aplicaciones de carácter Operativo y se deja de lado a la Alta Dirección, es decir se hacen sistema de

Facturación, Inventarios logrando de esta forma aliviar el trabajo a los dos últimos niveles de la

Pirámide (Sistema de Transacciones y Dirección Operativa) pero no se hace llegar ninguna

información a la Alta Dirección o quizá si se envía, sea esta la misma que ofrece el aplicativo a los

niveles antes mencionados; esta información no sirve ya que no está resumida. Un tema importante

a la hora de desarrollar software es no olvidarse que estos están en íntima relación con la

planificación de la empresa, específicamente con el Plan estratégico que da los lineamientos

generales para la meta anual. El siguiente grafico muestra la relación existente entre los distintos

planes que son desarrollados a nivel empresarial, así también se puede ver la parte de competencia

de cada uno.

Planificación



Al momento de definir la arquitectura final del software es necesario tener en consideración los

diferentes planes definidos a nivel de la parte más alta de la pirámide empresarial, es decir la plana

Directiva. Para esto se define un Plan estratégico que describe a nivel macro el rumbo que tomará la

empresa o institución, luego se establece un marco táctico para crear los posibles escenarios a los

cuales se podría llegar, por último las áreas involucradas establecen un Plan Operativo que realiza la

matriz o plano de los que se desea, estableciendo objetivos, metas, indicadores, entre otros.

A nivel informático es el Plan Operativo el que describe todas las actividades que serán desarrolladas

a lo largo de un periodo determinado. No debemos olvidar que éstas están en función del Plan

Estratégico, por ejemplo si en el plan estratégico se decide no realizar gastos en tecnologías de

información para el presente periodo, entonces en nuestro plan Operativo deberíamos definir la

forma en que trabajaremos sin ningún tipo de recurso adicional, es decir como nos mantenemos sin

comprar nada adicional a lo que ya tenemos.

1.2 Metodologías

Conjunto de métodos empleados para el desarrollo de desarrollo de software. Una metodología

completa es algo más que una notación, un proceso y herramientas. Estas nos permiten:

• Guías para estimar costos.

• Manejo del proyecto en las tareas y entregas.

• Medidas y métricas.

• Formas definidas y dirección en las entregas de la construcción.

• Políticas y procedimientos para garantizar la calidad del software.

• Descripciones de los roles y programas de entrenamiento detallados.

• Ejemplos totalmente trabajados.

• Ejercicios de entrenamiento.



• Técnicas para adaptar el método.

• Técnicas definidas.

• Diagramas que esquematizan los procesos

1.2.1 Metodología Orientada a Objetos

Es una forma de enfocar la tarea de desarrollo y programación; toma las mejores ideas del diseño

estructurándolo y combinándolo con nuevos y poderosos conceptos; que permiten descomponer

fácilmente un problema en subgrupos de partes relacionadas. Cada uno de estos subgrupos se

puede traducir en un objeto que tendrá un comportamiento propio.

Orientarnos a modelar objetos, permite una representación más directa del mundo real, reduciendo

fuertemente la transformación radical; los objetos son entidades que podemos entender y relacionar

fácilmente como personas, empresas, documentos, libros, etc. Cada objeto por lo tanto tendrá sus

propias características (información y comportamiento) y también similitudes con otros objetos. Entre

objetos además pueden interactuar enviándose mensajes. Los objetos también los podemos

organizar utilizando jerarquías que nos permitan establecer estas diferencias y similitudes

En sus inicios la metodología Orientada a Objetos se aplicó en programación (POO) pero sus buenos

resultados han hecho que ahora sea aplique el análisis y diseño de sistemas de software.

En resumen con la metodología orientada a objetos podemos:

• Modelar el mundo real de un modo más cercano a la perspectiva del usuario.

• Fomenta la reutilización y extensión del código.

• Permite crear sistemas más complejos.

• Facilita la creación de programas visuales.

• Construcción de prototipos.



• Agiliza el desarrollo de software.

• Facilita el trabajo en equipo.

• Facilita el mantenimiento del software.

1.2.2 Breve Historia de los Leguajes de Programación Orientados a Objetos

El primer lenguaje que introdujo los conceptos de orientación a objetos fue SIMULA 67 creado en

Noruega, por un grupo de investigadores dirigido por O. J. Dahl y K. Nygaard, con el fin de realizar

simulaciones discretas de sistemas reales. En estos tiempos no existían lenguajes de programación

que se ajustarán a sus necesidades, así que se basaron en el lenguaje ALGOL 60 y lo extendieron

con conceptos de objetos, clases, herencia, el polimorfismo por inclusión (que se obtiene

introduciendo la herencia de clases) y procedimientos virtuales. Estos últimos permiten la sobrecarga

de procedimientos, de tal forma que para un sólo procedimiento se pueden tener varias

implementaciones, dependiendo del nivel de jerarquía de la herencia de clases en el cual está

definido un procedimiento. El lenguaje fue utilizado sobre todo en Europa y no tuvo mucho impacto

comercial, sin embargo los conceptos que se definieron en él, se volvieron sumamente importantes

para el futuro del desarrollo de software.

Alrededor de los años 70´s fue desarrollado el lenguaje de programación OO llamado SMALLTALK

en los laboratorios Xerox en Palo Alto, EE.UU. Este lenguaje adoptó los conceptos nombrados

anteriormente como su fundamento. El hecho de ser creado en EE.UU., ayudó a que se introdujera a

nivel mundial el término de Orientación a Objetos (Object Oriented) y que cobrara importancia entre

los diseñadores de lenguajes de programación. Los puntos importantes de este lenguaje fueron, por

un lado, adoptar el concepto de objeto y clase como núcleo del lenguaje y la programación

interactiva,

incorporando las ideas ya conocidas de lenguajes funcionales. Es decir que se tuviese un lenguaje

interpretado y no compilado.

En 1985, E. Stroustrup extendió el lenguaje de programación C a C++, es decir C con conceptos de

clases y objetos, también por esta fecha se creó desde sus bases el lenguaje EIFFEL por B. Meyer.

Ambos manejan conceptos de objetos y herencia de clases. La herencia es múltiple y se introduce

pensando en dar mayor flexibilidad a los desarrolladores. Sin embargo, actualmente la herencia

múltiple se ha evitado por agregar complejidad en las estructura de clases. Ambos lenguajes tuvieron

importancia entre 1985 y hasta la primera mitad de los noventas.

En 1995 apareció JAVA, el más reciente lenguaje OO, desarrollado por SUN, que hereda conceptos

de C++, pero los simplifica y evita la herencia múltiple. A cambio se introduce el término de interfaz y

la herencia múltiple de interfaces. Obtiene una rápida aceptación gracias a los applets, que son unos

programas en JAVA insertado en páginas WEB dentro del código HTML. Estos programas pueden



viajar a través de la Internet y brindarle al usuario mayor interactividad con las páginas WEB. JAVA

introduce también, la programación concurrente y distribuida. El lenguaje es mitad compilado y mitad

interpretado dando como resultado la portabilidad a distintas plataformas. JAVA aún sigue

evolucionando y se espera que en los próximos años logre la madurez adecuada para volverse un

lenguaje de desarrollo de mayor importancia.

Actualmente la Programación Orientada a objetos es aplicada ampliamente por varios lenguajes

además de JAVA entre ellos esta PHP lo que nos brinda un poderosa herramienta en el momento de

desarrollar nuestras aplicaciones Web.

1.2.3 El modelo OO (Orientado a Objetos)

Un modelo representa a un sistema software desde una perspectiva específica, proporcionándonos

conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como

sea posible.

Cuando modelamos utilizando objetos, dividimos los sistemas en unidades (objetos) que nos

permitan representar información y comportamientos que interactúan entre si, dándonos una visión

detallada del funcionamiento esperado de dicho sistema.

Para esto necesitamos conocer algunas definiciones básicas:

a. Definición de Objeto:

Empecemos entendiendo que es un objeto del mundo real. Un objeto del mundo real es

cualquier cosa que vemos a nuestro alrededor. Un automóvil, un avión, un monitor de

computadora, una impresora, una factura, un libro.

Todo objeto del mundo real tiene 2 componentes: características y comportamiento.

Por ejemplo, los automóviles tienen características (marca, modelo, color, velocidad máxima,

etc.) y comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar llantas, etc.).

En términos de programación, un objeto es una abstracción conceptual del mundo real que se

puede traducir a un lenguaje programación. De esta manera los objetos pueden ser reales o

abstractos, por ejemplo: una persona, un documento, una pantalla de usuario, etc.

Estos objetos de software al igual que los objetos del mundo real, también tienen

características y comportamientos. Un objeto de software mantiene sus características en una

o más "variables", e implementa su comportamiento con "métodos". Un método es una

función o subrutina asociada a un objeto.



AUTOMOVIL

Var Marca = string()

Var Modelo = string()

Var Color = string()

método arrancar()

método acelerar()

método frenar()

método retroceder()

OBJETO

Características ( Variables)

Comportamiento (métodos)

AUTOMOVIL



Var Color = string()

método arrancar()

método acelerar()

método frenar()

método retroceder()

OBJETO

Características ( Variables)

Comportamiento (métodos)

Entre las características del objeto cabe destacar que un objeto puede distinguirse de otros,

esto se conoce como identidad y para esto posee un identificador OID (Object Identifier) que

debe cumplir:

• Constituye un identificador único y global para cada objeto dentro del sistema.

• Es determinado en el momento de la creación del objeto.

• Es independiente de la localización física del objeto, es decir, provee completa

independencia de localización.

• Es independiente de las propiedades del objeto, lo cual implica independencia de

valor y de estructura.

• No cambia durante toda la vida del objeto. Además, un OID no se reutiliza aunque

el objeto deje de existir.

El valor de las características de un objeto en un determinado momento se le conoce como

estado y presenta las siguientes características:

• El estado evoluciona con el tiempo.

• Algunos atributos pueden ser constantes.

El comportamiento del objeto está representado por una serie de operaciones, funciones o

métodos que modifican o no el estado del objeto, haciendo que ocurra un cambio de estado

en el mismo, el cual representa el comportamiento visible del objeto en la realidad. El estado

y el comportamiento de un objeto están relacionados.

Ejemplo: no es posible frenar un automóvil si este no ha arrancado primero.

b. Definición de Clase:

La clase es un modelo o prototipo que define las variables y métodos comunes a todos los

objetos de cierta clase. También se puede decir que una clase es una plantilla genérica para



un conjunto de objetos de similares características. Por otro lado, una instancia de una clase

es otra forma de llamar a un objeto. En realidad no existe diferencia entre un objeto y una

instancia. Sólo que el objeto es un término más general, pero los objetos y las instancias son

ambas representación de una clase.

En el mundo real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo,

nuestro teléfono celular es sólo uno de los miles que hay en el mundo. Si hablamos en

términos de la programación orientada a objetos, podemos decir que nuestro objeto celular es

una instancia de una clase conocida como "celular". Los celulares tienen características

(marca, modelo, sistema operativo, pantalla, teclado, etc.) y comportamientos (hacer y recibir

llamadas, enviar mensajes multimedia, transmisión de datos, etc.).

CELULAR



método llamar()

método colgar()

CELULAR



método llamar()

método colgar()

Mi_Celular

Var Marca = Motorola

Var Modelo = V220

método llamar()

método colgar()

Mi_Celular

Var Marca = Motorola

Var Modelo = V220

método llamar()

método colgar()

Clase: CELULAR

Objeto: Mi_Celular

c. Definición de Herencia:

La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente

consiste en que una clase puede heredar sus variables y métodos a varias subclases (la

clase que hereda es llamada superclase o clase padre). Esto significa que una subclase,

aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos

heredados de la superclase. De esta manera se crea una jerarquía de herencia.

Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda

que vende y repara equipos celulares.



CELULAR

Marca = string()

Modelo = string()

método llamar()

método colgar()

CELULAR

Marca = string()

Modelo = string()

método llamar()

método colgar()

CELULAR

NUEVO

Precio = string()

fecha_ing = string()

método llamar()

método colgar()

CELULAR

NUEVO

Precio = string()

fecha_ing = string()

método llamar()

método colgar()

CELULAR

MALOGRADO

motivo = string()

motivo = string()

método llamar()

método colgar()

CELULAR

MALOGRADO

motivo = string()

motivo = string()

método llamar()

método colgar()

d. Definición de Envío de Mensajes

¿Qué sucede cuando los objetos desean comunicarse entre sí? Un objeto es inútil si está

aislado. El medio empleado para que un objeto interactúe con otro son los mensajes.

Hablando en términos un poco más técnicos, los mensajes son invocaciones a los métodos

de los objetos, es decir desde un punto de vista más convencional no es más que el sinónimo

de una llamada a una aplicación.

Estructuralmente, un mensaje consta de tres partes: la identidad del objeto receptor, el método

ejecución se ha solicitado y cualquier otra información adicional que el receptor pueda necesitar

para ejecutar el método requerido. Esta información suele darse en forma de parámetros.

CARACTERISTICAS ASOCIADAS AL MODELAMIENTO ORIENTADO A OBJETOS

a. Abstracción

La abstracción consiste en captar las características esenciales de un objeto, así como su

comportamiento. Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué características

podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes

tienen todos los automóviles? Todos tendrán una marca, un modelo, número de chasis, peso,

llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automóviles

podrán acelerar, frenar, retroceder, etc.

En los lenguajes de programación orientada a objetos, el concepto de Clase es la

representación y el mecanismo por el cual se gestionan las abstracciones.

Por ejemplo, en Java tenemos:

public class Automovil {

// variables



// métodos

}

b. Encapsulamiento

El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto

es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes

estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la

abstracción y el ocultamiento que veremos a continuación.

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que

tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no

los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la

Clase pero no será necesario saber cómo lo hace.

c. Ocultamiento

Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer

sólo los detalles que sean necesarios para el resto del sistema.

El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque

habrá cierto comportamiento privado de la Clase que no podrá ser accedido por otras Clases. Y

controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es

en estos mecanismos dónde se validarán que algunas condiciones se cumplan. En Java el

ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las

variables y métodos.

1.3 UML (Unified Modeling Language)

Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos.

También se necesitará realizar un análisis y diseño orientado a objetos.

El modelamiento visual es la clave para realizar el análisis OO. Desde los inicios del desarrollo de

software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a

duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías.

1.3.1 Definición de UML

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los

elementos que forman un sistema software orientado a objetos. UML entrega una forma de modelar

cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas



concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y

componentes de software reusables.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del

proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático.

Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no

así el proceso que se siguió para obtenerlo

El UML es un lenguaje de modelado y no un método. La mayor parte de los métodos consisten, al

menos en principio, en un lenguaje y en un proceso para modelar. El lenguaje de modelado es la

notación (principalmente gráfica) de que se valen los métodos para expresar los diseños. El proceso

es la orientación que nos dan sobre los pasos a seguir para hacer el diseño.

El lenguaje de modelado es la parte más importante del método, es la clave para la comunicación;

para poder analizar un diseño se necesita comprender el lenguaje de modelado; no el proceso que se

siguió para lograr el diseño.

1.3.2 Características del UML

• Desplegar los límites de un sistema, sus principales funciones mediante casos de uso y

actores.

• Representar la estructura estática de un sistema usando diagramas de clases.



• Modelar los límites de un objeto con diagramas de estados.

• Mostrar la arquitectura de la implementación física con diagramas componentes y de

emplazamiento o despliegue.

1.3.3 Objetivos del UML

• Debe ser un lenguaje universal, como cualquier lenguaje de modelado de propósito general,

que pueden usar todos los modeladores. No tiene propietario y está basado en el común

acuerdo de gran parte de la comunidad informática.

• Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de

sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para

manejar todos los conceptos que se originan en un sistema moderno, tales como la

concurrencia y distribución, así como también los mecanismos de la ingeniería de software,

como son la encapsulación y componentes.

• Establecer un acoplamiento explícito entre los modelos conceptuales como los de

implementación.

• Modelar Sistemas (y no sólo software) utilizando conceptos Orientado a Objetos.

• Resolver los problemas de sistemas complejos.

1.3.4 Utilidad del UML

UML es un lenguaje para modelamiento de propósito general evolutivo, ampliamente aplicable, dable

de ser soportado por herramientas e industrialmente estandarizado. Se aplica a una multitud de

diferentes tipos de sistemas, dominios y métodos o procesos.

• Como lenguaje de propósito general, se enfoca en el corazón de un conjunto de conceptos

para la adquisición, comparición y utilización de conocimientos emparejados con mecanismos

de extensión.

• Como un lenguaje para modelamiento ampliamente aplicable, puede ser aplicado a diferentes

tipos de sistemas (software y no - software), dominios (negocios versus software) y métodos

o procesos.

• Como un lenguaje para modelamiento soportable por herramientas, las herramientas ya están

disponibles para soportar la aplicación del lenguaje para especificar, visualizar, construir y

documentar sistemas.

• Como un lenguaje para modelamiento industrialmente estandarizado, no es un lenguaje

cerrado, propiedad de alguien, sino más bien, un lenguaje abierto y totalmente extensible

reconocido por la industria.



UML posibilita la captura, comunicación y nivelación de conocimiento estratégico, táctico y

operacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costos y

reduciendo el tiempo de presentación al mercado; manejando riesgos y siendo proactivo para el

posible aumento de complejidad o cambio.

1.3.5 Diagramas de UML

Los diagramas se utilizan para dar diferentes perspectivas del problema según lo que nos interese

representar en un determinado momento, vale decir que en algunos casos no es necesario

representar los nueve diagramas.

1.3.6 Diagrama de Caso de Uso

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema,

las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. El diagrama de uso es

muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que sólo

especifica como deben comportarse y no como están implementadas las partes que define.

Representa los distintos requerimientos que le hacen los usuarios al sistema, especificando las

características de funcionalidad y comportamiento durante su interacción con los usuarios u otros

sistemas.

Un caso Diagrama de Casos de Uso puede existir tanto a nivel del Modelo de Negocio como en el

nivel de Modelo de Construcción del Software. A nivel de Negocio muestra el Caso de Uso de

Negocio relacionado con los actores internos y externos de negocio. A nivel de Sistema muestra la

funcionalidad total del Sistema Software que se construye. El Diagrama de Casos de Uso a nivel de



Sistema permite definir los privilegios del Sistema por actor, teniendo en cuenta aspectos de auditoria

al considerar el módulo de IDENTIFICACIÓN, como obligatorio.

Comunica

<<use>>

Profesor

Actualizar cargaacademica

Actor

<<extend>>

Actualizarcarga

Administrativa

Pedir Permiso

ElaborarInforme de Actividades

ElaborarPlanificaciónde Actividad

Comunica

<<use>>

Profesor

Actualizar cargaacademica

Actor

<<extend>>

Actualizarcarga

Administrativa

Pedir Permiso

ElaborarInforme de Actividades

ElaborarPlanificaciónde Actividad

Diagrama de Casos de Usos

Elementos que participan en un Diagrama de Caso de Uso

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y

relaciones entre casos de uso.

a) Actores.- Un actor es algo con comportamiento, como una persona identificada por un rol

(comprador, vendedor, cobrador, etc.), un sistema informatizado u organización, y que realiza

algún tipo de interacción con el sistema. Se representa mediante una figura humana dibujada

con palotes. Esta representación sirve tanto para actores que son personas como para otro

tipo de actores.

Representación de un actor

Cada usuario puede acceder al sistema asumiendo el rol de diferentes actores. Un actor tiene

un único rol para cada Caso de Uso que se comunica con él.

La palabra rol especifica que un Actor no necesariamente representa a una persona en

particular, sino más bien la labor que realiza frente al sistema.

b) Casos de Uso.- Un caso de uso es una descripción de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una



tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el

Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior.

El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo

usando el sistema.

Representación de un caso de uso

Los procesos se describen dentro del caso de uso por una descripción textual o una

secuencia de pasos ejecutados. Un caso de uso es justamente una forma de representar

como un actor usa nuestro sistema.

c) Relaciones entre Casos de Uso.- Un caso de uso, en principio, debería describir una tarea

que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil

describir una interacción con un alcance menor como caso de uso. La razón para utilizar

estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo

de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que

queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos

de uso ordinarios pueden ser de los siguientes tres tipos:

• Incluye (include): Un caso de uso base incorpora explícitamente a otro caso de uso en

un lugar especificado en dicho caso base. Se suele utilizar para encapsular un

comportamiento parcial común a varios casos de uso.

<<include>>

Paciente

Hacer una cita Identificarse

<<include>>

Paciente

Hacer una cita Identificarse

El caso de uso Hacer una Cita puede incluir el comportamiento del caso de uso

Identificarse.

• Extiende (extend): Cuando un caso de uso tiene un comportamiento particular del

mismo tipo que un caso de uso base.



<<extends>>

Cliente

Pagar con tarjeta Pagar

<<extends>>

Cliente

Pagar con tarjeta Pagar

El caso de uso Pagar con Tarjeta extiende el caso de uso Pagar.

• Uso (uses): Cuando un caso de uso hace uso de otro caso de uso para realizar una

tarea.

<<uses>>

Cliente

Pagar con tarjeta Imprimir Voucher

El caso de uso Pagar con tarjeta Usa el caso de uso imprimir Voucher.

1.3.7 Diagramas de Clases

Muestran un conjunto de clases, así como sus relaciones. Son los más comunes en el modelado de

sistemas orientados a objetos.

Elementos que participan en un diagrama clase

a) Clase

La clase se representa con un rectángulo dividido en tres compartimentos ( Ver Figura 20):

<Nombre Clase>

<Atributos>

<Operaciones o Metodos>

<Nombre Clase>

<Atributos>

<Operaciones o Metodos>

Representación de una clase



El primero indica el nombre de la clase, que nos da una idea de lo que representa y no lo

que ella hace.

El segundo contiene los atributos expresados con su nombre, que representa alguna

propiedad de los objetos que estamos modelando y que son compartidos por todos los

objetos de una clase; muestran su visibilidad, multiplicidad, tipo de dato, valor inicial, etc.

El tercero indica sus operaciones expresadas con el nombre de la operación, que pueden

realizar los objetos de una clase, mostrando su visibilidad, nombre, lista de parámetros, tipo

de dato retornado, valores por defecto y el alcance de las operaciones. El conjunto de

operaciones describen el comportamiento de los objetos de una clase; como una clase

interactúa con su entorno.

b) Relaciones entre clases

Los enlaces a nivel de objetos pueden verse en el mundo de las clases. Estas son:

• Dependencia: Es una relación de uso, es decir una clase usa a otra, que la necesita para

su cometido. Se representa con una flecha que va desde la clase utilizadora a la clase

utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede

afectar al funcionamiento de la clase utilizadora, pero no al contrario.

Presentacion

descripciondescripcionBrevesimbolo

Producto

descripciondescripcionBrevefechaRegistrocantidadfechaUsuariohoraUsuario

0..* 10..* 1tiene

Modificación de la clase utilizadora

• Herencia: Es una relación entre dos clases en donde una de ellas, llamada subclase o

clase hija (subclase o child), hereda los atributos y el comportamiento de otra, llamada

superclase o clase padre (superclase o parent).



P e r s o n a N a t u r a l

a p e l l i d o P a t e r n oa p e l l i d o M a t e r n on o m b r en o m b r e B r e v ef e c h a U s u a r i oh o r a U s u a r i o

E m p l e a d o

f e c h a N a c i m i e n t of e c h a U s u a r i oh o r a U s u a r i o

R e p r e s e n t a n t e

f e c h a U s u a r i oh o r a U s u a r i o

C l i e n t e

U s u a r i o

n o m b r en u m e r o E s t a c i o nn i v e l A c c e s os u b N i v e l A c c e s on u m e r o A c c e s o s

Esquema de Herencia

• Asociación: Expresa una conexión bidireccional entre clases.

- Asociación binaria: Es una asociación exactamente entre dos clases, se representa

mediante una línea sólida que une dos clases.

Producto

descripciondescripcionBrevefechaRegis trocantidadfechaUsuariohoraUsuario

Persona

fechaRegistrofechaUsuariohoraUsuario

0.. * 0..*0.. * 0..*compra por factura

Asociación binaria

- Asociación ternaria: Los atributos de enlace o clases asociativas nacen para romper

relaciones con multiplicidades de muchos a muchos, este tipo de relación se conoce

como relación ternaria.



Fac tura

num eroItem Fac turaunidadM edidaprec ioUnitarioc ant idaddesc uento

P roduc to

des c ripc iondes c ripc ionB revefechaRegis troc antidadfechaUsuariohoraUs uario

P ers ona

fec haRegis trofec haUs uariohoraUs uario0..*0..* 0..*0..*

compra por fac t ura

• Agregación: La agregación representa un objeto compuesto por otros objetos conocida

también como relación parte de. Puede ser caracterizada con precisión determinando las

relaciones de comportamiento y estructura que existen entre el objeto agregado y cada

uno de sus objetos componentes. La anotación de UML para una relación de agregación

es una asociación con un diamante al lado de la clase que denota al agregado (entero).

Ver Figura 25.

Provincia

nom brenom breB reve

DeptoG

nom brenom breB reve

1

1..*

1

1..*

Elementos adicionales que detallan las relaciones

• Nombre: Toda relación debe llevar un nombre la cual consta de una cadena de caracteres

que sirve para identificar a la relación.

• Multiplicidad: Indican cuantos elementos de una clase se conectan con la otra clase. Se

escriben en cada extremo de la relación y estas pueden ser:

- uno o muchos: 1..* (1..n)

- 0 o muchos: 0..* (0..n)



- número fijo: m (m denota el número).

1.3.8 Diagrama de Objetos

Muestra un conjunto de objetos (instancias de las clases) y sus relaciones. Modelan las instancias de

elementos contendidos en los diagramas de clases, es decir las ocurrencias de cada elemento que

constituye una clase, a cada uno de estos elementos se les llama objetos. Son como fotos

instantáneas de los diagramas de clases.

Diagramas de objetos

Abstracciones más generales

Vehículo

Vehículo Terrestre Vehículo aéreo

Avión HelicópteroCoche Camión

Diagramas de objetos

Abstracciones más generales

VehículoVehículo

Vehículo TerrestreVehículo Terrestre Vehículo aéreoVehículo aéreo

AviónAvión HelicópteroHelicópteroCocheCoche CamiónCamión

Elementos que participan en un diagrama de Objetos

a) Objeto: En UML, un objeto se representa por un rectángulo con un nombre subrayado. Un

Objeto = Identidad + Estado + Comportamiento. Cada objeto posee su propia identidad

exclusiva y se puede hacer referencia a él mediante una denominación exclusiva que permite

accederle. El estado está representado por los valores de los atributos. Un atributo toma un

valor en un dominio concreto.

b) Mensajes: La unidad de comunicación entre objetos se llama mensaje. El mensaje es el

soporte de una comunicación que vincula dinámicamente los objetos que fueron separados

previamente en el proceso de descomposición. Adquiere toda su fuerza cuando se asocia al

polimorfismo y al enlace dinámico. Un estímulo causará la invocación de una operación, la

creación o destrucción de un objeto o la aparición de una señal. Un mensaje es la

especificación de un estímulo.



1.3.9 Diagrama de Secuencia

Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de

eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que

intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el

eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado.

Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los

distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de

tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o

activaciones a las que se refieren.

Diagrama de secuencia

:USUARIOAUTORIZADO

:TOTAL_D

ACTUALIZAR DEPOSITO F.T.

OK

Diagrama de secuencias asociadas al proceso “Actualizar Depósito”

ACTUALIZAR TOTAL_DOK



OK

:USUARIOAUTORIZADO

Diagrama de secuencia

:USUARIOAUTORIZADO

:TOTAL_D


OK





OK

:USUARIOAUTORIZADO

:USUARIOAUTORIZADO

:TOTAL_D


OK





OK

:USUARIOAUTORIZADO

Elementos que participan en un diagrama de Secuencia:

Objetos: Un objeto se representa con un rectángulo, que contiene el nombre y la clase del objeto en

un formato nombreObjeto: nombreClase.

a) Línea de vida de un objeto: Indica la vida de un objeto durante la interacción y se

representa como una línea vertical punteada debajo del rectángulo del objeto.

b) Mensaje: El envió de mensajes entre objetos se representa mediante una línea sólida dirigida

con cabeza de flecha abierta, desde el objeto emisor del mensaje hacia el objeto receptor.



Envío de mensaje

Mensajes al mismo objeto

c) Activación: Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando

alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus

atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto. Ver Figura

30.

1.3.10 Diagrama de Colaboración

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que

toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A



diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones

entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes

deben determinarse explícitamente mediante números de secuencia. Los diagramas de colaboración

permiten mostrar mejor como se vinculan los objetos, a cambio de hacer más difícil observar el orden

de ejecución, pues enumeran los mensajes en lugar de mostrar al tiempo como una dimensión, tal

como lo hacen los diagramas de secuencia.

Diagramas de colaboración

: Administrador

: Interfaz Principal del SICIA

: Interfaz de Identificación: Usuario

: Verificador de datos de Acceso

3: buscar conexión a red

1: Solicita acceso al Sistema

2: Verificar datos de acceso(usuario y

password)

5: Crear Ventana Principal

4: Guardar (usuario y password)

Diagramas de colaboración

: Administrador







password)



: Administrador







password)



Elementos que participan en un Diagrama de Colaboración

a) Objeto: Se representa con un rectángulo, que contiene el nombre y la clase del objeto en un

formato nombreObjeto: nombreClase.

b) Enlaces: Un enlace es una instancia de una asociación en un diagrama de clases. Se

representa como una línea que une a dos objetos.

Esta acompañada por un número que indica el orden dentro de la interacción y por un

estereotipo que indica que tipo de objeto recibe el mensaje. Los estereotipos indican si el

objeto que recibe el mensaje es un atributo (association y se asume por defecto), un

parámetro de un mensaje anterior, si es un objeto local o global. Ver Figura 32:



c) Flujo de mensajes: Expresa el envió de un mensaje. Se representa mediante una flecha

dirigida colocada cerca de un enlace. Ver Figura 33

1.3.11 Diagrama de Estado

Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso,

bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que

se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la

representación, un diagrama de estados es un grafico cuyos nodos son estados y cuyos arcos

dirigidos son transiciones etiquetadas con los nombres de los eventos. Capturan los cambios de

estado que sufren los objetos en respuesta a eventos. Los diagramas de clases y de objetos

correspondientes, sólo muestran los aspectos estáticos pero no muestran como son afectados los

objetos cuando ocurre algo. Sin embargo, estos comportamientos tienen que implementarse

mediante software y representarlos en algún sitio, asegura que los desarrolladores no adivinen el

comportamiento y produzcan software que satisfaga los requerimientos.



Diagramas de Estados

Persona

Con respecto a la poseción de R.U.C.

Persona Natural

EmpresaPersona Natural

Empresa Persona Juridica

Empleado Representante Cliente

Usuario

Banco

Diagramas de Estados

Persona


Persona Natural




Usuario

Banco

Persona


Persona Natural




Usuario

Banco

Todo objeto mantiene un estado durante algún tiempo, esperando a que ocurra algún evento que

produzca una transición de un estado a otro.

Elementos que participan en un Diagrama de Estados

a) Estado: Queda definido por ciertas características que un objeto mantiene en un periodo de

tiempo, en el cual el objeto puede recibir cierto tipo de estímulo como alguna condición,

operación u evento. Se representa mediante un rectángulo con los bordes redondeados, que

puede tener tres comportamientos: uno par el nombre del estado, otro para las variables de

estado (que son los valores característicos de los atributos del objeto en ese estado) y otro

para las acciones.

Por lo general se muestra sólo el nombre del estado.

P ers ona N a tu ra l

La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece

el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer

acciones de entrada, de salida y acciones internas.

b) Estado inicial: Define el inicio de un estado. Se representa mediante un círculo relleno.



c) Estado final: Define el final de un estado. Se representa mediante un círculo relleno rodeado

por una circunferencia.

d) Transición: Define el paso de una transición a otra. Una transición es una relación entre dos

estados que indica que un objeto en el primer estado puede o no entrar al segundo estado y

ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son

satisfechas.

e) Transición hacia el mismo: Define una transición ocurrida en un mismo objeto. Es una

transición que permanece en el mismo estado, en vez de involucrar dos estados distintos.

Representa un evento que no causa cambio de estado. Se denota como una cadena

adicional en el compartimiento de acciones del estado.

1.3.12 Diagramas de Actividad

Muestra la realización de operaciones para conseguir un objetivo. Presentan una visión simplificada

de lo que ocurre en un proceso, mostrando los pasos que se realizan. Los diagramas de actividad,

son una extensión de los diagramas de estado. Los diagramas de estado resaltan los estados y

muestran las actividades que dan lugar a cambios de estado, mientras que los diagramas de

actividad, resaltan justamente las actividades.

Comúnmente los diagramas de actividad se utilizan en dos formas. En el modelado de flujos de

trabajo, haciendo hincapié en las actividades tal y como son vistas por los actores que colaboran con

el sistema, esto es, modelando procesos de negocios.

En el modelado de una operación, utilizando los diagramas de actividad como diagramas de flujo para

mostrar detalles de un algoritmo, haciendo amplio uso de las condiciones y modelado de procesos

concurrentes



Diagrama de Actividades

Consultar cantidad de deuda de AGUESMA

¿Existe activos para realizar la compra?

Ordenar generación de Recibo de Pago

si existe

no existe

Verificar la existencia de activos para realizar la compra

Genera Recibo de Pago

¿Existe efectivo?

Entregar al Proveedor Recibo de Pago mas cantidad en efectivo

Generar Cheque de Pago

Entregar al Proveedor Recibo de Pago mas Cheque de Pago

Diagrama de Actividades: Generar Recibo de Pago

Verificar la existencia de efectivo

si existe

no existe

Asistente del Administrador de ComprasAdministrador de Compras

Diagrama de Actividades




si existe

no existe



¿Existe efectivo?






si existe

no existe





si existe

no existe



¿Existe efectivo?






si existe

no existe


Elementos que participan en un Diagrama de Actividades

a) Actividad: Representa la realización de una o varias tareas que causan un cambio en el

sistema. Se representa por un rectángulo redondeado El siguiente define la actividad

“Consultar Ficha de Guías de Remisión”.

b) Estado inicial: Define el inicio de una actividad.

c) Estado final: Define el fin de una actividad.

INICIO



d) Transiciones: Cuando se completa la ejecución de una actividad, el flujo de control pasa a la

siguiente actividad dando lugar a una transición. Este paso se representa mediante una línea

dirigida que va de la actividad que finaliza hacia la actividad a ejecutar. Las flechas entre

actividades representan transiciones, las cuales no deben ser etiquetados pues son

disparadas automáticamente por la finalización de la primera actividad.

e) Decisión: En los diagramas de actividad se puede incluir caminos alternativos según se

cumpla alguna condición. Esta condiciones se representa mediante un rombo al cual llega la

transición de la actividad origen y de la cual salen dos transiciones pactadas a cada actividad

destino, basado en diferentes condiciones, lo más frecuente es utilizarlo en dos decisiones

determinado por una condición booleana.

f) Barra de sincronización: Cuando se modela flujos de procesos, especialmente en los

procesos de negocio, suelen encontrarse actividades que se pueden realizar

simultáneamente. Estas actividades se pueden modelar con ayuda de las barras de

sincronización que se representa como una línea vertical u horizontal gruesa.

Conceptualmente las barras de sincronización muestran actividades concurrentes, sin

embargo en la realidad puede que no se ejecuten simultáneamente. La idea es indicar que

actividades se pueden realizar en paralelo, sin que ello signifique que deba forzosamente

realizarse así. Pueden realizarse en cualquier orden lo importante es dar la idea de que se

pueden ejecutar al mismo tiempo.

1.3.13 Diagramas de Componente

Los diagramas de componentes permiten visualizar las partes de un sistema, mostrando las diversas

formas en que pueden ensamblarse para construir ejecutables. Un diagrama de componentes

muestra las dependencias entre componentes físicos de software, tales como archivos de código



fuente, binarios, de configuración, de instalación y desinstalación, ejecutables, tablas, etc. Los

diagramas de componentes modelan la vista estática de los sistemas, es decir sólo los componentes

y sus conexiones y no como funcionan.

Diagramas de Componentes

LISTADOReservación

AGENCIADEVIAJES Actualizar

INTERFAZ

Diagramas de Componentes

LISTADOReservación


INTERFAZ

LISTADOReservación


INTERFAZ

Elementos que participan en un Diagrama de Componente

a) Componentes: Son cada una de las partes físicas y reemplazables de un sistema formados

por un conjunto de elementos lógicos como las clases y colaboraciones que proveen la

realización de un conjunto de interfaces. Se dice que es parte física en el sentido que viven

en el mundo de bites y no sólo en el mundo lógico de los esquemas conceptuales, así un

componente se encuentra en la computadora y no en la mente del analista. Se dice que es

reemplazable pues puede ser sustituido por un nuevo componente que mejore la

funcionalidad o añada alguna otra, sin que afecte a otros componentes. Esto se logra

mediante el uso de interfaces bien definidas. Así pues, los componentes no se ejecutan

solos, sino que necesitan 7de otros componentes para poder hacer que el sistema cumpla su

cometido, constituyendo una parte importante en cualquier software. Los componentes se

representan con un rectángulo que tiene en uno de sus lados dos pequeños rectángulos

sobresalientes.

Tipos de componentes:

• Componentes de trabajo.- Son aquellos componentes que contienen el código del

programa, como los archivos de código fuente.

• Componentes de distribución.- Son aquellos que se instalan con la versión ejecutable

del sistema como DLLs, ejecutables, controles Active X, Java Beans, etc.

• Componentes creados en tiempo de ejecución.- Son aquellos producto de la ejecución

del software, como los archivos de índice de las ayudas, los archivos temporales, etc.



b) Interfaces: Es una colección de operaciones que son usadas para especificar un servicio

provisto por una clase o un componente. Una interfaz es el rostro que presenta al mundo un

componente o una clase con la cual interaccionan otros componentes o clases. Las interfaces

de los componentes deben ser las mismas que las de las clases que lo conforman. Sólo se

pueden efectuar operaciones de los componentes por su interfaz, además el componente

puede hacer disponible su interfaz para que otros la usen. Las interfaces se representan, en

su forma compacta, mediante un círculo con una línea que lo une al componente que la

implementa.

1.3.14 Diagramas de Despliegue

El diagrama de despliegue, modela la topología del hardware sobre el cual correrá nuestra aplicación

y nos indica en donde se ejecutará cada uno de nuestros componentes; muestra las relaciones físicas

entre los componentes de software y el hardware de nuestro sistema.

Los diagramas de despliegue muestran la forma en que físicamente lucirá nuestro sistema, sólo

deben mostrarse los nodos y componentes que utilizarán en su versión ejecutable. El término original

para estos diagramas es deployment diagram que en nuestro idioma ha sido traducido como

diagramas de distribución, emplazamiento, implantación o despliegue

Diagrama de despliegue

Representa la visualización de

los componentes sobre los dispositivos físicos.

SERVIDOR

reservacioneslistado

<<Base de Datos >>

CLIENTE: PC

Agencia de Viajes

Diagrama de despliegue

Representa la visualización de

los componentes sobre los dispositivos físicos.

SERVIDOR


<<Base de Datos >>

CLIENTE: PC

Agencia de Viajes

SERVIDOR


<<Base de Datos >>

CLIENTE: PC

Agencia de Viajes



Elementos que participan en un Diagrama de Despliegue

a) Nodos: Es un elemento físico que representa un recurso computacional, generalmente

cuentan con memoria y capacidad de procesos y también pueden incluir recursos humanos o

procesos mecánicos. Un nodo es la representación de cualquier tipo de hardware sobre el

cual correrá nuestro sistema.

Un nodo se representa mediante un cubo en cuyo interior se incluye un nombre que lo

distinga de otros.

Tipos de nodos:

• Procesador (processor).- Es un tipo de nodo que tiene capacidad de proceso. Tenemos

por ejemplo: la computadora cliente, la computadora servidor, etc.

• Dispositivo (device).- Este tipo de nodo no tiene capacidad de proceso y representa las

interfaces con el mundo real. Tenemos por ejemplo: el fax, la impresora, el teléfono, etc.

b) Conexiones entre nodos: Los nodos se conectan mediante asociaciones de comunicación.

Como toda asociación se puede añadir detalles según se necesite, tales como roles,

multiplicidad, restricciones, etc.

Una conexión entre nodos se representa mediante una relación de asociación, esto es una

línea continua que une dos nodos.

1.4 ArgoUML

ArgoUML es una herramienta Open Source para modelar sistemas utilizando UML



http://argouml.tigris.org

ArgoUML está escrito 100% en Java, por esta razón debe funcionar en cualquier máquina con un

motor de Java. Java2, versión 1,3 o superior. Si no dispone de Java lo puede bajar libremente desde

Sun MicroSystems ( www.sun.com ). Observe que sólo necesita el ambiente runtime de Java (JRE),

no hay necesidad de descargar el kit entero del desarrollo de Java (JDK

ArgoUML necesita una cantidad razonable de recursos. Una PC con procesador 200MHz, 64Mb y

10Mb del espacio disponible en un disco.

Existen tres opciones para obtener ArgoUML.

1. Ejecutar ArgoUML directamente del Web site.

2. Descargando el código ejecutable binario, si es que ArgoUML será usado regularmente.

3. Descargue el código de fuente usando CVS y construya su propia versión. Eligiremos esta

opción si deseamos ver el funcionamiento de java..

Las tres opciones están libremente disponibles con el Web site del proyecto, argouml.tigris.org.

Descargar el ejecutable binario



En primer lugar crearemos un directorio donde realizaremos la descarga y la instalación del paquete

ArgoUML. Por ejemplo, vamos a crear el directorio llamado argoUML. Para descargar la última

versión conéctese a la página http://argouml.tigris.org/.

Si elegimos descargar el binario hay que asegurarnos de descargar la versión más estable que en

este momento es la version 0.18.1. Una vez realizada la descarga descomprima el ZIP dentro del

directorio creado.

Para ejecutar la aplicación argoUML lo puede hacer:

• Si usa Linux desde una consola introduciendo la orden: java -jar argouml.jar

• Si usa Windows hacer doble clic en el archivo argouml.jar

Para asegurar su ejecución aconsejamos situarse en el directorio de la aplicación.

Pantalla Principal

La ventana inicial de la aplicación se estructura en distintas zonas que facilitan la construcción de

modelos OO en ArgoUML



a) Barras de herramientas.

b) Zona de dibujo: donde se realizan los diagramas en notación UML.

c) zona de jerarquía de objetos.

d) zona de características de objeto.

e) entre otras que no aparecen.

1.4.1 Partes de ArgoUML

Barra de herramientas de diagramas

Desde esta barra de herramientas podremos seleccionar el diagrama de dibujo de UML que

deseamos construir. Sitúese con el cursor sobre cada icono para ver qué diagrama representa.

Algunos de ellos aparecen inicialmente desactivados. Los diagramas inicialmente activos son: el

diagrama de clases, diagrama de casos de uso y el diagrama de instalación (deployment).

Barra Herramientas

Zona de dibujo

En esta zona podremos modelar (dibujar) algo usando la notación (elementos de dibujo) del diagrama

seleccionado.

Área de Dibujo



Zona de jerarquía de objetos

En esta zona de la pantalla se irá mostrando la jerarquía de objetos que se van creando en la zona de

dibujo.

Jerarquía Objetos

Zona de características de los objetos

Es una zona donde podremos editar las características (visuales o no) del objeto que queremos

modelar.

Características Objetos



1.5 ACTIVIDADES

1.5.1 AUTO EVALUACIÓN

Responda marcando la alternativa correcta:

1. El primer paso para desarrollar un sistema de software es:

a) Programar el código

b) Modelar el sistema

c) Diseñar la base de datos

d) NA

2. UML es:

a) Un lenguaje de programación orientado a objetos

b) Un lenguaje para modelar sistemas de software

c) Un lenguaje para modelar bases de datos.

d) NA

3. ¿Qué hace un diagrama de casos de usos?

a) Representa las clases

b) Representa objetos relacionales

c) Represente el esquema macro de la aplicación

d) Construye dll.

4. ¿Qué representa un diagrama de clases?

a) Atributos

b) Atributos y Comportamiento

c) Objetos

d) Entidades

5. ¿Qué es ArgoUML?

a) Una herramienta para hacer diagramas UML

b) Una herramienta para programar orientado a objetos

c) Una herramienta para modelar bases de datos.

d) Ninguna

6. La relación entre un caso de uso (Comprar Item) con un caso de uso (Comprar Embutidos).

a) <<include>>

b) <<extend>>

c) <<use>>

d) NA

7. El diagrama de despliegue, modela:

a) Hardware

b) La topología del Hardware

c) El Software



d) Ninguna

8. El comportamiento de un objeto esta representado por los valores de las variables que

almacena.

a) Verdadero

b) Falso

9. ArgoUML permite hacer modelamiento de base de datos

a) Verdadero

b) Falso

10. ArgoUML puede jalar diagramas de otros programas

a) Verdadero

b) Falso

1.5.2 Laboratorio

Laboratorio 1

Generando Diagrama Caso de Usos

Duración

30 minutos

Objetivos

• Diseñar aplicaciones comerciales

• Comprender el modelamiento de aplicaciones usando UML

Recursos

01 Equipo PC con Linux y ArgoUML

Proceso de Ejecución

1. En primer lugar deberíamos tener en ejecución la aplicación ArgoUML, para eso utilice el

comando java –jar argouml.java o use el acceso directo que encuentre en el escritorio de su

PC.

2. Para crear un proyecto nuevo sólo hay que seleccionar la secuencia de opciones Archivo >

Nuevo en el menú principal. Como se puede ver en la parte izquierda de la ventana, un

proyecto nuevo genera por defecto un diagrama de casos de clases y un diagrama de casos

de uso (ambos vacíos) con los nombres "Use Case Diagram 1" y "Class Diagram 1",

respectivamente.

3. El nombre por omisión para el proyecto es "untitledModel". Para cambiar un nombre de

elemento en la ventana de jerarquías (parte izquierda) se hace seleccionando el elemento y

modificando el nombre en la casilla "Nombre" de la ventana de características (ventana



inferior).Vamos a modificar el nombre del proyecto por el de "Restaurante". Cuando

introduzca el nombre en la casilla, pulse con el cursor sobre la zona de dibujo para actualizar

la ventana de jerarquías.

4. Ahora vamos a empezar definiendo la estructura general del sistema que queremos

construir. Normalmente se comienza con los diagramas de casos de uso. En primer lugar,

dado que en la ventana de jerarquías ya existe un diagrama de casos de uso vacío, vamos a

utilizarlo para nuestros propósitos. Primero modifiquemos el nombre del diagrama de forma

similar a como se ha explicado en el paso anterior para el nombre del proyecto. Vamos a

darle el nombre "Gestión Restaurante".

5. En la zona de dibujo debería aparecer la barra de herramientas para dibujar diagramas de

casos de uso. Pulse directamente sobre la zona de dibujo.

6. De acuerdo a la Figura Nº 41 desarrolle el mismo diagrama utilizando la barra de

herramientas asociada. Para ello, como consejo, comience introduciendo los actores, luego

la caja del sistema, luego los casos de uso y por último las conexiones. Como se puede

apreciar también, los elementos que no tienen un nombre asignado, ArgoUML le pone el

término "anon" (sin nombrar) en la ventana de jerarquías. Por ejemplo, las conexiones que

hemos creado han sido todas ellas conexiones del tipo "Asociación normal" (una línea

simple) a las que no les hemos asignado ningún nombre y por este motivo aparecer el texto

"anon Association".

Laboratorio 2

Generando Diagrama de Clases

Duración



30 minutos

Objetivos

• Diseñar aplicaciones comerciales

• Comprender el modelamiento de aplicaciones usando UML

Recursos

01 Equipo PC con Linux y ArgoUML

Proceso de Ejecución

1. Ahora vamos a dibujar un diagrama de clases para nuestro ejemplo, para ello y como antes,

dado que tenemos un diagrama de clases creado por defecto en el proyecto, vamos a

renombrarlo para nuestros propósitos. Vamos a darle el nombre "El Restaurante".

2. Tras modificar el nombre, pulse en la ventana de dibujo para empezar a realizar el diagrama

de clases.

3. Comience primero introduciendo las clases en el diagrama, asignándole un nombre a cada

clase en el momento que las genere. Por omisión, la sección de atributos y operaciones de

una clase se muestran vacías.

4. Como puede comprobar en el diagrama, sólo introduciremos algunas operaciones para

alguna de las clases del diagrama, para simplificar el ejercicio: Clientes, Camarero,

Cocinero, Cajero.

5. Por tanto, un cliente podrá realizar las siguientes operaciones:

o pedir un plato de comida: pedirComida()

o pedir un vaso de vino: pedirVino()

o pedir la factura: pedirFactura()

o pagar la factura: pagarFactura()

6. El camarero podrá realizar las siguientes operaciones:

o pedir comida a cocina: pedirComida()

o servir el vino al cliente: servirVino()

o servir el plato de comida al cliente: servirComida()

7. El cocinero podrá realizar las siguientes operaciones:

o cobrar la factura: cobrarFactura()

8. El orden en el que se introduzcan las operaciones dentro de una clase no influye en el

resultado final del diagrama. Introduzca las operaciones para aquellas clases indicadas.

9. Seleccione este icono para introducir nuevas operaciones en una clase. Este icono lo podrá

encontrar en la barra de herramientas de la ventana de dibujo, o en la barra de herramientas

de la ventana de características (abajo), siempre que haya seleccionado la clase.

10. Introduzca las conexiones entre clases siguiendo el modelo de la figura objetivo. Seleccione

primero el tipo de conexión que desea (en la forma explicada), luego pulse sobre la clase

origen y sin soltar el botón del ratón, arrastre el cursor sobre la clase destino con la que



desea conectar, por último suelte el botón izquierdo. Puede reorganizar la forma y

orientación de las líneas y la ubicación de las clases directamente con el cursor del ratón.

11. Asigne nombres a las conexiones, tal y como se indica en la figura objetivo.

12. La cardinalidad se puede introducir situando el cursor sobre uno de los extremos de la línea

de conexión y luego pulsando el botón derecho del ratón. Luego, en la opción de

multiplicidad seleccione la cardinalidad que requiera.

1.6 Bibliografía y enlaces recomendados

o G. Booch, I. Jacobson, J. Rumbaugh. El Lenguaje Unificado de Modelado. Guía del

usuario. Addison-Wesley/Diaz de Santos,1999.

o J. Rumbaugh, I. Jacobson, G. Booch, El Lenguaje Unificado de Modelado. Manual de

referencia. Addison-Wesley,2000.

o OMG, "Unified Modeling Language. Notation Guide". OMG Version 1.4.

Sitios Web

o http://argouml.tigris.org/ (ArgoUML)

o http://www.uml.org/ (UML)

modulo_1-_introduccion_al_desarrollo_de_aplicaciones

Documents