UML Monografia

MODELOS DEL PROCESO DEL SOFTWARE
1
2
Introduccin
En el presente mdulo se permite entregar un material de apoyo que le permita

al alumno poder definir diagramas propios como tambin poder entender el
modelamiento de diagramas ya existentes, y finalmente se analiza los
3
diagramas que componen UML y ofrece acercamientos a casos de uso guiados

sobre cmo estos diagramas se usan para modelar sistemas, toda vez que el
Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es
un lenguaje grfico para visualizar, especificar y documentar cada una de las
partes que comprende el desarrollo de software. UML entrega una forma de
modelar cosas conceptuales como lo son procesos de negocio
y funciones de sistema, adems de cosas concretas como lo son escribir
clases en un lenguaje determinado, esquemas de base de datos y
componentes de software reusables.
El lenguaje UML
Cualquier rama de ingeniera o arquitectura ha encontrado til desde hace

mucho tiempo la representacin de los diseos de forma grfica. Desde los
inicios de la informtica se han estado utilizando distintas formas de
representar los diseos de una forma ms bien personal o con
4
algn modelo grfico. La falta de estandarizacin en la manera de representar

grficamente un modelo impeda que los diseos grficos realizados se
pudieran compartir fcilmente entre distintos diseadores.+
MODELADO VISUAL
Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es
una simplificacin de la realidad. El objetivo del modelado de un sistema es
capturar las partes esenciales del sistema. Para facilitar este modelado, se
realiza una abstraccin y se plasma en una notacin grfica. Esto se conoce
como modelado visual.
UML es adems un mtodo formal de modelado. Esto aporta las siguientes

ventajas:
Mayor rigor en la especificacin.
Permite realizar una verificacin y validacin del modelo realizado.
Se pueden automatizar determinados procesos y permite generar cdigo a
partir de los modelos y a la inversa (a partir del cdigo fuente generar los
modelos). Esto permite que el modelo y el cdigo estn actualizados, con lo
que siempre se puede mantener la visin en el diseo, de ms alto nivel, de
la estructura de un proyecto.
HISTORIA DE UML
El lenguaje UML comenz a gestarse en octubre de 1994 [1], cuando
Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados
investigadores en el rea de metodologa del software). El objetivo de ambos
era unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT
(Object Mode-lling Tool ). El primer borrador apareci en octubre de 1995. En
esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se
incluyeron ideas suyas. Estas tres personas son conocidas como los "tres
amigos". Adems, este lenguaje se abri a la colaboracin de
otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definicin de la primera versin de UML.
5
Qu es UML?
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe
la semntica esencial de lo que estos diagramas y smbolos significan.
Mientras que ha habido muchas notaciones y mtodos usados para el diseo
orientado a objetos, ahora los modeladores slo tienen que aprender una nica
notacin.
Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
Visualizar: UML permite expresar de una forma grfica un sistema de forma
que otro lo puede entender.
Especificar: UML permite especificar cules son las caractersticas de un
sistema antes de su construccin.
Construir: A partir de los modelos especifica-dos se pueden construir los
sistemas diseados.
Documentar: Los propios elementos grficos sirven como documentacin del
sistema desarrollado que pueden servir para su futura re-visin.
Aunque UML est pensado para modelar sistemas complejos con gran
cantidad de software, el lenguaje es los suficientemente expresivo como para
modelar sistemas que no son informticos, como flujos de trabajo (workflow )
en una empresa, diseo de la estructura de una organizacin y por supuesto,
en el diseo de hardware.
Un modelo UML est compuesto por tres clases de bloques de construccin:
Elementos: Los elementos son abstracciones de cosas reales o ficticias
(objetos, acciones, etc.)
Relaciones: relacionan los elementos entre s.
Diagramas: Son colecciones de elementos con sus relaciones.
DIAGRAMAS UML
Un diagrama es la representacin grfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar.
Para poder representar correctamente un sistema, UML ofrece una amplia
6
variedad de diagramas para visualizar el sistema desde varias perspectivas

UML ofrece nueve diagramas en los cuales modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos "business".
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboracin para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el
sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de
Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en el
sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos en el
sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementacin para modelar la distribucin del sistema.
Figura 3: Diagrama de casos de uso
7
Figura 4: Diagrama de clases
UML ofrece notacin y semntica estndar

