Modulo 1 - Introduccion Al Desarrollo de Aplicaciones

Desarrollo de Aplicaciones I
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.
INICTEL-UNI 1 Módulo 1
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 OBJETO
Var Marca = string()

Características
Var Modelo = string()
( Variables)
Var Color = string()
método arrancar()
método acelerar() Comportamiento

(métodos)
método frenar()
método retroceder()
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.).
Clase: CELULAR
CELULAR
Objeto: Mi_Celular
Var Marca = string()
Var Modelo = string()

Mi_Celular
método llamar()
método colgar() Var Marca = Motorola
Var Modelo = V220
método llamar()
método colgar()
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 CELULAR
NUEVO MALOGRADO
Precio = string() motivo = string()
fecha_ing = string() motivo = string()
método llamar() método llamar()
método colgar() 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.
Diagrama de Casos de Usos

Comunica Actualizar carga
academica
<<extend>>
Actor
Actualizar Elaborar <<use>> Elaborar
carga Informe de Planificación
Administrativa Actividades de Actividad
Profesor Pedir Permiso
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>>
Hacer una cita Identificarse
Paciente
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>>
Pagar con tarjeta Pagar
Cliente
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>>
Pagar con tarjeta Imprimir Voucher
Cliente
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>
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.
Producto
descripcion Presentacion
descripcionBreve 0..* tiene 1 descripcion
fechaRegistro
descripcionBreve
cantidad
simbolo
fechaUsuario
horaUsuario
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 rs o n a N a tu r a l
a p e llid o P a t e rn o
a p e llid o M a t e rn o
n o m b re
n o m b re B re ve
fe c h a U s u a r i o
h o ra U s u a rio
E m p le a d o R e p re s e n ta n te C lie n t e
fe c h a N a c i m i e n t o fe c h a U s u a r i o
fe c h a U s u a r i o h o ra U s u a rio
h o ra U s u a rio
U s u a rio
n o m b re
n u m e ro E s t a c io n
n ive lA c c e s o
s u b N ive lA c c e s o
n u m e ro 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.
Produc to
Persona descripcion
compra por factura descripcionBreve
fechaRegistro 0.. * 0..*
fechaRegis tro
fechaUsuario
cantidad
horaUsuario
fechaUsuario
horaUs uario
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.
P roduc to
des c ripc ion P ers ona
des c ripc ionB reve
c ompr a por fac t ura fec haRegis tro
fec haRegis tro
fec haUs uario
c antidad 0..* 0..* horaUs uario
fec haUs uario
horaUs uario
F ac tura
num eroItem F ac tura
unidadM edida
prec ioUnitario
c antidad
des c uento
• 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.
DeptoG
nom bre
nom breB reve
1..*
Provincia
nom bre
nom breB reve
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
Coche Camión Avión Helicóptero
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
:USUARIO :USUARIO :TOTAL_D
AUTORIZADO AUTORIZADO
ACTUALIZAR
DEPOSITO F.T.
OK ACTUALIZAR
TOTAL_D
OK
ACTUALIZAR ACTUALIZAR
DEPOSITO F.T. TOTAL_D
OK OK
Diagrama de secuencias asociadas al proceso “Actualizar Depósito

”
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
1: Solicita acceso al Sistema
: Usuario
: Administrador : Interfaz de Identificación
2: Verificar datos de
acceso(usuario y
password) 4: Guardar (usuario y
password)
5: Crear Ventana Principal
3: buscar conexión a red
: Interfaz Principal del SICIA : Verificador de datos de

Acceso
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 Empresa Persona

Natural Juridica
Empleado Representante Cliente Banco
Usuario
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 e rs o n a
N a t u 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
Administrador de Compras Asistente del Administrador de Compras
Diagrama de Actividades:
Generar Recibo de Pago
Consultar cantidad de
deuda de AGUESMA
Genera Recibo
de Pago
Verificar la existencia de activos
para realizar la compra
Ordenar generación de Verificar la existencia

Recibo de Pago de efectivo
si existe
¿Existe activos para ¿Existe
realizar la compra? efectivo? si existe
no existe Entregar al Proveedor Recibo de
Pago mas cantidad en efectivo
Generar Cheque
de Pago
no existe
Entregar al Proveedor Recibo de
Pago mas Cheque de Pago
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.
INICIO
c) Estado final: Define el fin de una actividad.
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
Reservaci
ón
LISTADO
AGENCIADE
VIAJES Actualizar
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
SERVIDOR
Representa la <<Base de Datos >>
visualización de
listado
los reservaciones
componentes
sobre los CLIENTE: PC
dispositivos
Agencia de Viajes
físicos.
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

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modulo 1 - Introduccion Al Desarrollo de Aplicaciones

Hochgeladen von

Copyright:

Verfügbare Formate

Desarrollo de Aplicaciones I

CURSO 1: Desarrollo de Aplicaciones I

Objetivo General del Curso

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

• Modelar aplicaciones comerciales utilizando el lenguaje UML

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

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

• Identificar el entorno actual de aplicaciones comerciales.

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

1.1 Aplicaciones Comerciales. 5

1.1 Aplicaciones Comerciales

1.1.2 ¿Qué son las Aplicaciones Comerciales?

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

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

• Guías para estimar costos.

• Técnicas para adaptar el método.

1.2.1 Metodología Orientada a Objetos

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.

• Agiliza el desarrollo de software.

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

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

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

1.2.3 El modelo OO (Orientado a Objetos)

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

Para esto necesitamos conocer algunas definiciones básicas:

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

Var Marca = string()

método acelerar() Comportamiento

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

• El estado evoluciona con el tiempo.

Var Modelo = string()

método colgar() Var Marca = Motorola

Var Modelo = V220

Precio = string() motivo = string()

fecha_ing = string() motivo = string()

método llamar() método llamar()

método colgar() método colgar()

d. Definición de Envío de Mensajes

CARACTERISTICAS ASOCIADAS AL MODELAMIENTO ORIENTADO A OBJETOS

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

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

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

1.3 UML (Unified Modeling Language)

1.3.1 Definición de UML

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

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

1.3.2 Características del UML

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

1.3.3 Objetivos del UML

1.3.4 Utilidad del UML

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

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

1.3.5 Diagramas de UML

1.3.6 Diagrama de Caso de Uso

Diagrama de Casos de Usos

Profesor Pedir Permiso

Elementos que participan en un Diagrama de Caso de Uso

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

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

Representación de un caso de uso

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

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