UML preescribe una notacin estndar y semnticas esenciales para el
modelado de un sistema orientado a objetos. Previamente, un diseo orientado
a objetos podra haber sido modelado con cualquiera de la docena de
metodologas populares, causando a los revisores tener que aprender las
semnticas y notaciones de la metodologa empleada antes que intentar
entender el diseo en s. Ahora con UML, diseadores diferentes modelando
sistemas diferentes pueden sobradamente entender cada uno los diseos de
los otros.
8
UML no es un Mtodo
Aun as, UML no preescribe un proceso o mtodo estndar para desarrollar un
sistema. Hay varias metodologas existentes; entre las ms populares se
incluyen las siguientes:
Catalysis: Un mtodo orientado a objetos que fusiona mucho del trabajo
reciente en mtodos orientados a objetos, y adems
ofrece tcnicas especficas para modelar componentes distribuidos.
Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por
Ivar Jacobson.
Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en
marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida
de Objetos, modelando el Mundo en Estados y Ciclos de vida de Objetos,
Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor continan
actualizando su mtodo continuamente (la actualizacin ms reciente es el
OOA96 report), y recientemente publicaron una gua sobre cmo usar la
notacin UML con Shlaer/Mellor.
Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como
primer intento de un mtodo de diseo orientado a objetos estndar. Combina
OMT y Booch con tarjetas CRC y mtodos formales.
(www.hpl.hp.com/fusion/file/teameps.pdf)
OMT: La Tcnica de Modelado de Objetos fue desarrollada por James
Rumbaugh y otros, y publicada en el libro de gran influencia "Diseo y
Modelado Orientado a Objetos" (Prentice Hall, 1991). Un mtodo que propone
anlisis y diseo "iterative", ms centrado en el lado del anlisis.
Booch: Parecido al OMT, y tambin muy popular, la primera y
segunda edicin de "Diseo Orientado a Objetos, con Aplicaciones" (Benjamin
Cummings, 1991 y 1994), (Object-Oriented Design, With Applications), detallan
un mtodo ofreciendo tambin diseo y anlisis "iterative", centrndose en el
lado del diseo.
XML Schemas en UML extendido

Un XML Schema es un documento que define el contenido y la estructura de
un tipo de documento XML, es decir, describe los elementos y atributos que
9
puede contener un documento y la forma en la que se pueden definir dentro de

una estructura jerrquica de un documento vlido.
Dado que XML Schema no tiene su propia notacin grfica se ha decidido
utilizar UML. Sin embargo, este lenguaje no permite representar directamente
estos esquemas, con lo que ser necesario realizar una extensin al mismo.
Una perspectiva general de UML
Una vuelta por un caso de uso

Una vez ms, UML es una notacin, no un mtodo. No preescribe un proceso
para modelar un sistema.
No obstante, como UML incluye los diagramas de casos de uso, se le
considera estar dotado de una aproximacin al diseo centrada en el problema
con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada
para analizar los requisitos del sistema, y el problema que necesitamos
solucionar.
Casos de Uso y Diagramas de Interaccin

Un caso de uso se modela para todos los procesos que el sistema debe llevar
a cabo. Los procesos se describen dentro de el caso de uso por una
descripcin textual o una secuencia de pasos ejecutados. Los Diagramas de
Actividad se pueden usar tambin para modelar escenarios grficamente.
Clases y Diagramas de Implementacin

Conforme se van encontrando los objetos, pueden ser agrupados por tipo y
clasificados en un Diagrama de Clase. Es el diagrama de clase el que se
convierte en el diagrama central del anlisis del diseo orientado a objetos, y el
que muestra la estructura esttica del sistema.
Tarjetas CRC (CRC cards) - Una extensin informal de UML

Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede
usar para guiar el sistema a travs de anlisis guiados por la responsabilidad.
Las clases se examinan, se filtran y se refinan en base a sus responsabilidades
10
con respecto al sistema, y las clases con las que necesitan colaborar para
completar sus responsabilidades.
Diagramas de Estado
El comportamiento en tiempo real de cada clase que tiene comportamiento
dinmico y significativo, se modela usando un Diagrama de Estado. El
diagrama de actividad puede ser usado tambin aqu, esta vez como una
extensin del diagrama de estado, para mostrar los detalles de las acciones
llevadas a cabo por los objetos en respuesta a eventos internos. El diagrama
de actividad se puede usar tambin para representar grficamente las acciones
de mtodos de clases.
Implementando el diseo
La implementacin del sistema trata de traducir informacin desde mltiples
modelos UML en cdigo y
estructura de bases de datos. Cuando se modela un sistema grande, es til
fragmentar el sistema en su capa "business" (incluyendo los objetos de la
interfaz de usuario), su capa de aplicacin (incluyendo los objetos de
implementacin), y su capa de datos (incluyendo la estructura de la base de
datos y el acceso a objetos).
Implementando la aplicacin
11
El Diagrama de Clase se usa para generar una estructura base del cdigo en el
lenguaje escogido.
Informacin de los diagramas de interaccin, estado, y actividad, puede ofrecer
detalles de la parte procedimental del cdigo de implementacin.
Implementando el diseo de Bases de Datos

La capa de datos del diagrama de clase se puede usar para implementar
directamente un diseo orientado a objetos de una base de datos, o, como
extensin de UML, puede ser referenciado en un diagrama de relacin de
entidad para ms anlisis de relaciones de entidad. Est en el diagrama de
relacin de entidad (ER diagram, entity relationship) el cual relaciona entre
entidades que pueden ser modeladas basadas en atributos clave. El diagrama
de relacin de entidad lgico ofrece una base desde la cual construir un
diagrama fsico representando las tablas y relaciones actuales de la base de
datos relacional.
Probar teniendo en cuenta los requisitos

Los casos de uso se utilizan tambin para probar el sistema y ver si satisface
los requisitos iniciales. Los pasos de los casos de uso van llevando a cabo para
determinar si el sistema est satisfaciendo los requisitos del usuario.
Un estudio a fondo de UML
Las siguientes secciones presentan una vista ms detallada al modelado con

UML. Un sistema de reserva de aerolneas simple se va a usar para mostrar los
diagramas y tcnicas de modelado con UML. Se cubren los siguientes puntos:
Organizando tu sistema con paquetes
Modelando con Casos de Uso, y usndolos para averiguar los requisitos del
sistema
Modelando con Diagramas de Secuencia y Colaboracin
Analizando y diseando con el Diagrama de Clase, y extendiendo UML con la
tcnica de las tarjetas
CRC
Modelando comportamiento con Diagramas de Actividad y de Estado
12
Modelando componentes de software, distribucin e implementacin

Extendiendo UML con el diseo de Bases de Datos relacionales
Modelado de Casos de Uso

El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms
simple para modelar los requisitos del sistema desde la perspectiva del usuario.
Estudiar y descubrir los requisitos

El objetivo final en cualquier diseo de software es satisfacer los requisitos del
usuario para el sistema.
Estos requisitos pueden ser requisitos de software, requisitos de productos, o
requisitos de pruebas. La meta de capturar y comprobar los requisitos del
usuario es asegurar que todos los requisitos son completados por el diseo, y
que el diseo es acorde con los requisitos especificados.
Muchas veces los requisitos del sistema ya existen en forma de documentos de
requisitos. Los casos de uso se utilizan para correlacionar cada escenario con
13
los requisitos que completa. Si los requisitos no existen, modelar el sistema a

travs de los Casos de Uso, permite el descubrimiento de estos requisitos.
Organizacin de Diagramas de Casos de Uso

Durante el anlisis de negocio (business) del sistema, puedes desarrollar un
modelo de caso de uso para este sistema, y construir paquetes para
representar los varios dominios de negocio (business) del sistema.
Puedes descomponer cada paquete con un Diagrama de Caso de Uso que
contenga los Casos de Uso de un dominio, con interacciones de actor.
Un Caso de Uso para cada escenario

El objetivo es construir un Diagrama de Caso de Uso para cada tipo de
escenario diferente en el sistema. Cada escenario muestra una secuencia
diferente de interacciones entre actores y el sistema, sin condiciones "or".
Modelar secuencias alternas a travs de la relacin "Extiende"

(extends)
Tpicamente, uno modela cada Caso de Uso con una secuencia normal de
acciones. El usuario entonces considera condiciones "que si" para cada paso, y
desarrolla Casos de Uso basados en estas secuencias alternas de eventos.
Las secuencias alternas se modelan en casos de uso separados, los cuales
estn relacionados con el caso de uso original mediante una relacin
"Extiende" (extends). Las relaciones Extiende (extends) pueden ser pensadas
como un caso de uso equivalente a herencia, en el cual el caso de uso
extendido, hereda y modifica el comportamiento del caso de uso original.
En UML la relacin de extensin es un elemento especial de modelado, por lo
tanto la relacin aparece explcitamente en las siguientes definiciones.
Eliminar el modelado redundante a travs de la relacin "Incluir"

(Include)
Para eliminar el modelado redundante de buena parte del comportamiento que
aparezca en varios casos de uso, la parte del comportamiento puede ser
modelada en un caso de uso separado que est relacionado con los otros
14
casos de uso mediante la relacin "Incluir" (Include). La relacin Incluir

(Include) se puede pensar como un caso de uso equivalente "of aggregation".
La relacin Include
Una relacin include entre dos Casos de Uso indica que el comportamiento
definido en el Caso de Uso a adicionar, es includo en un lugar dentro de la
secuencia del comportamiento realizado por una instancia del Caso de Uso
base. Cuando una instancia del Caso de Uso llega al lugar donde el
comportamiento de otro Caso de Uso debe ser includo, ejecuta todo el
comportamiento descripto por el Caso de Uso includo y luego contina de
acuerdo a su Caso de Uso original. El Caso de Uso includo no depende del
Caso de Uso base. En este sentido, el Caso de Uso includo representa
comportamiento encapsulado que puede ser reusado en varios Casos de Uso.
Ayuda en casos de uso probando el sistema frente a los requisitos

Los Casos de Uso tambin se utilizan para construir scripts de prueba que se
usan a su vez para comprobar que la aplicacin satisface los requisitos de
negocio y de sistema.
Diagramas de Secuencia
El Diagrama de Secuencia es uno de los diagramas ms efectivos para
modelar interaccin entre objetos en un sistema. Un diagrama de secuencia se
modela para cada caso de uso. Mientras que el diagrama de caso de uso
permite el modelado de una vista "business" del escenario, el diagrama de
secuencia contiene detalles de implementacin del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario, y mensajes
pasados entre los objetos.
Tpicamente uno examina la descripcin de un caso de uso para determinar
qu objetos son necesarios para la implementacin del escenario. Si tienes
modelada la descripcin de cada caso de uso como una secuencia de varios
pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu
objetos son necesarios para que se puedan seguir los pasos.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario
con lneas discontinuas verticales, y los mensajes pasados entre los objetos
15
como vectores horizontales. Los mensajes se dibujan cronolgicamente desde

la parte superior del diagrama a la parte inferior; la distribucin horizontal de los
objetos es arbitraria.
Diagramas de Colaboracin
El Diagrama de Colaboracin presenta una alternativa al diagrama de
secuencia para modelar interacciones entre objetos en el sistema. Mientras que
el diagrama de secuencia se centra en la secuencia cronolgica del escenario
que estamos modelando, el diagrama de colaboracin se centra en estudiar
todos los efectos de un objeto dado durante un escenario. Los objetos se
conectan por medio de enlaces, cada enlace representa una instancia de una
asociacin entre las clases implicadas. El enlace muestra los mensajes
enviados entre los objetos, el tipo de mensaje (sincrnico, asincrnico, simple,
blanking, y "time-out"), y la visibilidad de un objeto con respecto a los otros.
Anlisis y Diseo con el Diagrama de Clase

El Diagrama de Clase es el el diagrama principal de diseo y anlisis para un
sistema. En l, la estrucutra
de clases del sistema se especifica, con relaciones entre clases
y estructuras de herencia. Durante el
anlisis del sistema, el diagrama se desarrolla buscando una solucin ideal.
Durante el diseo, se usa el
mismo diagrama, y se modifica para satisfacer los detalles de las
implementaciones.
3.4.1. Desarrollo de Diagramas de Clase durante el anlisis

3.4.1.1. Aproximacin a un Caso de Uso guiado
En una aproximacin a un Caso de Uso guiado hacia el anlisis orientado a
objetos, el diagrama de clases se desarrolla a travs de informacin obtenida
en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboracin.
Los objetos encontrados durante el anlisis son modelados en trminos de la
clase a la que instancian, y las interacciones entre objetos son referenciados a
relaciones entre las clases instanciadas.
16
3.4.1.2. Extensin guiada por la responsabilidad

La tcnica de la tarjeta CRC se usa a veces como una extensin a UML para
anlisis guiados por la responsabilidad. Las definiciones de clase son refinadas
basndose en las responsabilidades de clase y en otras clases con las que
colabora para completar sus responsabilidades.
Cada clase se representa en una tarjeta ndice (index card), y los diseadores
establecen los papeles (roles) de las clases en el sistema para definir su
trabajo, y con qu otras necesitan colaborar para completar sus
responsabilidades. Esta informacin se pasa directamente a un diagrama de
clase; las responsabilidades coinciden con los mtodos de clase, las
colaboraciones se traducen en asociaciones entre clases.
3.4.2. Diseo del sistema con Diagramas de Clase
Durante el diseo, el Diagrama de Clase se elabora para tener en cuenta los

detalles concretos de la implementacin del sistema.
3.4.2.1. Arquitecturas Multicapas

Una vez concienciados del diseo, estableceremos la arquitectura del sistema.
Esto incluye establecer si ser un sistema simple diseado para correr en una
sola mquina, un sistema "two-tiered" consistente en un cliente y un servidor, o
un sistema "multi-tiered" con objetos interfaz de usuario separados de los
objetos "business", separado de la base de datos, cada uno corriendo en
plataformas distintas.
3.4.2.2. Diseo de Componentes

Un componente es un grupo de objetos o componentes ms pequeos que
interaccionan entre ellos y se combinan para dar un servicio. Un componente
es similar a una caja negra, en la cual los servicios del componente se
especifican por su interface o interfaces, sin ofrecer conocimiento del diseo e
implementacin internas del componente. El desarrollo basado en
componentes es el proceso de ensamblar la combinacin correcta de
17
componentes en la configuracin correcta para llevar acabo la funcionalidad

deseada para un sistema.
3.4.2.3. Anlisis y diseo "Iterative"

El diagrama de clase se puede desarrollar en una "iterative fashion", a travs
de un ciclo repetido de anlisis, diseo e implementacin, y despus vuelta al
anlisis, para empezar el ciclo de nuevo. Este proceso se suele llamar "round-
trip engineering". El modelado de herramientas como System Architect 2001
puede facilitar este proceso permitindote implementar el diseo en
un lenguaje como C++ o Java, y despus traer de vuelta al cdigo a al
diagrama de clase, automticamente actualizando la informacin contenida en
el diagrama y en el "underlying repository".
Modelando el comportamiento de las Clases con Diagramas de

Estado
18
Mientras los diagramas de interaccin y colaboracin modelan secuencias

dinmicas de accin entre grupos de objetos en un sistema, el diagrama
de estado se usa para modelar el comportamiento dinmico de un objeto en
particular, o de una clase de objetos.
Diagramas de Actividad
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito
que se usa para modelar el comportamiento del sistema. Los diagramas de
actividad se pueden usar para modelar un Caso de Uso, o una clase, o
un mtodo complicado.
3.6.1. Usando Diagramas de Actividad para modelar Casos de Uso

Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el
proceso de un Caso de Uso. Se pueden usar como un aadido a
una descripcin textual del caso de uso, o para listar los pasos del caso de uso.
Una descripcin textual, cdigo, u otros diagramas de actividad pueden detallar
ms la actividad.
3.6.2. Usando Diagramas de Actividad para modelar Clases

Cuando se modela el comportamiento de una clase, un diagrama de estado de
UML se suel usar normalmente para modelar situaciones donde ocurren
eventos asincrnicos. El diagrama de actividad se usa conado todos o la
mayora de los elementos representan el desarrollo de los pasos dados por las
acciones generadas internamente. Deberas asignar actividades a las clases
antes de terminar con el
19
diagrama de actividad.
Modelando Componentes de Software

El Diagrama de Componentes se usa para modelar la estructura del software,
incluyendo las dependencias entre los componentes de software, los
componentes de cdigo binario, y los componentes ejecutables. En el
Diagrama de Componentes modelas componentes del sistema, a veces
agrupados por paquetes, y las dependencias que existen entre componentes (y
paquetes de componentes).
20
Modelando la Distribucin y la Implementacin

Los Diagramas de Implementacin se usan para modelar la configuracin de
los elementos de procesado en tiempo de ejecucin (run-time processing
elements) y de los componentes, procesos y objetos de software que viven en
ellos. En el diagrama "deployment", empiezas modelando nodos fsicos y las
asociaciones de comunicacin que existen entre ellos.
Diseo de Bases de Datos Relacionales -- Una extensin informal

de UML
El Diagrama de Clase presenta un mecanismo de implementacin neutral para
modelar los aspectos de almacenado de datos del sistema. Las clases
persistentes, sus atributos, y sus relaciones pueden ser implementadas
directamente en una base de datos orientada a objetos. Aun as, en el entorno
de desarrollo actual, la base de datos relacional es el mtodo ms usado para
el almacenamiento de datos.
21
Ya en el Diagrama de Relacin de Entidad, el modelador puede empezar el

proceso de determinar cmo el modelo relacional encaja; y qu atributos son
claves primarias, claves secundarias, y claves externas basadas en relaciones
con otras entidades. La idea es constriur un modelo lgico que sea conforme a
las reglas de normalizacin de datos.
Uso de una herramienta de modelado
El intercambio de informacin de diseo e ideas usando la notacin UML sera

hecho en los medios que siempre han sido populares: pizarras, cuadernos y
trozos de papel por nombrar algunos. Pero UML se sirve mejor por una
herramienta de modelado, la cual puede ser usada para capturar, guardar,
rechazar, integrar automticamente informacin, y diseo de documentacin.
Proceso de desarrollo
Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga,

los mismos creadores de UML han propuesto su propia metodologa de
desarrollo, denominada el Proceso Unificado de Desarrollo.
22
XL (lenguaje de programacin)
XL significa lenguaje eXtensible. Es el primer y hasta ahora el nico lenguaje
de programacin diseado para apoyar la programacin de conceptos . [1]
XL cuenta con sintaxis y semntica reconfigurables por el programador. Los

complementos del compilador se pueden utilizar para agregar nuevas
funciones al idioma. Un conjunto bsico de complementos implementa
un lenguaje imperativo relativamente estndar. Los programadores pueden
escribir sus propios complementos para implementar anotaciones especficas
de la aplicacin, como la diferenciacin simblica , que luego se pueden utilizar
tan fcilmente como caractersticas de lenguaje incorporadas .
Idioma
XL se define en cuatro niveles diferentes:
XL0 define cmo un texto de entrada se transforma en un rbol de

anlisis .
XL1 define un lenguaje base con caractersticas comparables a C ++ .
XL2 define la biblioteca estndar, que incluye tipos de datos y

operadores comunes.
XLR define un tiempo de ejecucin dinmico para XL basado en XL0.
XL no tiene tipos primitivos ni palabras clave. Todos los operadores tiles y

tipos de datos, como enteros o adicin, se definen en la biblioteca estndar
(XL2). XL1 es porttil entre diferentes entornos de ejecucin. No existe tal
garanta para XL2: si una CPU particular no implementa la multiplicacin de
23
coma flotante, la definicin de operador correspondiente puede faltar en la

biblioteca estndar y si utiliza una multiplicacin de coma flotante puede
resultar en un error en tiempo de compilacin.
El programa Hello World en XL se parece a lo siguiente:
Utilizar XL.TEXT_IO
WriteLn "Hola Mundo"
Una forma alternativa en un estilo ms adecuado para programas a gran escala

sera:
Importar IO = XL.TEXT_IO
IO.WriteLn "Hola Mundo"
Una ejecucin recursiva de factorial en XLR se parece a lo siguiente:
0! -> 1
NORTE! -> N * (N - 1).
Sintaxis
La sintaxis se define en el nivel XL0. La fase XL0 del compilador se puede
configurar utilizando un archivo de descripcin de sintaxis, en el que se definen
propiedades como la representacin de texto y la precedencia de los
operadores. Un archivo de sintaxis bsico define anotaciones matemticas
comunes, como + para sumar, con el orden de operaciones
generalmente aceptado.
El rbol de anlisis se compone de 7 tipos de nodos, 4 tipos de nodos de

hoja (entero, real, texto y smbolo) y 3 tipos de nodos internos (infijo, prefijo y
bloque).
Los nodos enteros representan un literal entero, como 2 . El signo # se

puede utilizar para especificar una base distinta de 10, como en
24
( 2#1001 ). Un subrayado de separacin se puede utilizar para mejorar la

legibilidad, como en 1_000_000 .
Los nodos reales representan nmeros no integrales, como 2.5 . Las
notaciones basadas y los separadores se pueden utilizar, como para los
nodos enteros, por ejemplo 16#F.FFF#E-10 es un literal 16#F.FFF#E-
10 vlido.
Los nodos de texto representan contenidos textuales. Normalmente

estn rodeados de comillas simples o dobles, como "Hello" o 'a' , pero el
archivo de sintaxis se puede usar para agregar otros separadores,
incluyendo el contenido textual de varias lneas.
Con el archivo de sintaxis predeterminado, lo siguiente es vlido XL0,

independientemente de cualquier semntica.
A = B + "Hola"
Se analiza como:
Infijo ("=",
Smbolo ("A"),
Infijo ("+",
Smbolo ("B"), texto ("Hola")))
Semntica de XL
La fase XL se define como una secuencia de operaciones en el rbol de
anlisis de XL0. Estas operaciones son proporcionadas por varios plug-ins del
compilador, que se activan en funcin de la forma del rbol de anlisis.
Las construcciones especiales, translate y translation , son translation por un

plug-in diseado para facilitar la escritura de otros plug-ins. La construccin
de quote genera un rbol de anlisis. Aqu es cmo estas anotaciones se
pueden utilizar para implementar un plug-in llamado ZeroRemoval que elimina
las adiciones y multiplicaciones superfluas por cero.
25
Traduccin ZeroRemoval
cuando
'X' + 0
entonces
Devolver X
cuando
'X' * 0
entonces
Regresar parse_tree (0)
Un plug-in puede ser invocado en un archivo entero desde la lnea de

comandos, o ms localmente en el cdigo fuente usando la notacin pragma ,
de la siguiente manera:
X: = {Diferenciar} d (sin (omega * T) * exp (-T / T0)) / dT
La fase XL1 contiene un gran conjunto de plug-ins, XLSemantics , que

proporcionan abstracciones comunes como subrutina , tipo de
datos y declaracin y definicin de variables , as como sentencias de
programacin estructurada bsica, como condicionales o bucles.
Tipo de sistema
La comprobacin de tipo XL1 es esttica , con capacidades de

programacin genricas que estn ms all de las de idiomas como Ada o C +
+. Tipos como arrays o punteros, que son primitivos en lenguajes como C ++,
se declaran en la biblioteca en XL. Por ejemplo, un tipo de matriz
unidimensional podra definirse como sigue:
Genrico [Artculo: tipo; Tamao: entero] tipo array
Un tipo genrico validado es un tipo genrico donde una condicin indica cmo
se puede utilizar el tipo. Tales tipos no necesitan parmetros genricos. Por
26
ejemplo, se puede declarar que se ordered un tipo si tiene un operador menor

que el siguiente:
// Se ordena un tipo si tiene una relacin de menos que

Tipo genrico ordenado si
A, B: ordenado
Prueba: boolean: = A <B
Entonces es posible declarar una funcin que es implcitamente genrica

porque el tipo ordered es genrico.
// Funcin genrica para el mnimo de un elemento

Funcin Min (X: ordenada) retorno ordenado es
... calcula Y de tipo ordenado ...
Regresa
Esto tambin se aplica a tipos genricos que tienen parmetros,

como array . Una funcin que calcula la suma de los elementos de cualquier
matriz se puede escribir de la siguiente manera:
Funcin Sum (A: array) return array.Item es

Para I en 0..array.Size-1 loop
Resultado + = A [I]
Lista de argumentos de variables de tipo seguro
Las funciones pueden estar sobrecargadas . Se puede declarar una funcin

para usar un nmero variable de argumentos usando ... en la lista de
parmetros (histricamente, la palabra clave other fue usada para ese
propsito). En tal funcin, ... se puede utilizar para pasar el nmero variable de
argumentos a otra subrutina, una funcin ahora llamada plantillas Variadic :
// Funcin genrica para el mnimo de N elemento
27
Funcin Min (X: ordenada; ...) return ordenada es

Resultado: = Min (...)
Si X <resultado entonces
Resultado: = X
Cuando se llama una funcin de este tipo, el compilador instancia

recursivamente las funciones para que coincidan con la lista de parmetros:
// Ejemplos de uso del Min recin declarado

X: real: = Mn (1,3, 2,56, 7,21)
Y: entero: = Mn (1, 3, 6, 7, 1, 2)
Reduccin de la expresin: sobrecarga del operador
Los operadores pueden definirse utilizando la forma written de las

declaraciones de funciones. A continuacin se muestra el cdigo que declarara
la adicin de enteros:
Funcin Aadir (X, Y: entero) devolver el entero escrito X + Y
Tales formas escritas pueden tener ms de dos parmetros. Por ejemplo, una
transformacin lineal de la matriz se puede escribir como:
Funcin Matriz de retorno lineal (A, B, C: matriz) escrita A + B * C
Una forma escrita puede utilizar constantes, y tal forma es ms especializada

que una forma sin constantes. Por ejemplo:
Funcin Equal (A, B: matriz) retorno booleano escrito A = B

Funcin IsNull (A: matriz) retorno booleano escrito A = 0
Funcin IsUnity (A: matriz) retorno booleano escrito A = 1
El mecanismo se utiliza para implementar todos los operadores bsicos. Una

expresin se reduce progresivamente a llamadas de funcin usando formas
28
escritas. Por esta razn, el mecanismo se denomina reduccin de expresin en

lugar de sobrecarga del operador.
Iteradores [ editar ]
Los iteradores XL permiten a los programadores implementar tanto

los generadores como los iteradores .
Importar IO = XL.UI.CONSOLE
Iterador IntegerIterator ( var out Contador: integer , Low, High: integer )

escrito Contador en Low..High is
Contador: = Bajo
Mientras que Contador <= Bucle alto
rendimiento
Contador + = 1
// Tenga en cuenta que no es necesario declarar, porque declar 'var out' en el

iterador
// Por lo tanto, se hace aqu una declaracin implcita de I como un nmero
entero
Para I en 1..5 lazo
IO.WriteLn "I =", I
Estado e historia del desarrollo

XL es el resultado de un largo trabajo de diseo de lenguaje que
comenz alrededor de 1992. El lenguaje fue diseado e implementado
principalmente por Christophe de Dinechin .
Ancestry
XL1 se inspir en un gran nmero de otros idiomas. En orden alfabtico:
29
Ada inspir parte del apoyo a programas a gran escala, manejo de

excepciones , tareas y aspectos de apoyo.
BASIC las variantes ms modernas que dispensan nmeros de lnea y
apoyan la programacin estructurada, mostraron lo simple que podra ser la
sintaxis de un lenguaje de programacin.
C se utiliz como estndar para esperar en trminos de tiempo de

ejecucin y apoyo a nivel de mquina. XL no requerir que se ejecute una
mquina virtual.
C ++ y la biblioteca de plantillas estndar demostraron la necesidad de

un buen soporte de tipos genricos, incluyendo la instanciacin implcita de
genricos (que Ada carece).
El rendimiento continuo de Fortran sobre C y C ++ para aplicaciones de

uso intensivo numrico ayud a identificar qu construcciones de lenguaje
impediran optimizaciones tiles.
Java demostr la importancia de una gran biblioteca de soporte

porttil. Los contenedores Java tambin mostraron las limitaciones de un
enfoque no basado en la programacin genrica. Interfaz con cdigo Java
sigue siendo un desafo interesante para XL.
Semntica
XLR es un lenguaje dinmico, originalmente pensado como un back-end para
el compilador XL1, de ah el nombre, que significa tiempo de ejecucin
XL. Comparte la sintaxis bsica de XL0 con XL1, pero su comportamiento es
mucho ms cercano a un lenguaje funcional, mientras que XL1 est destinado
a buscar principalmente como un lenguaje imperativo. XLR tiene prcticamente
slo un operador incorporado, "->", que denota una reescritura. La notacin a la
izquierda de la reescritura se transforma en la notacin a la derecha de la
reescritura.
Este mecanismo se utiliza para implementar las notaciones estndar:
30
Si es cierto entonces TrueBody ms FalseBody -> TrueBody

Si es falso entonces TrueBody ms FalseBody -> FalseBody
Modelo RUP
Es un proceso de ingeniera de software, que hace una propuesta orientada por

disciplinas para lograr las tareas y responsabilidades de una organizacin que
desarrolla software.
Su meta principal es asegurar la produccin de software de alta calidad que
cumpla con las necesidades de los usuarios, con una planeacin y presupuesto
predecible.
Para quin es RUP?

Diseado para:
Profesionales en el desarrollo de software.
Interesados en productos de software.
Profesionales en la ingeniera y administracin de procesos de software.
Por qu usar RUP?

Provee un entorno de proceso de desarrollo configurable, basado en
estndares.
Permite tener claro y accesible el proceso de desarrollo que se sigue.
Permite ser configurado a las necesidades de la organizacin y del
proyecto.
Provee a cada participante con la parte del proceso que le compete
directamente, filtrando el resto.
31
Caractersticas
Dirigido por Casos de Uso: Los casos de uso son los artefactos
primarios para establecer el comportamiento deseado del sistema
Centrado en la Arquitectura: La arquitectura es utilizada para
conceptualizar, construir, administrar y evolucionar el sistema en desarrollo
Iterativo e Incremental:
Maneja una serie de entregas ejecutables
Integra continuamente la arquitectura para producir nuevas versiones
mejoradas
Conceptualmente amplio y diverso
Enfoque orientado a objetos
En evolucin continua
Adaptable
Repetible
Permite mediciones:
Estimacin de costos y tiempo, nivel de avance, etc.
Ciclo de Vida y sus Faces
En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES

secuenciales, cada cual concluye con un producto intermedio.
32
Al terminar cada fase se realiza una evaluacin para determinar si se ha

cumplido o no con los objetivos de la misma.
Las fases son:
Inicio (Inception)
Elaboracin
Construccin
Transicin.
Conclusiones
Es fcil predecir que UML ser el lenguaje de modelado de software de uso

universal. Las principales razones para ello son:
En el desarrollo han participado investigadores de reconocido prestigio.
Ha sido apoyado por prcticamente todas las empresas importantes
de informtica.
Se ha aceptado como un estndar por la OMG.
Prcticamente todas las herramientas CASE y de desarrollo la han adaptado
como lenguaje de modelado.
En resumen, UML resuelve de forma bastante satisfactoria un viejo problema
del desarrollo de software como es su modelado grfico. Adems, se ha llega-
do a una solucin unificada basada en lo mejor que haba hasta el momento, lo
cual lo hace todava ms excepcional.
33
Bibliografa
B. Vela, E. Marcos, Una extensin de UML para

representar XML Schemas
Entendiendo UML: La gua del desarrollador, con una aplicacin java
basada en web, por Paul
Harmon y Mark Watson; Morgan Kauffman Publishers, Inc., 1998
(www.mkp.com/books_catalog/1-55860-465-0.asp).
Qu le falta a UML? un artculo por Scott Ambler, "Objet Magacine",
Octubre de 1997, SIGS. Publications (www.sigs.com/omo/articles/ambler.html)
Especificacin UML 1.1 (Centro de Recursos de UML en
www.popkin.com)
Objetos, componentes y Estructuras con UML, The Catalysis Aproach,
por Desmond F. D"Souza y Alan C. Wills, Addison Wesley Longman, 1998
Enrique Hernndez Orallo, El Lenguaje, Unificado de Modelado (UML).
34

UML Monografia

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UML Monografia

Încărcat de

Drepturi de autor:

Formate disponibile

MODELOS DEL PROCESO DEL SOFTWARE

En el presente mdulo se permite entregar un material de apoyo que le permita

diagramas que componen UML y ofrece acercamientos a casos de uso guiados

Cualquier rama de ingeniera o arquitectura ha encontrado til desde hace

algn modelo grfico. La falta de estandarizacin en la manera de representar

UML es adems un mtodo formal de modelado. Esto aporta las siguientes

variedad de diagramas para visualizar el sistema desde varias perspectivas

Figura 3: Diagrama de casos de uso

Figura 4: Diagrama de clases

UML ofrece notacin y semntica estndar

XML Schemas en UML extendido

puede contener un documento y la forma en la que se pueden definir dentro de

Una perspectiva general de UML

Una vuelta por un caso de uso

Casos de Uso y Diagramas de Interaccin

Clases y Diagramas de Implementacin

Tarjetas CRC (CRC cards) - Una extensin informal de UML

Implementando el diseo de Bases de Datos

Probar teniendo en cuenta los requisitos

Un estudio a fondo de UML

Las siguientes secciones presentan una vista ms detallada al modelado con

Modelando componentes de software, distribucin e implementacin

Modelado de Casos de Uso

Estudiar y descubrir los requisitos

los requisitos que completa. Si los requisitos no existen, modelar el sistema a

Organizacin de Diagramas de Casos de Uso

Un Caso de Uso para cada escenario

Modelar secuencias alternas a travs de la relacin "Extiende"

Eliminar el modelado redundante a travs de la relacin "Incluir"

casos de uso mediante la relacin "Incluir" (Include). La relacin Incluir

Ayuda en casos de uso probando el sistema frente a los requisitos

como vectores horizontales. Los mensajes se dibujan cronolgicamente desde

Anlisis y Diseo con el Diagrama de Clase

3.4.1. Desarrollo de Diagramas de Clase durante el anlisis

3.4.1.2. Extensin guiada por la responsabilidad

3.4.2. Diseo del sistema con Diagramas de Clase

Durante el diseo, el Diagrama de Clase se elabora para tener en cuenta los

3.4.2.1. Arquitecturas Multicapas

3.4.2.2. Diseo de Componentes

componentes en la configuracin correcta para llevar acabo la funcionalidad

3.4.2.3. Anlisis y diseo "Iterative"

Modelando el comportamiento de las Clases con Diagramas de

Mientras los diagramas de interaccin y colaboracin modelan secuencias

3.6.1. Usando Diagramas de Actividad para modelar Casos de Uso

3.6.2. Usando Diagramas de Actividad para modelar Clases

Modelando Componentes de Software

Modelando la Distribucin y la Implementacin

Diseo de Bases de Datos Relacionales -- Una extensin informal

Ya en el Diagrama de Relacin de Entidad, el modelador puede empezar el

Uso de una herramienta de modelado

El intercambio de informacin de diseo e ideas usando la notacin UML sera

Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga,

XL cuenta con sintaxis y semntica reconfigurables por el programador. Los

XL0 define cmo un texto de entrada se transforma en un rbol de

XL2 define la biblioteca estndar, que incluye tipos de datos y

XLR define un tiempo de ejecucin dinmico para XL basado en XL0.

XL no tiene tipos primitivos ni palabras clave. Todos los operadores tiles y

coma flotante, la definicin de operador correspondiente puede faltar en la

El programa Hello World en XL se parece a lo siguiente:

Una forma alternativa en un estilo ms adecuado para programas a gran escala

Una ejecucin recursiva de factorial en XLR se parece a lo siguiente:

El rbol de anlisis se compone de 7 tipos de nodos, 4 tipos de nodos de

Los nodos enteros representan un literal entero, como 2 . El signo # se

( 2#1001 ). Un subrayado de separacin se puede utilizar para mejorar la