ENTERPRISE ARCHITECT

INTRODUCCION
Bienvenidos a la gua de usuario de Enterprise Architect de Sparx Systems. Esta gua lo
ayudar a usar Enterprise Architect, una herramienta CASE basada en UML, para
realizar modelado, construccin y administracin de software.
Desde que UML fue adoptado por el OMG como el lenguaje estndar para el
modelado, se ha definido un buen nmero de modelos de proceso para el desarrollo de
aplicaciones orientadas a objetos (OO), que utilizan este lenguaje como medio de
expresin de los diferentes modelos que se crean durante el desarrollo. Estas propuestas
suelen estar dirigidas por los casos de uso, de manera que stos se emplean para definir
los requisitos funcionales del sistema, y todas las etapas del proceso (planificacin de
las iteraciones, anlisis, diseo y pruebas) se articulan en torno a los casos de uso
identificados.
Actualmente, en muchas discusiones sobre casos de uso se coincide en sealar que con
frecuencia son mal interpretados, y que no hay guas precisas para resolver los aspectos
que tienen que ver con su organizacin. En este sentido, se han publicado diferentes
propuestas (por ejemplo [3, 7, 8]) en las que se discuten cuestiones tales como la
granularidad de los casos de uso, el nivel de detalle en que deben describirse, o la
conveniencia de crear una jerarqua de casos de uso.
Inspirados en la arquitectura de tres modelos de OOram y en el mtodo IDEA, estamos
definiendo un proceso basado en UML orientado a sistemas de informacin de gestin.
Este proceso incluye una fase de modelado del negocio, que describe los procesos del
negocio de la organizacin bajo estudio de manera que se puedan construir, de forma
sencilla y directa, versiones iniciales de los modelos conceptual y de casos de uso. Cada
proceso del negocio se describe haciendo uso de un diagrama de actividades UML con
calles (simIlanes). Posteriormente, se identifican los casos de uso del sistema a partir de
las actividades y los conceptos (clases del dominio) a partir de los datos (objetos de
informacin que fluyen entre las actividades).
En este trabajo describimos nuestra propuesta para realizar el modelado del negocio y
su conexin con el anlisis de requisitos (modelos conceptual y de casos de uso). Esta
propuesta ha sido experimentada en el marco de un proyecto cuyo objetivo ha sido
proporcionar un modelo de proceso, basado en requisitos, para el desarrollo de sistemas
de informacin de gestin con uso intensivo de datos [10]. El mbito de este trabajo ha
sido la DGSIC (Direccin General de Servicios de Informacin y de las
Comunicaciones) de la CARM (Comunidad Autnoma de la Regin de Murcia).
Este trabajo est estructurado de la siguiente manera: en el apartado 2 comentamos
someramente la problemtica asociada a la utilizacin del concepto de caso de uso, y
ofrecemos una visin general de nuestra propuesta; en el apartado 3 presentamos la

manera de abordar el modelado del negocio; en el apartado 4 mostramos cmo realizar

la transicin desde el modelo del negocio a los modelos de casos de uso y conceptual;
finalmente, en la seccin 5 exponemos nuestras conclusiones.
CONCEPTOS BSICOS
Enterprise Architect es una herramienta CASE para el diseo y construccin de sistemas
software. Desarrollada por Sparx Systems, la primera release (v1.1.3) data de Agosto
del 2000, mientras que la versin actualmente homologada (v6.5) vio la luz a finales del
2006.
Enterprise Architect soporta la especificacin UML 2.0, que describe un lenguaje visual
que permite la definicin de los modelos de un proyecto. Se trata de una herramienta
progresiva que cubre todos los aspectos del ciclo de un desarrollo, proporcionando una
completa trazabilidad desde la fase inicial de diseo hasta el desarrollo y posterior
mantenimiento. As mismo, tambin proporciona soporte para testing y control de
cambios.
Enterprise Architect, permite la realizacin de ingeniera directa e inversa, sincronizar
los elementos de los modelos con el cdigo fuente de las clases (ActionScript, C++, C#,
Delphi, Java, Python, PHP, VB.NET y Visual Basic), disear y generar elementos de
base de datos y generar documentacin de gran calidad fcilmente exportable a formato
RTF.
Enterprise Architect soporta todos los modelos/diagramas de UML 2.0. Permite disear
desde procesos de negocio, sitios web, interfaces de usuario, configuraciones hardware,
hasta estimar el esfuerzo del proyecto en horas. El repositorio est basado en DBMS
proporciona buenos tiempos de respuesta cuando se trabaja con varios usuarios debido a
su estructura interna. Adems, cualquier problema de conexin que se produzca, debera
ser cubierto por las habilidades del servidor DBMS, permitiendo deshacer cualquier
transaccin interrumpida por problemas externos. En nuestro caso se ha seleccionado
SQL Server 7.0 como repositorio de proyectos, y la licencia.
QUE ES ENTERPRISE ARCHITECT
Enterprise Architect de Sparx Systems es una herramienta CASE (Computer Aided
Software Engineering) para el diseo y construccin de sistemas de software, para el
modelado de procesos de negocios, y para objetivos de modelado ms generalizados.
EA est basada en la especificacin the UML 2.1, que define un lenguaje visual que usa
para modelar un dominio o sistema en particular (existente o propuesto).
Tenga en Cuenta: UML es un estndar de modelado abierto, definido y mantenido por el
Grupo de Administracin de Objeto. Para obtener ms detalles sobre UML, incluyendo
los documentos de especificacin de UML actual, visite http://www.omg.org y siga los
vnculos.

Consejo: Los usuarios que no estn familiarizados con UML, deben tomarse el tiempo
para explorar por completo esta gua de usuario de EA y proyecto de ejemplo
proporcionado con Enterprise Architect. El Tutorial UML (parte 1 y 2) en lnea y el
Tutorial UML 2.0 son tambin de mucha ayuda.
EA es una herramienta progresiva que soporta todos los aspectos del ciclo de desarrollo,
proporcionando una trazabilidad completa desde la fase inicial del diseo a travs del
despliegue y mantenimiento. Tambin provee soporte para pruebas, mantenimiento y
control de cambio.
Con ms de 100,000 licencias vendidas, Enterprise Architect ha probado ser muy
popular a travs de un rango amplio de industrias y es usado por miles de compaas en
todo el mundo. Desde organizaciones conocidas y multinacionales hasta compaas y
consultoras independientes y pequeas, Enterprise Architect se ha convertido en la
herramienta de modelado UML de eleccin para los desarrolladores, consultores y
analistas en ms de 60 pases.
El software de Sparx se usa en el desarrollo de muchos tipos de sistemas de software en
un amplio rango de industrias, incluyendo: el mbito aeroespacial, bancos, desarrollo
web, ingeniera, finanzas, medicina, ejrcito, investigacin, acadmico, transporte,
ventas al por menor, utilidades (como por ejemplo el gas y las electricidad) y la
ingeniera elctrica. Este tambin se usa efectivamente para la capacitacin de la
arquitectura de negocios y UML en muchos colegios prominentes, compaas de
capacitacin y universidades alrededor del mundo.
CARACTERISTICAS DEL ENTERPRISE ARCHITECT
Enterprise Architect est disponible en las tres ediciones: Corporativo, Profesional y
Escritorio, cada uno de los cuales ofrece un rango diferente de caractersticas. Para
obtener una comparacin de las ediciones de EA, vea el tema Diferencia entre las
ediciones Corporativa, Profesional, y Escritorio.
Las caractersticas claves de Enterprise Architect
UML 2.1 comprensivo -modelado basado
Administracin de requisitos incorporada
Depuracin y perfilacin integrada para las aplicaciones Java y .Net.
Soporte de administracin del proyecto extensivo, incluyendo los recursos,
mtricas y pruebas.
Soporte de pruebas: soporte para casos de prueba, JUnit y NUnit
Opciones de documentacin flexible: HTML estndar y reportes RTF.

 Soporte para muchos lenguajes de ingeniera de cdigo fuera de la caja

Entorno de modelado extensible con la capacidad de hospedar perfiles y
tecnologas definidas por el usuario.
Uso.
Velocidad: EA es un ejecutor espectacularmente rpido.
Precio: EA est evaluado para equipar el equipo completo, haciendo del
desarrollo de colaboracin y del equipo una posibilidad real.

QUE PUEDO HACER CON ENTERPRISE ARCHITECT

Enterprise Architect es un medio fuerte por el cual se puede especificar, documentar y
compilar sus proyectos de software. Usando las notaciones y semnticas del UML,
puede disear y modelar sistemas de software complejos desde su comienzo.
EA le permite:
Modelar sistemas de hardware y software complejos en notacin UML..
Generar y realizar ingeniera de cdigo inversa (Solo en Ediciones Profesional y
Corporativa) en:
Actionscript,
C
C++
C#
Delphi
Java
PHP
Python
Visual Basic
VB.NET.
Modelar base de datos y generar scripts DDL e invertir el esquema de base de datos
desde las conexiones ODBC.
Producir documentacin detallada y de calidad en formatos RTF y HTML.
Administrar cambio, mantenimiento y scripts de prueba.
Modelar dependencias entre los elementos.
Configurar clasificadores de objeto.
Modelar dinmicos del sistema y estados.
Modelar jerarquas de clase.
Modelar los detalles de despliegue, componentes e implementacin.
Recolectar incidencias del proyecto, tareas y el glosario del sistema.
Asignar recursos a los elementos del modelo y comparar el esfuerzo que llevo con el
esfuerzo requerido.
Modelos de produccin en formato compatible XMI 1.0, XMI 1.1, XMI 1.2 y XMI

2.1 para exportar a otras herramientas que soporten XMI.

Importar modelos en formato XMI 1.0, XMI 1.1, XMI 1.2 y XMI 2.1 desde otras
herramientas.
Administrar el control de versiones a travs de XMI usando MS TFS, CVS y
configuraciones de la subversin.
Usar Perfiles UML para crear extensiones de modelado personalizado.
Guardar y Descargar diagramas completos como patrones UML.
Analizar las relaciones entre los elementos en un formato tabular usando la Matriz de
Relacin.
Escribir y trabajar con elementos UML y automatizar tareas comunes usando una
interfaz de Automatizacin detallada.
Conectar a las bases de datos SQL Server, MySQL, Oracle9i, PostgreSQL, Adaptive
Server Anywhere, y Progress OpenEdge databases (Edicin Corporativa).
Migrar cambios a travs de un entorno distribuido con una Replicacin JET.
Usar paquetes controlados basados en importar y exportar XMI.
Realizar Transformaciones de Estilo MDA (ediciones profesional y corporativa).
CASO DE USO
El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un
caso de uso representa una unidad discreta de interaccin entre un usuario (humano o
mquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo significativo;
por ejemplo, "Validarse en el sistema", "Registrarse en el sistema" y "Crear un pedido"
son todos casos de uso.
Cada caso de uso tiene una descripcin que describe la funcionalidad que se construir
en el sistema propuesto. Un caso de uso puede "incluir" la funcionalidad de otro caso de
uso o "extender" a otro caso de uso con su propio comportamiento.

Una descripcin de caso de uso generalmente incluir:

Comentarios generales y notas describiendo el caso de uso

Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como
capacidad para actualizar pedido, capacidad para modificar pedido, etc.

Restricciones -reglas acerca de qu se puede y qu no se puede hacer-. Incluye:

o Pre-condiciones que deben ser verdaderas antes de que el caso de uso se
ejecute, por ejemplo crear pedido debe preceder a modificar pedido.
o Post-condiciones que deben ser verdaderas una vez que el caso de uso se
ejecut, por ejemplo el pedido est modificado y es consistente.
o invariantes: stas son siempre verdaderas -por ejemplo, un pedido debe
tener siempre un nmero de cliente.
Escenarios -descripciones secuenciales de los pasos que se toman para llevar a
cabo el caso de uso. Pueden incluir escenarios mltiples, para satisfacer
circunstancias excepcionales y caminos de proceso alternativos
Diagramas de escenarios -diagramas de secuencia para describir el flujo de
trabajo- similar al punto 4 pero descrito grficamente.
Atributos adicionales como fase de implementacin, nmero de versin, rango
de complejidad, estereotipo y estado.

Actores
Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas
computarizados. Un actor usa un caso de uso para desempear alguna porcin de trabajo
que es de valor para el negocio. El conjunto de casos de uso al que un actor tiene acceso
define su rol global en el sistema y el alcance de su accin.

Relaciones de Inclusin y Extensin entre Casos de Uso

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su

procesamiento normal. Generalmente se asume que los casos de uso incluidos se
llamarn cada vez que se ejecute el camino base. Un ejemplo puede ser listar un
conjunto de rdenes de clientes de las cules poder elegir antes de modificar una
orden seleccionada; en este caso, el Caso de Uso listar rdenes se puede incluir
en el Caso de Uso modificar orden cada vez que ste se ejecute.

Un Caso de Uso puede ser incluido por uno o ms casos de uso, ayudando as a
reducir la duplicacin de funcionalidad al factorizar el comportamiento comn
en los casos de uso que se reutilizan muchas veces.

Un Caso de Uso puede extender el comportamiento de otro Caso de Uso;

tpicamente cuando ocurren situaciones excepcionales. Por ejemplo, si antes de
modificar un tipo particular de orden de cliente, un usuario debe obtener la
aprobacin de alguna autoridad superior, entonces el Caso de Uso obtener
aprobacin puede extender opcionalmente el Caso de Uso normal modificar
orden.

Diagrama de Secuencia

El UML provee un medio grfico para representar la interaccin entre los

objetos a lo largo del tiempo en los diagramas de secuencia. stos muestran
tpicamente a un usuario o a un actor y los objetos y componentes con los que
interacten durante la ejecucin de un Caso de Uso. Un diagrama de secuencia
representa tpicamente un nico escenario de Caso de Uso o flujo de eventos.

Los diagramas son una va excelente para documentar los escenarios de uso,
para capturar los objetos necesarios de manera temprana en el anlisis y para
verificar el uso de los objetos ms tarde en el diseo. Los diagramas de
secuencia muestran el flujo de mensajes de un objeto a otro y, como tales,
representan los mtodos y los eventos soportados por un/a objeto/clase.

El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia,

con el usuario o actor a la izquierda iniciando un flujo de eventos y mensajes
que corresponden al escenario del caso de uso. Los mensajes que pasan entre
objetos se convertirn en operaciones de clases en el modelo final.

Diagrama de Implementacin

Un Caso de Uso es una descripcin formal de la funcionalidad que el sistema

tendr cuando se construya. Un diagrama de implementacin se asocia
tpicamente con un caso de uso para documentar qu elementos de diseo (por
ejemplo, componentes y clases) implementar la funcionalidad del Caso de Uso
en el nuevo sistema. Esto provee un alto grado de trazabilidad al diseador, al
cliente y al equipo que construir el sistema. La lista de casos de uso a los que se
asocia un componente o una clase documenta la funcionalidad mnima que debe
ser implementada por el componente.

E
l

ejemplo de arriba muestra que el caso de uso "Acceso" implementa el requisito

formal "1.01 Acceder al sitio web". Tambin establece que el componente de
lgica de negocios y el componente de pginas ASP implementan alguna parte o
toda la funcionalidad de "Acceso". Un refinamiento adicional es mostrar la
pantalla de "Acceso" (una pgina web) como una implementacin de su interfaz.
Estos enlaces de implementacin o realizacin definen la trazabilidad desde los
requisitos formales, a travs de casos de uso, a componentes y pantallas.
CASO DE USO DE NEGOCIO Y SISTEMA
Resumen
En este trabajo se presenta una estrategia para obtener de modo sistemtico el
modelo de casos de uso y el modelo conceptual, a partir del modelado del
negocio basado en diagramas de actividades UML. Despus de determinar los
procesos del negocio de la organizacin bajo estudio, y de describir sus flujos de
trabajo mediante diagramas de actividad, los casos de uso son identificados y
estructurados a partir de las actividades de cada proceso, mientras que los
conceptos que aparecen en el modelo conceptual se obtienen a partir de los datos
que fluyen entre las actividades. Adems, las reglas del negocio son
identificadas e incluidas en un glosario, como parte de la especificacin de datos
y actividades. Un aspecto destacable de nuestra propuesta es el hecho deque el
modelado conceptual y el de casos de uso se realiza en paralelo, haciendo ms
fcil la identificacin y especificacin de casos de uso adecuados. Tanto el
modelado de casos de uso como el modelado conceptual forman parte de la fase
de anlisis de requisitos de un modelo de proceso completo en cuya definicin
estamos trabajando. Este proceso est siendo experimentando en un organismo
de tamao medio de la Administracin

 Autonmica.
Introduccin
Motivacin
Problemas en la Utilizacin de los Casos de Uso
Actualmente, la mayor parte de los modelos de proceso propuestos para UML se
definen como dirigidos por los casos de uso. Un caso de uso puede ser definido como
una secuencia de acciones, incluyendo variaciones, que el sistema puede ejecutar y que
produce un resultado observable de valor para un actor que interacta con el sistema.
Aunque el xito de los casos de uso se suele justificar con el hecho de que constituyen
una tcnica simple e intuitiva, algunos autores sealan las dificultades que entraa la
obtencin y la especificacin de casos de uso verdaderamente tiles, y la falta de
consenso sobre cmo organizarlos y manejarlos. Estas son las razones que nos llevan a
pensar que es necesario establecer un conjunto de guas para la identificacin,
descripcin y organizacin de los casos de uso.
Algunas discusiones interesantes acerca del manejo de casos de uso son las
proporcionadas por T. Korson y A. Cockburn. Korson defiende que los requisitos (y por
tanto los casos de uso) han de ser organizados jerrquicamente, y establece que i) cada
nivel de casos de uso no debe aadir nuevos requisitos, sino refinar los del nivel
superior, y ii) la jerarqua de casos de uso no debe ser el resultado de una
descomposicin funcional, y ha de ser desarrollada de manera iterativa e incremental.
Por otro lado, Cockburn utiliza el concepto de objetivo (goal) para organizar
jerrquicamente los casos de uso. Distingue bsicamente entre objetivos estratgicos
(los procesos del negocio de la organizacin) y objetivos de usuario (las funciones del
sistema). Los objetivos estratgicos se corresponden con un conjunto de objetivos de
usuario y, de igual modo, un objetivo de usuario puede ser descompuesto, a su vez, en
un conjunto de objetivos de usuario. Aparece, por tanto, el concepto de objetivo
compuesto, que corresponde bien a un conjunto de objetivos de usuario, o bien a un
objetivo estratgico.
Otra cuestin importante es la ubicacin del modelado de casos de uso dentro del
modelo de proceso. Normalmente se concibe el modelado de casos de uso como un paso
previo al modelado conceptual. Sin embargo, Korson que no es posible crear casos de
uso adecuados y tiles (ni implementarlos correctamente) sin comprender el dominio, y
por tanto, el modelado de casos de uso y el modelado conceptual deben ser actividades
realizadas en paralelo.
Nuestra Propuesta
Normalmente, los casos de uso son elicitados de forma intuitiva a partir de la
especificacin del sistema y, posteriormente, las entidades del modelo conceptual se
extraen a partir de las especificaciones de los casos de uso. En las siguientes secciones
presentamos una propuesta para obtener de forma sistemtica tanto el modelo de casos

de uso como el modelo conceptual, a partir de un modelo del negocio, de acuerdo con el
esquema mostrado

Relaciones de trazabilidad entre los modelos de negocio y de requisitos

Inspirados en la Arquitectura de Tres Modelos de OO ram. el modelado del negocio se
realiza mediante diagramas de actividades UML. Una vez determinados los procesos de
negocio de la organizacin, y descritos sus flujos de trabajo mediante diagramas de
actividades, los casos de uso se elicitan y estructuran a partir de las actividades de cada
proceso, mientras que las entidades del modelo conceptual se obtienen de los datos que
fluyen entre tales actividades. Adems, se identifican las reglas del negocio y se
incluyen en un glosario como parte de la especificacin de los datos y las actividades.
Un aspecto notable de nuestra propuesta es que el modelado de casos de uso y el
modelado conceptual se realizan al mismo tiempo, haciendo ms fcil, por tanto, la
identificacin y especificacin de los casos de uso adecuados.

3 Modelado del Negocio

Para conseguir sus objetivos, una empresa organiza su actividad por medio de un
conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una coleccin de
datos que son producidos y manipulados mediante un conjunto de tareas, en las que
ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un
flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de
reglas de negocio, que determinan las polticas y la estructura de la informacin de la
empresa. Por tanto, la finalidad del modelado del negocio es describir cada proceso del

negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de

negocio.
El primer paso del modelado del negocio consiste en capturar los procesos de negocio
de la organizacin bajo estudio. La definicin del conjunto de procesos del negocio es
una tarea crucial, ya que define los lmites del proceso de modelado posterior. De
acuerdo con el concepto de objetivo estratgico de Cockburn, capturamos los procesos
del negocio a partir de los objetivos principales de la empresa. En primer lugar,
consideramos los objetivos estratgicos de la organizacin. Teniendo en cuenta que
estos objetivos van a ser muy complejos y de un nivel de abstraccin muy alto, sern
descompuestos en un conjunto de subobjetivos ms concretos, que debern cumplirse
para conseguir el objetivo estratgico. Estos subobjetivos pueden a su vez ser
descompuestos en otros, de manera que se defina una jerarqua de objetivos. En nuestro
estudio, hemos experimentado que dos o tres niveles de descomposicin son suficientes.
Para cada uno de estos subjetivos de segundo nivel definimos un proceso de negocio
que deber dar soporte a dicho subobjetivo. Representamos cada proceso del negocio
como un caso de uso del negocio, que inicialmente ser descrito de forma textual.
En el resto del trabajo, ilustramos el proceso mediante el ejemplo de una compaa que
fabrica productos bajo demanda (siguiendo un esquema just in time). Los objetivos
estratgicos de dicha compaa podran incluir Satisfacer un pedido de un cliente,
Incrementar en un 25% las ventas, o Disminuir el tiempo de fabricacin en un 15%.El
objetivo Satisfacer un pedido de un cliente puede ser dividido en subobjetivos tales
como: Registrar Pedido de Cliente, Fabricar Producto Pedido, Gestionar Almacn y
Realizar Pedidos a Proveedores. stos sern los objetivos que utilizaremos para definir
nuestros procesos del negocio.
Identificacin de Roles del Entorno del Negocio
Una vez se han identificado los procesos de negocio, es preciso encontrar los agentes
involucrados en su realizacin. Cada uno de estos agentes o actores del negocio
desempea cierto papel (juega un rol) cuando colabora con otros para llevar a cabo las
actividades que conforman dicho caso de uso del negocio. De hecho, identificaremos los
roles que son jugados por agentes de la propia empresa (que incluyen trabajadores,
departamentos y dispositivos fsicos) o agentes externos (como clientes u otros
sistemas). Por el momento nos centraremos en este ltimo tipo de roles, con los que la
organizacin interacta para llevar a cabo sus procesos de negocio. En nuestro ejemplo
tenemos los roles Cliente y Proveedor, claramente externos al sistema.
Para tener una visin general de los diferentes procesos de negocio de la organizacin,
puede construirse un diagrama de casos de uso del negocio, en el cual aparece cada
proceso del negocio como un caso de uso. Este diagrama permite mostrar los lmites y
el entorno de la organizacin bajo estudio. Slo se mostrarn en este diagrama los
actores del negocio correspondientes a los roles externos al sistema, deforma que los
procesos de negocio en los que slo tomen parte roles internos a la organizacin no
estarn conectados a ningn actor. En la Figurase muestra el diagrama de casos de uso

del negocio para nuestro ejemplo; es un diagrama de casos de uso UML formado por
casos de uso del negocio y actores. En el diagrama se muestra adems que el agente
Cliente arranca la realizacin del caso de uso relacionado, mientras que Proveedor
simplemente participa en el caso de uso asociado.

Diagrama de casos de uso del negocio para el sistema de produccin just in time
Descripcin de los Casos de Uso del Negocio
El siguiente paso dentro del modelado del negocio es introducirse en cada uno de los
casos de uso del negocio identificados, para describirlo en detalle. Nos centraremos en
uno de los casos de uso del negocio de nuestro ejemplo, Registrar Pedido, cuya
descripcin se muestra en la figura. Esta descripcin puede ser validada fcilmente por
los usuarios.
A continuacin, hemos de determinar los agentes internos que juegan un rol en cada
caso de uso del negocio. Hasta el momento hemos identificado los roles que pertenecen
al entorno de la organizacin. Ahora es necesario estudiar la descripcin de cada caso de
uso del negocio, y observar el conjunto completo de roles involucrados, tanto externos
como internos a la organizacin. Los roles del caso del uso del negocio Registrar pedido
son Cliente, Comercial, Jefe_Tcnico, y Jefe_Produccin (siendo los tres ltimos
internos al sistema).

Fig. 3. Descripcin del caso de uso del negocio Registrar pedido

El aspecto estructural de la colaboracin entre los roles para llevar a cabo un caso de
uso del negocio, puede ser representado en un diagrama de roles, en el que cada rol (una
clase UML estereotipada) aparece asociado con los roles con los que puede colaborar
(ver Fig. 4). Por tanto, este diagrama permite expresar el conocimiento que unos roles
tienen de otros, as como las caractersticas (como la multiplicidad) de cada relacin
entre roles. Adems, este diagrama permite tambin mostrar las caractersticas de los
roles identificados, tales como sus atributos y responsabilidades. Ortn y Garca Molina
[11] discuten con ms detalle el modelado de roles con UML.

Fig. 4. Diagrama de roles para el caso de uso del negocio Registrar Pedido

Despus crearemos escenarios para mostrar el aspecto de comportamiento de la

colaboracin. Para ello utilizaremos diagramas de secuencia UML (ver Fig. 5), en los
que los objetos denotan las instancias de los roles que intervienen en la interaccin.

Fig. 5. Diagrama de secuencia para el caso de uso del negocio Registrar Pedido

En cada proceso podemos distinguir entre el flujo bsico o normal de la interaccin

(en nuestro ejemplo, solicitud de un pedido que es aceptado) y los posibles flujos
alternativos (por ejemplo, rechazo o cancelacin de un pedido). Para mejorar la
legibilidad, es conveniente asociar varios escenarios a un mismo caso de uso del
negocio, en lugar de mostrar en una nica secuencia todas las posibilidades.

En la arquitectura de tres modelos de OOram se incluye un modelo del negocio

representado mediante una vista proceso basada en el estndar IDEF0, en la cual se
muestra el flujo de trabajo a realizar para conseguir cierto objetivo de la organizacin,
indicando qu roles realizan cada actividad y cules son los datos requeridos y
producidos por cada actividad. Creemos que estos diagramas son muy tiles para
modelar casos de uso del negocio, dado que son muy sencillos y expresivos, facilitando
as la comunicacin con los usuarios. Estos diagramas pueden adaptarse a UML
utilizando diagramas de actividades con calles (swimlanes). De esta manera, para
mostrar de forma ms detallada el flujo de trabajo que realiza cada proceso de negocio
crearemos diagramas de este tipo, que llamaremos diagramas de proceso.
La Fig. Nuestra el diagrama de proceso que incluye el escenario de la figura. Existe una
calle por cada rol participante en el escenario, que incluye las actividades que realiza
dicho rol. El diagrama tambin muestra la informacin que necesita y produce cada
actividad, y la sincronizacin requerida entre las diferentes actividades. Los datos
aparecen como objetos que fluyen entre las actividades y pueden tener un estado. Por
ejemplo, la actividad Cursar pedido recibe un pedido propuesto e inicia su revisin (ver
Figura Nos referimos a estos objetos como objetos de informacin.

Diagrama de proceso para el caso de uso del negocio Registrar Pedido

Durante la descripcin de un proceso de negocio mediante un diagrama de proceso, es

posible encontrar una actividad cuya complejidad sea tal que sea necesario describirla
mediante otro diagrama de proceso adicional, por no complicar en exceso el diagrama
en cuestin. Por tanto, este nuevo diagrama de proceso describir un subobjetivo en
relacin al objetivo ligado al proceso de negocio original. De este modo los procesos de
negocio se organizan jerrquicamente. Tambin es posible mostrar en diferentes
diagramas de proceso el flujo normal y los flujos alternativos.
Especificacin de Reglas del Negocio
En una organizacin, tanto los procesos como los datos que estos manejan, estn
restringidos por las reglas del negocio. Con el fin de tener en cuenta todos los tipos de
reglas que aparecen en la especificacin de requisitos, hemos utilizado la clasificacin
descrita por James Odell [9], que distingue entre reglas de restriccin (reglas de
estmulo-respuesta, reglas de restriccin de operacin y reglas estructurales) y reglas de
derivacin. De acuerdo con esta clasificacin, recogemos de manera explcita cada tipo
de regla en el modelo del negocio mediante la especificacin de las actividades y
objetos de informacin que aparecen en los diagramas de proceso. Estas
especificaciones se renen en un glosario. La Fig. 7 muestra la especificacin del objeto
de informacin Pedido y de las actividades Ordenar fabricacin y Notificar aceptacin
de pedido.

...

...

Objeto de Informacin: Pedido Actividad: Ordenar fabricacin

Origen: Analizar viabilidad
Atributos

Agente: Jefe Tcnico

Cdigo de pedido

Precondiciones:

Fecha de solicitud

La fabricacin de todo
producto en el pedido es
viable

Existe una plantilla de

fabricacin para cada uno
de dichos productos.

Fecha de creacin
Fecha mxima de entrega
Conjunto de {Producto}Cliente
Importe total
Estado actual

Postcondiciones:

Ha sido creada una orden

de trabajo para
producto solicitado;

cada

Restricciones

El cdigo de pedido
identificar unvocamente
el pedido, y ser asignado
automticamente por el
sistema.

El estado de cada orden de

trabajo es pendiente.

Cada orden de trabajo ha

sido enviada al jefe de
produccin
para
su
planificacin.

Las fechas de solicitud y

de creacin sern previas a Caso de Uso del sistema:
la fecha mxima de
- pendiente de especificarentrega.

Un pedido contendr al Actividad: Notificar aceptacin de

menos un producto; no pedido
existe lmite mximo de
Origen: Analizar viabilidad
productos.

Agente: Comercial
Un pedido siempre ser
solicitado por un y
Precondiciones:
solamente un cliente

La fabricacin de todos sus

El importe total del pedido
productos es viable.
ser calculado a partir del
precio y unidades pedidas Postcondiciones:
de cada producto incluido.

...

Clase del Dominio:

-pendiente de especificar...

Se ha comunicado al
cliente la aceptacin de su
pedido.

El estado del pedido es

aceptado.

Caso de Uso del Sistema:

-pendiente. de especificar...

Cada objeto de informacin se describir mediante un conjunto de atributos y sus

restricciones de integridad (si las tuviera); por tanto, establecemos explcitamente las
reglas estructurales y de derivacin. Por otro lado, la especificacin de la semntica de
cada actividad contendr: origen (actividades que la preceden), agente (responsable de
llevar a cabo la actividad), y pre y postcondiciones (que establecen qu tiene que
cumplirse antes y despus de la actividad). Esta ltima parte se corresponde con las
reglas de operacin, mientras que las reglas de estmulo-respuesta quedan reflejadas
mediante el origen, donde se expresa el orden entre las actividades. El glosario tendr
una estructura de hipertexto (referencias-cruzadas) con el objeto de mantenerlas
relaciones de trazabilidad entre los procesos del negocio y las clases y los casos de uso
que especifican la funcionalidad del sistema.
Anlisis de Requisitos: Modelos Conceptual y de Casos de Uso Iniciales
Apartir del modelo del negocio descrito en la seccin anterior, es posible obtener de
manera sistemtica y directa, tanto la coleccin inicial de casos de uso del sistema como
el modelo conceptual preliminar. A continuacin vamos a describir de manera separada
cmo obtener cada modelo.
Los requisitos elicitados y especificados en esta fase sern incluidos en un documento
de especificacin de requisitos del software (ERS). Recomendamos el uso de una
plantilla de ERS estndar, como la IEEE 830-1998.
Transicin al Modelo Inicial de Casos de Uso del Sistema
Segn nuestra experiencia, las actividades del diagrama de proceso tienen el nivel de
granularidad adecuado para ser asociadas a un caso de uso del sistema. De esta manera,
crearemos un caso de uso del sistema por cada actividad del diagrama de proceso que
deba ser soportada por el sistema software. Por tanto, el rol que lleva a cabo la actividad
ser el actor principal del caso de uso. Ntese que, de acuerdo con la definicin de caso
de uso, no todas las actividades del diagrama de proceso sern consideradas como casos
de uso, sino solamente aquellas que sean de valor para algn actor.

Diagrama inicial de casos de uso del sistema

Los casos de uso se pueden organizar en varios niveles (recomendamos dos o tres como
mximo) de acuerdo con la descomposicin jerrquica propuesta en el modelado del
negocio.
Cada caso de uso se describir mediante una plantilla que puede rellenarse a partir de la
especificacin de la actividad asociada, que se encuentra recogida en el glosario como
ya hemos visto. Hemos elegido la plantilla propuesta por Coleman [4] porque combina
simplicidad y completitud, como se muestra en la Fig..Una vez descrito el caso de uso,
se conectar a la especificacin de la actividad asociada en el glosario, con el objeto de
mantener la trazabilidad entre los casos de uso del negocio y del sistema.

Caso de Uso
Descripcin

Actores
Asunciones

Ordenar Fabricacin
Se crearn rdenes de trabajo para cada producto
solicitado en el pedido, y sern enviadas al jefe de
produccin para su planificacin.
Jefe tcnico
- Es viable la fabricacin de cada producto solicitado
en el pedido.
- Existe una plantilla de fabricacin para cada producto
solicitado.

Pasos
1 REPETIR
1.1 Obtener un producto del pedido.
1.2 Buscar la plantilla de fabricacin asociada al
producto.
1.3 Crear la orden de trabajo.

Variaciones
Req.
Funcionales
Cuestiones

1.4 Almacenar la orden de trabajo con el estado

pendiente.
No -

Tambin podran encontrarse relaciones entre los casos de uso, tales como include, si se
detectan aspectos comunes entre varios casos de uso, y extend, para expresar caminos
opcionales o alternativos en un caso de uso. No obstante, estamos de acuerdo con las
recomendaciones ampliamente extendidas de no abusar de estas relaciones y no
mostrarlas en los diagramas de casos de uso.

Para completar esta fase debemos establecer los requisitos no funcionales. Cuando estn
asociados a un caso de uso, podrn especificarse en la plantilla de caso de uso
propuesta. Los requisitos no funcionales globales se recogern en el apartado
correspondiente de la plantilla de ERS elegida.
4.2 Obtencin del Modelo Conceptual Inicial
Los objetos de informacin que fluyen entre las actividades de un caso de uso del
negocio representan datos del dominio, por lo que suponen una buena base para crear el
modelo conceptual inicial. Este modelo incluir los conceptos y sus relaciones y se
describir mediante un diagrama de clases UML, en el que los conceptos se representan
mediante clases (del dominio).
As, cada objeto de informacin del diagrama de proceso se convertir ahora en un
concepto (y en la etapa de diseo dar lugar a una clase si el sistema software debe dar
soporte a dicho concepto). A partir de la especificacin de un objeto de informacin
obtendremos la definicin del concepto asociado, es decir, sus atributos, relaciones con
otras clases y restricciones. Por ejemplo, a partir de la especificacin de Pedido
mostrada en la Fig, podramos obtener: i) los atributos cdigo, fecha, Solicitud, fecha,
Creacin, fecha Max, Entrega, importe Total, estado Actual; ii) las asociaciones Cliente
Pedido y Pedido, Producto, y iii) restricciones que podran ser expresadas textualmente
o bien mediante OCL (Object Constraint Language), como {fecha Max-Entrega fecha,
Creacin}. Ntese adems que cuando un modelo conceptual evoluciona hacia un
diagrama de clases, las responsabilidades se pueden obtener a partir de ciertas
restricciones ya especificadas en el glosario. Por ejemplo, la clase Pedido podra tener
responsabilidades como obtener Productos, calcular Fecha Max Entrega, calcular
Importe Total o cambiar Estado.
De igual forma que conectbamos en el glosario las actividades con los casos de uso del
sistema, vincularemos cada objeto de informacin con la clase del dominio que lo
representa en el sistema. La Figura muestra el diagrama de clases que describe el primer
modelo conceptual de nuestro ejemplo.

Modelo conceptual inicial para el caso de uso del negocio Registrar Pedido
En esta etapa del desarrollo, merece la pena detenerse en la identificacin de los
conceptos y no tanto en las relaciones entre ellos. Deberamos concentrarnos en las
asociaciones del tipo debe conocer. Por ejemplo, a partir del glosario podemos
establecer que un pedido debe conocer al cliente que lo realiza y los productos que lo
componen (ver Fig. 7). De esta forma, alguno de los roles identificados en el modelo del
negocio, y por tanto especificado en el modelo de roles, podra ser incluido como una
clase en el modelo conceptual. Es el caso de la clase Cliente en nuestro ejemplo.
A partir del modelo del negocio, es posible identificar tambin qu clases tienen un
comportamiento que depende de un conjunto no trivial de estados alcanzables. En estos
casos, sera interesante definir una mquina de estados mediante un diagramas tatechart
UML. Estas clases se detectan con facilidad en los diagramas de proceso, puesto que se
corresponden con objetos de informacin etiquetados con varios estados diferentes. En
nuestro ejemplo, Pedido sera candidato para construir una mquina de estados que
mostrase los estados de un pedido (propuesto, en_evaluacin, evaluado, aceptado y
rechazado) y los eventos que producen los cambios entre estados.
Conclusiones
Este trabajo presenta una estrategia para abordar el modelado del negocio y el anlisis
de requisitos, en la que los casos de uso y el modelo conceptual se obtienen de forma
sencilla, a partir del modelo del negocio basado en el uso de diagramas de actividades
UML.
Con las guas proporcionadas, el modelador dispone de un modo sistemtico de
identificar y organizar casos de uso, y de identificar y definir las clases del modelo
conceptual. Los procesos de negocio de la organizacin se identifican partiendo de los
objetivos propuestos por Cockburn, y se describen mediante flujos de actividades que se
representan mediante diagramas de actividades UML. De este modo, los casos de uso
del sistema se obtienen a partir de las actividades de los procesos del negocio y se
organizan jerrquicamente, de acuerdo con lo indicado por Korson.
Las clases del modelo conceptual se obtienen a partir de los objetos de informacin que
fluyen entre las actividades. Nos gustara subrayar, como una caracterstica importante
de nuestro enfoque, que el modelado de los casos de uso del sistema y el modelado
conceptual se realizan en paralelo, de acuerdo con Korson, quien establece que esto es
crucial para obtener casos de uso correctos, puesto que es necesario entender bien el
dominio para poder escribir casos de uso que sean realmente tiles.
A la vez que se realiza el modelado del negocio y de los requisitos, la especificacin de
las actividades y de los casos de uso asociados, as como de los objetos de informacin
y de las clases que los implementan, se van recogiendo en un glosario, que permitir
mantener las correspondientes relaciones de trazabilidad entre los diferentes artefactos
del modelado.

El Proceso Unificado de desarrollo de software (UP) definido por Rational para UML,
incluye tambin el modelado del negocio como un paso ms dentro de las iteraciones
necesarias que conforman el modelo del proceso. Jacobson et al. Presentan algunos
pasos que son similares a los nuestros, pero no se considera la descomposicin
jerrquica de los casos de uso de nivel superior, ni tampoco se proporciona una gua
clara para detectar los casos de uso del sistema. Nuestro enfoque para el modelado del
negocio constituye una gua completa y detallada, a diferencia de las indicaciones
generales presentadas en el UP.

Consejo: La gua del usuario de EA se aprecia mejor con Internet Explorer versin
4.0 o superior.
Uso recomendado de esta gua
Primero, vea Que es Enterprise Architect (EA)? Para entender que puede hacer EA y
para que puede usarla. Si es nuevo en el modelado y UML as como tambin para EA, o
slo quiere obtener una vista rpida del proceso de modelado con EA, ir a Comenzando.
Esto no es slo una descripcin terica - lo primero que hace es comenzar EA e
inmediatamente crear un proyecto! Los modeladores con experiencia tambin pueden
usar CD de Enterprise Architect para usuarios experimentados.
EA es muy flexible y tiene muchas caractersticas. Cuando trabajamos en Comenzando,
ver muchos vnculos a descripciones ms extensas de caractersticas, funciones, tareas
y procedimientos, en la seccin Usando Enterprise Architect. Si desea ms informacin
puede seguir cualquiera de estos inmediatamente. La seccin Usando Enterprise
Architect es el primer de las principales referencias para trabajar con EA. Otras
secciones incluyen:

Administracin del modelo

Administracin del proyecto

Ingeniera de cdigo

Depurar y perfilar

Modelado de datos

Transformaciones MDA

Tecnologas XML

Extendiendo EA

EA hace un uso extensivo de UML, por esto proveemos un diccionario de Definiciones

de UML para los diagramas, elementos y conectores. Tambin puede verificar el
Glosario para la definicin de varios trminos y conceptos usados en la gua del usuario
de EA.
Debera leer los Procedimientos formales de Sparx Systems, incluyendo los Derechos
de autor y nuestro Acuerdo de Licencia del usuario final.
Sus comentarios
Sparx Systems desea permanecer en contacto con las necesidades de los usuarios de
Enterprise Architect para que ejecuten sus tareas eficientemente. Nosotros evaluamos
cualquier sugerencia, comentarios que pueda tener respecto a este producto, la
documentacin o el proceso de instalacin. Puede acceder nuestras pginas de
comentarios en lnea en:

www.sparxsystems.com.au/bug_report.htm y

www.sparxsystems.com.au/feature_request.htm.

Alternativamente, puede contactar a Sparx Systems en espaol por mail a:

suporte@sparxsystems.com.ar.
Diferencias entre las ediciones de Escritorio, Profesional y Corporativa

Enterprise Architect est disponible en tres ediciones, edicin de Escritorio,

Profesional y Corporativa. La funcionalidad de cada edicin se describe a
continuacin:

Funcionalidad

Edicin
Corporativa

Edicin

Edicin
de Escritorio

Profesional

Archivos EAP
S

No

No

No

No

No

No

No

No

No

No

No

No

Modelos compartidos
Ingeniera de cdigo fuente
Ingeniera de base de datos
Acceso al repositorio de Microsoft
Repositorio de base de datos SQL Server,
MySQL, Oracle9i y 10g, PostgreSQL, MSDE,
Adaptive Server Anywhere
Control de versiones
Replicacin
Tecnologas MDG
Vnculo MDG para Eclipse y Vnculo MDG para
Visual Studio.NET

Seguridad
Auditoria

Edicin Corporativa de EA
La edicin Corporativa, que apunta a equipos de desarrollo grandes, soporta todo lo que
soportan las versiones de Escritorio y Profesional, ms la capacidad de conectarse a los
DBMS de MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere y
Oracle 9i y 10g como repositorios compartidos. Esto provee escalabilidad adicional y
concurrencia mejorada sobre el enfoque de archivos .EAP compartidos para el uso
compartido del modelo. El soporte para Tecnologas MDG y Vnculo MDG (vendidos
por separado) est incluido con la versin Corporativa de EA. Esta edicin tambin
soporta seguridad de usuario, acceso de usuario, grupos de usuario y bloqueo de
elemento a nivel de usuario. El soporte de la edicin Corporativa para la seguridad
basada en el usuario/grupo comprende bloqueos en el diagrama y niveles de elementos.
La seguridad se provee de dos modos: en el primer modo, todos los elementos se
consideran "editables" hasta que sean explcitamente bloqueados por el usuario o grupo;
en el segundo modo, todos los elementos se consideran bloqueados hasta que sean
verificados con un bloqueo de usuario.
La edicin Corporativa est disponible en la forma independiente (licencia fija) o
licencia Flotante. El orden de la licencia Corporativa Flotante es particularmente til
para las compaas que administran un almacn central de las claves de las licencias.
Las claves de las licencias Flotantes se pueden usar por diferentes empleados en el
tiempo, temporalmente o permanentemente.
Edicin Profesional de EA
La edicin Profesional, que apunta a grupos de trabajo y a desarrolladores, soporta
proyectos compartidos a travs de replicacin y archivos de red compartidos. Esta
edicin tiene una interfaz ActiveX para revisar proyectos de EA y extraer informacin
en formato XMI. La edicin Profesional tambin soporta la importacin/exportacin
completa de cdigo y sincronizacin de elementos de modelado con el cdigo fuente e
ingeniera inversa de bases de datos Oracle 9i y 10g, SQL Server y MS Access. El
soporte para Tecnologas MDG y Vnculo MDG (vendidos por separado) est incluido
con la versin Profesional de EA. El repositorio compartido disponible en la Edicin
Profesional esta restringido al formato de archivo EAP ( base de datos JET).
Edicin de Escritorio de EA
La edicin de Escritorio apunta a desarrolladores individuales que producen modelos
UML de anlisis y diseo.
Consejo: Con el fin de ayudar a comprender las diferencias entre estas ediciones y las
ventajas y restricciones de cada una, la versin de evaluacin de Enterprise Architect
se puede abrir en cualquiera de las configuraciones que se desee. Cuando se inicie
Enterprise Architect, seleccione el modo que desea probar; puede reiniciar en otro
modo la prxima vez si lo desea.

COMENZAR ENTERPRISE ARCHITECT

Cuando instale Enterprise Architect en su computadora, se crear una nueva carpeta de
programa en el men Inicio que se llama Enterprise Architect (a menos que haya
cambiado el nombre predeterminado durante la instalacin).
Iniciando Enterprise Architect
Puede iniciar Enterprise Architect desde el cono que se cre en su escritorio de
Windows durante la instalacin, o alternativamente:
1. Abrir el men de Inicio de Windows.
2. Ubicar la carpeta de programa de Enterprise Architect.
3. Seleccionar Enterprise Architect.
Tenga en Cuenta: Cuando instale Enterprise Architect, se instala por defecto un
proyecto 'inicial' llamado 'EABase.EAP', as como un proyecto de ejemplo que se llama
'EAEjemplo.EAP'. Recomendamos que los usuarios nuevos seleccionen el archivo
'EAExample' y lo exploren en detalle mientras se familiarizan con el UML y la
ingeniera de software usando Enterprise Architect.

ABRIR UN PROYECTO
Enterprise Architect soporta muchos mtodos diferentes para abrir un archivo del
proyecto de EA.
Desde el men principal
Seleccionar la copin de men Archivo | Abrir proyecto. Desde la ventana Abrir
proyecto, seleccionar la ruta para el archivo para abrir luego hacer clic en Abrir.

Desde la pgina de inicio ( ver Pgina de inicio)

Hacer clic en Abrir un archivo de proyecto.
Aparecer la ventana Abrir proyecto.
Usar el explorador de archivo ([ ... ]) para navegar al proyecto que desea abrir, el
cual tiene una extensin .EAP (*.EAP) . Seleccionar el proyecto y hacer clic en
Abrir.
Proyectos abiertos recientemente
Enterprise Architect mantiene una lista de proyectos abiertos recientemente y los
muestra en la Pgina de inicio para lograr una fcil seleccin. Si el proyecto que
desea est en la lista de Recientes, simplemente hacer clic una vez en el nombre del
proyecto para abrirlo.
Tenga en Cuenta: Si ya tiene un proyecto abierto, se le sugerir guardar los
cambios antes de cargar.
Archivo del proyecto ejemplo de EA
Los usuarios nuevos de Enterprise Architect en particular deberan comenzar
explorando el archivo de ejemplo de EA provisto por Enterprise Architect. El
archivo modelo de ejemplo se guarda en su directorio de instalacin. Los directorios
de instalacin predeterminados, dependiendo de la versin que instal, son:
Versin Registrada: C:\Archivos de Programa\Sparx Systems\EA
Versin de Prueba: C:\Archivos de Programa\Sparx Systems\EA Trial
Versin Lite: C:\Archivos de Programa\Sparx Systems\EA Lite
CREAR NUEVO PROYECTO

Bienvenido a Enterprise Architect! Esta gua de

comienzo rpido le ayuda a comenzar a modelar
con Enterprise Architect.
La primer tarea que puede realizar es crear un
nuevo proyecto y agregar un paquete, diagrama,
elementos y conectores.
Cuando inicia Enterprise Architect este se abre en
la Pgina de inicio. Para crear su proyecto:
1. Haga clic en la opcin Crear un nuevo
proyecto.... Se abre la ventana Nuevo proyecto.
2. En el campo Nombre de archivo, ingrese un
nombre significativo para el proyecto y haga clic
en el botn Guardar para crear el archivo del
proyecto. Se abre el Asistente del modelo.
3. Ahora seleccione uno o ms platillas del
modelo (estas le proveen con las estructuras
bsicas para su proyecto, as como tambin las
referencias a los archivos de ayuda tiles para que comience). Seleccione la casilla de
cada modelo que sea de inters.
4. Haga clic en el botn Aceptar. Enterprise Architect crea su proyecto y lo abre en la
ventana del Explorador del proyecto, que est en el lado derecho de la pantalla.
Tambin puede crear rpidamente un proyecto copiando un proyecto base existente
provisto con Enterprise Architect; vea el tema Copiar un proyecto base.
Para ver su proyecto, haga clic en el icono 'ms' para expandir una carpeta o paquete, y
haga doble clic en el icono del diagrama que se muestra debajo del nombre del paquete.
Enterprise Architect abre el diagrama de ejemplo para su modelo en la Vista del
diagrama, la cual est en el medio de la pantalla. Ahora que ya tiene un proyecto, puede
agregar otro paquete y diagrama, y luego agregue elementos y conectores (o relaciones).
Una vez que cree estos componentes de un proyecto, debera tambin saber cmo mover
y eliminar los mismos, y como guardar su trabajo.

AGREGAR UN PAQUETE A UN MODELO

Un Paquete es un contenedor de los elementos del modelo, y este se muestra en la
ventana del Explorador del proyecto como el icono de la carpeta familiar a los usuarios
de Windows. Los contenidos del paquete estn ordenados alfabticamente.
En la ventana del Explorador del proyecto haga clic en un paquete y, en la barra de
herramientas de la ventana del Explorador del proyecto, haga clic en icono Nuevo
paquete .
Enterprise Architect muestra un aviso para el nombre del paquete.

Ingrese un nombre y haga clic en el botn Aceptar. Enterprise Architect agrega el

nuevo paquete subordinado al paquete que seleccion.

AGREGAR UN DIAGRAMA A UN PAQUETE

Un diagrama es una representacin de los componentes o elementos de su modelo y,

dependiendo del tipo de diagrama, como esos elementos se vinculan o cmo
interactan.
Cuando crea por primera vez un proyecto, EA provee ejemplos simples de diagramas
apropiados a sus patrones del modelo seleccionados, con anotaciones. Puede editar estos
diagramas, y crear adicionales.
Haga clic en su nuevo paquete y, en la barra de herramientas del Explorador del
proyecto, haga clic en el icono Nuevo diagrama.
Se muestra la ventana Nuevo diagrama.
Haga clic en una categora del diagrama en el panel Seleccionar desde, y un tipo de
diagrama en el panel Tipos de diagramas, luego haga clic en el botn Aceptar.
Enterprise Architect agrega un objeto del diagrama al paquete, con el mismo nombre del
paquete. Este tambin abre la Vista del diagrama para su diagrama, en el centro de la
pantalla.

Ha creado un proyecto que contiene paquetes, diagramas y elementos, y ja conectado los elementos. Puede que
haya ordenado sus componentes en la estructura incorrecta. Como cambia donde estn las cosas?
Tener en cuenta: Discutiremos el cambio de nombres y propiedades posteriormente.
En este tema, las explicaciones se refieren al siguiente ejemplo:

Tener en cuenta:
Muestra y trabaja en en su modelo en la ventana Explorador del proyecto, y mostrar y trabajar en un diagrama
en la Vista del diagrama.

En el Explorador del proyecto, los contenidos de un paquete se listan en el orden diagramas | paquetes hijos |
elementos. Los elementos se arreglan an ms en el orden tipo. Dentro de sus tipos, los componentes se listan
inicialmente en orden alfabtico o numrico.

Mueva los componentes dentro de un paquete

Para mover un diagrama, el paquete hijo o el elemento dentro su paquete hijo, haga clic en la ventana
Explorador del proyecto y haga clic en

en la parte superior de la ventana.

Puede mover la Clase3 en el Explorador del proyecto arriba de la clase1, o mover el paquete Actores debajo de
Clases A.
Si quiere revertir a listar los componentes en orden alfabtico, haga clic con el botn derecho en el paquete y
seleccione la opcin de men Contenidos | Restaurar el orden.

Mueva los componentes entre los paquetes

Puede haber creado un diagrama, paquetes hijos o elemento en el lugar incorrecto en el Explorador del proyecto.
Para mover un componente del modelo a otro paquete, haga clic en el componente y arrastre al nuevo paquete.
Este puede ser un nivel ms alto y ms bajo.
Puede, por ejemplo, arrastrar Clase 1 en Casos de uso primarios en el paquete Clases A. De esta forma Clase 1
se lista en el paquete Clases A en el Explorador del proyecto. Como un ejemplo similar, podra arrastrar el
Diagrama de clase en el paquete Modelo del proceso de negocio.
Mover elementos al Explorador de proyectos no afecta el uso de elementos en los diagramas (y vice versa). En
nuestro ejemplo, Clase 1 est inicialmente en el diagrama en el paquete Casos de usos primarios. Cuando mueve
Clase 1 en el Explorador del proyecto desde Casos de uso primarios a clases A, este an se muestra en el
diagrama en los Casos de uso primarios, y no se muestra en ningn diagrama en Clase A. Para quitar Clase 1
desde el diagrama Casos de uso primarios, haga clic en este en el diagrama y eliminar. Nada pasa con el
elemento en el Explorador del proyecto. Para poner Clase 1 en el diagrama en el paquete Clases A, abra el
diagrama en ese paquete y arrastre el elemento desde el paquete Clases A en el Explorador del proyecto en el
diagrama.

Mueve los elementos en un diagrama

Si un elemento no est en la posicin correcta en el diagrama, solo haga clic en el medio del mismo y arrastre al
lugar correcto. En el diagrama de arriba, puede mover la Clase2 de abajo Clase 3, y mover la Clase3 a la
izquierda. El elemento trae sus conectores.

Mueve los conectores en un diagrama

Puede haber conectado el par equivocado de elementos. Para mover el final de un conector a un elemento
diferente. Para mover el fina de un conector a un elemento diferente (por ejemplo, Clase2 en lugar de Clase3),
haga clic en el final para mostrar una caja negra de desplazamiento y arrastre al final de su nueva posicin. Sea
consciente que el conector no se sale del elemento de destino original hasta que el cursor este en el siguiente
destino.
Tambin puede ordenar una conexin arrastrando el final del conector a una posicin mejor en el borde del
elemento, o mover los finales de una vez arrastrando la mitad del conector.

Plantillas del modelo

Las plantillas del modelo incluidas en Enterprise Architect se designan para asistir en la creacin de Proyectos y
modelos tanto para usuarios nuevos como para aquellos que ya tienen experiencia. Cada plantilla provee una
estructura sobre la cual puede crear su proyecto.

Formato de la plantilla

Todas las plantillas del modelo proporcionadas con Enterprise Architect siguen el formato que se describe a
continuacin.

Nota
La nota lo introducir a la plantilla del modelo y delinea su propsito.

Vnculos de ayuda
Estos vnculos proveern ms informacin acerca de como usar el modelo. Dependiendo de la plantilla del modelo,
ejemplos y otra informacin til ser tambin vinculada aqu.

Patrones
La seccin del patrn en la plantilla del modelo debera darle una estructura para crear su propio modelo.

Las secciones listadas abajo proveen una introduccin a la terminologa e conos usados en los plantillas del
modelo. Esto le proporcionar una gua rpida a los conceptos importantes del UML, y como estos se aplican en
Enterprise Architect.

Modelado de los procesos de negocio

El Modelado de los proceso de negocio es una parte esencial de cualquier proceso de desarrollo de software.
Permite que el analista capture el esquema general y los procedimientos que gobiernan lo que hace el negocio. Este
modelo provee una vista general de donde el sistema de software propuesto se introducir en la estructura de la
organizacin y sus actividades cotidianas. Puede tambin proporcionar la justificacin para la construccin del
sistema capturando los procedimientos manuales y automticos actuales que sern llevados a cabo dentro del
sistema, y la relacin costo beneficio.

Como un modelo temprano de actividad de negocios, permite al analista capturar eventos significantes, entradas,
recursos y salidas asociados con los procesos de negocios. Conectando despus los elementos diseados (tales
como Casos de Uso) hacia el modelo de procesos de negocio a travs de vnculos de implementacin, es posible
construir una trazabilidad completa del modelo desde los procesos a los requisitos funcionales y eventualmente a
los artefactos de software que estn siendo construidos actualmente.

Como el Modelo de Procesos de Negocio generalmente tiene un amplio y ms exclusivo rango que el sistema de
software que est siendo considerado, tambin permite al analista asignar claramente cual es el alcance del sistema
propuesto y que ser implementado de otra manera.

Modelo de requisito
El Modelo de requisitos es un catlogo estructurado de requerimientos del usuario final y las relaciones entre ellos.
La Administracin de requisitos compilada en Enterprise Architect se puede usar para definir elementos de
requerimientos, vincular requerimientos para los elementos del modelo, vincular requerimientos juntos en una
jerarqua y reportar requerimientos.

MODELO DE CASO DE USO

El Modelo de casos de uso describe la funcionalidad de un sistema en trminos de Casos de uso. Cada Caso de uso
representa una sola interaccin repetida que el usuario o "actor" experimenta cuando usa el sistema, acentuando la
perspectiva de los usuarios del sistema y las interacciones. Ver Casos de uso para obtener ms informacin.

MODELO DEL DOMINIO

Un Modelo del dominio es un modelo conceptual de alto nivel, que define objetos fsicos y abstractos, en un rea
de inters para el Proyecto. Se puede usar para documentar relaciones entre ellos y responsabilidades de clases
conceptuales (es decir, las clases que representan el concepta de un grupo de cosas en lugar de Clases que definen
un objeto de programacin). Esto tambin es til para definir los trminos de un dominio.

Un modelo del dominio muestra:

Las unidades fsicas y de organizacin del dominio; por ejemplo, Empleado y Vuelo.
Las relaciones entre estas unidades; por ejemplo, el empleado es asignado a volar.
La multiplicidad de las relaciones; por ejemplo, un empleado puede ser asignado a ningn vuelo, un vuelo o
muchos vuelos (representado por 1 y * en los finales de la relacin).

MODELO DE CLASES

El Modelo de clase es un modelo riguroso y lgico del sistema de software bajo construccin. Las clases
generalmente tienen una relacin directa con el cdigo fuente y otros artefactos de software que se pueden agrupar
juntos en componentes ejecutables.

MODELO DE BASE DE DATOS

El Modelo de base de datos describe la informacin que debe ser almacenada y recuperada como parte del sistema
completo. Normalmente esto referir a los modelos de base de datos relacional que describen las tablas y datos en
detalle y permitir la generacin de scripts DDL para crear e instalar base de datos.

MODELO DE COMPONENTE

El Modelo del componente define como las clases, artefactos y otros elementos de bajo nivel se agrupan en
componentes de alto nivel, y las interfaces y conexiones entre ellos. Los componentes son artefactos de software
compilados que trabajan juntos para proveer el comportamiento requerido dentro de las restricciones de operacin
definidas en el modelo de requisitos.

MODELO DE DESPLIEGUE
El Modelo de despliegue describe cmo y dnde un sistema se desplegar. Las mquinas fsicas y los procesadores
son representados por nodos, y la construccin interna se puede describir embebiendo nodos y artefactos. Como los
artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicacin se gua por el uso de
especificaciones de despliegue.

MODELO DE PRUEBAS

El Modelo de pruebas describe y mantiene un catlogo de pruebas, planes de prueba y resultados que se ejecutan
en comparacin con el modelo actual.

MODELO DE MANTENIMIENTO
El Modelo de mantenimiento permite una representacin visual de incidencias que surgen durante y despus del
desarrollo del producto de software. El modelo puede ser mejorado con la integracin de elementos de cambios y
pruebas.

DIAGRAMAS

Tipos de Diagramas
La figura debajo muestra la taxonoma de los 13 diagramas UML, como est definido
por la especificacin de UML 2.0 de Grupos de Desarrollo de Objetos. Como se
puede ver, hay dos grupos mayoritarios de diagramas: diagramas Estructurales los
cuales muestran una vista esttica del modelo; y diagramas de Comportamiento los
cuales muestran una vista dinmica del modelo. Para ms detalles acerca de la
construccin de estos diagramas, haga clic en los siguientes vnculos:
DIAGRAMAS ESTRUCTURALES
DIAGRAMA DE CLASES
El diagrama de Clases captura la estructura lgica del sistema - las clases y cosas que constituyen el modelo -. Es
un modelo esttico, describiendo lo que existe y qu atributos y comportamiento tiene, ms que cmo se hace algo.
Los diagramas de Clases son los ms tiles para ilustrar las relaciones entre las clases e interfaces. Las
generalizaciones, las agregaciones y las asociaciones son todas valiosas para reflejar la herencia, la composicin o
el uso y las conexiones respectivamente.
Diagrama de ejemplo
El diagrama de abajo ilustra las relaciones de agregacin entre clases. La agregacin con la punta de flecha en
color claro indica que la clase Cuenta es usada por LibroDeDirecciones, pero que no est contenida
necesariamente. La agregacin con la punta de flecha en color oscuro indica la posesin o la contencin de las
clases destino (en el extremo del rombo) por las clases origen.

Elementos del diagrama de Clase

Conectores del diagrama de clase

Elementos y Conectores de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Clases desde las pgina Clase de la caja de herramientas
del UML de EA

Consejo: Haga clic sobre los siguientes elementos y conectores para obtener ms
informacin.

DIAGRAMA DE OBJETOS
Un diagrama de Objetos est relacionado de cerca con un diagrama de Clases, con la diferencia de que ste
describe las instancias de los objetos de clases en un punto en el tiempo. Esto podra parecer similar al diagrama de
Estructura Compuesta, que modela el comportamiento en tiempo de ejecucin; la diferencia es que el diagrama de
Objetos ejemplifica al diagrama de Clases esttico, mientras que los diagramas de Estructura Compuesta refleja las
arquitecturas diferentes de sus contrapartes estticas. Los diagramas de Objetos no presentan arquitecturas que
varen de sus correspondientes diagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases
instanciadas podran servir. Ellos son muy tiles en la comprensin de diagramas de Clases complejos, al crear
diferentes casos en los que se aplican las relaciones y las clases. Un diagrama de Objetos puede ser tambin un tipo
de diagrama de Comunicaciones, el cual modela tambin las conexiones entre pares de objetos y adems las
secuencias de eventos a lo largo de cada camino.
Tenga en cuenta: Los diagramas de Comunicacin se conocan como diagramas de Colaboracin en UML 1.4.
Diagrama de ejemplo
El siguiente ejemplo primero muestra un diagrama de Clases simple, con dos elementos clase conectados.
Las clases de arriba se instancian abajo como
objetos en un diagrama de Objetos. Hay dos
instancias de Computadora en este modelo, lo
que puede probar su utilidad por considerar las
relaciones y las interacciones que las clases
juegan en la prctica, como objetos.

Elementos de la Caja de
Herramientas y Conectores
Seleccione los elementos y conectores
del diagrama de Objeto desde las
pgina Objeto de la caja de
herramientas del UML de EA.

Consejo: Haga clic sobre los

siguientes elementos y
conectores para obtener ms
informacin.

Object Diagram Elements

Object Diagram Connectors

DIAGRAMA DE COMPONENTE
Un diagrama de Componentes ilustra los fragmentos de software, controladores embebidos, etc. que
conformarn un sistema. Un diagrama de componentes tiene un nivel de abstraccin ms elevado que un
diagrama de clase - usualmente un componente se implementa por una o ms clases (u objetos) en tiempo de
ejecucin. Estos son bloques de construccin, como as eventualmente un componente puede comprender una
gran porcin de un sistema.
Diagrama de ejemplo
El siguiente diagrama muestra algunos componentes y sus relaciones internas. Los conectores emsamble
"vinculan" las interfaces proporcionadas suministrada por Producto y Cliente a las interfaces requeridas
especificadas por Orden. Una relacin de dependencia asigna los detalles de cuenta asociados del cliente a la
interfaz requerida, "pago", indicado por Orden.

Conectores y Elementos de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Componente desde las pginas de Componente de la caja
de herramientas del UML de EA.

Consejo: Haga clic sobre los siguientes elementos y conectores para obtener ms
informacin.
Elementos del diagrama de
componentes

Conectores del diagrama de

componentes

DIAGRAMA DE ESTRUCTURA COMPUESTA

Un diagrama de Estructura Compuesta refleja la colaboracin interna de clases, interfaces o componentes para
describir una funcionalidad. Los diagramas de estructura compuesta son similares a los diagramas de clase, a
excepcin de que estos modelan un uso especifico de la estructura. Los diagramas de clase modelan una vista
esttica de las estructuras de clase, incluyendo sus atributos y comportamientos. Un diagrama de Estructura
Compuesta se usa para expresar arquitecturas en tiempo de ejecucin, patrones de uso, y las relaciones de los
elementos participantes, los que pueden no estar reflejados por diagramas estticos.
En un diagrama de Estructura Compuesta, las clases se acceden como partes o instancias en tiempo de ejecucin
cumpliendo un rol en particular. Estas partes pueden tener multiplicidad, si el rol ocupado por la clase requiere
mltiples instancias. Los puertos definidos por una clase de parte deberan representarse en la estructura
compuesta, asegurando que todas las partes conectadas provean las interfaces requeridas especificadas por el
puerto. Hay una flexibilidad extensa, y una complejidad resultante que viene con el modelado de estructuras
compuestas. Para optimizar su modelado, considere las colaboraciones de compilacin para representar los
patrones reusables respondiendo a su problemas de diseo.
Diagrama de ejemplo
El siguiente diagrama muestra una colaboracin usada en diagramas de Estructura Compuesta para modelar
patrones comunes. Este ejemplo en particular muestra un relacin para realizar una instalacin.

El siguiente diagrama usa la colaboracin instalar en una ocurrencia de colaboracin, y lo aplica a la clase
UtilLoad a travs de una relacin <<represents>>. Esto indica que el clasificador UtilLoad usa el patron
colaboracin dentro de su implementacin. Para ms ejemplos acerca de los diagramas de estructura
compuesta, referirse los elementos de la caja de herramientas listados a continuacin.

Elementos y Conectores de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Compuesta desde las pginas de Compuesta de la caja de
herramientas del UML de EA.
Consejo: Hacer clic en los siguientes elementos y conectores para ms informacin.

Elementos del diagrama de estructura

Conectores del diagrama de estructura

compuesta

compuesta

DIAGRAMA DE DESPLIEGUE
Un diagrama de Despliegue muestra cmo y dnde se desplegar el sistema. Las mquinas fsicas y los
procesadores se representan como nodos, y la construccin interna puede ser representada por nodos o artefactos
embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicacin es
guiada por el uso de las especificaciones de despliegue.
Diagrama de ejemplo
Debajo hay un diagrama de Despliegue. Los dos nodos tienen una ruta de comunicacin TCP/IP indicada. Las
relaciones de Despliegue indican el despliegue de artefactos. Adems, una especificacin de despliegue define el
proceso de despliegue para el artefacto networkScanner. Las relaciones manifestadas revelan la implementacin
fsica de los componentes ReposCustomer y ReposInternalRecords.

Conectores y Elementos de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Despliegue desde las pginas de Despliegue de la caja de
herramientas del UML de EA.

Consejo: Haga clic en los siguientes elementos y conectores para obtener ms informacin.
Elementos del diagrama de
despliegue

Conectores del diagrama de despliegue

DIAGRAMA DEL PAQUETE

Los Diagramas de Paquetes se usan para reflejar la organizacin de los paquetes y sus elementos, y para proveer
una visualizacin de sus correspondientes nombres de espacio.
Diagrama de ejemplo
El ejemplo siguiente muestra un diagrama de Paquetes bsico. El conector anidado entre ConnSeq y Controller
refleja lo que revela el contenido del paquete. El contenido del Paquete se puede listar accediendo en el fondo del
diagrama par amostrar la ventana Propiedades del diagrama, seleccionando la pestaa Elementos y seleccionando
la Casilla de contenidos del paquete.
El conector import indica que los elementos en el paquete Entero destino, que en este ejemplo es una nica
clase, Entero, se importar en el paquete Controlador. El nombre de espacio del Controlador obtendr acceso a la
clase Entero; el nombre de espacio de Entero no se afecta.
El conector merge indica que los elementos del paquete Controlador se importarn en GenApply, incluyendo los
contenidos anidados e importados de Controlador. Si un elemento ya existe en GenApply, tal como Cargador y
Tiempo, las definiciones de estos elementos se expandirn por aquellas que se incluyen en el paquete Controlador.
Todos los elementos agregados o actualizados por la mezcla son representados por una relacin de generalizacin
de vuelta a este paquete.
Tenga en cuenta: Los elementos privados de un paquete no se pueden importar o mezclar.

Elementos y Conectores de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Paquetes desde las pgina Clase de la caja de herramientas
del UML de EA

Consejo: Haga clic sobre los siguientes elementos y conectores para obtener ms
informacin.
Elementos del diagrama de
paquetes

Conectores del diagrama de paquetes

DIAGRAMAS DE COMPARTIMIENTO
DIAGRAMA DE ACTIVIDADES
Los diagramas de actividades se usan para modelar el comportamiento de un sistema, y la manera en que ste
comportamiento est relacionado con un flujo global del sistema. Se usan los caminos lgicos que sigue un
proceso basado en varias condiciones, concurrencia en el proceso, los datos de acceso, interrupciones y otras
alternativas del camino lgico para construir un proceso, sistema o procedimiento.
Tenga en cuenta: Los Diagramas de Anlisis (de Actividades simplificados) contienen los elementos que se deben
usar para modelar el proceso de negocio, que se puede crear usando la opcin Nuevo Diagrama
Diagrama de Ejemplo
El siguiente diagrama muestra algunas caractersticas de los diagramas de Actividades, incluyendo actividades,
acciones, nodos de inicio, nodos de finalizacin y puntos de decisin.

Elementos y Conectores de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Actividad desde las pgina Actividad de la caja de
herramientas del UML de EA
Consejo: Haga clic en los siguientes elementos y conectores para obtener ms informacin.
Activity Diagram Elements

Activity Diagram Connectors

DIAGRAMA DE CASO DE USO

Un diagrama de Casos de Uso captura las interacciones de los casos de uso y los
actores. Describe los requisitos funcionales del sistema, la forma en la que las cosas
externas (actores) interactan a travs del lmite del sistema y la respuesta del
sistema.
Diagrama de Ejemplo
El diagrama de ejemplo de abajo ilustra algunas caractersticas de los diagramas de
Casos de Uso:

Elementos y Conectores de la Caja de Herramientas

Consejo: Haga clic sobre los elementos y conectores de abajo para ms
informacin.

Elementos de los Diagramas de Casos de Conectores de los Diagramas de Casos de

Uso
Uso

DIAGRAMA DE MAQUINA DE ESTADO

Tener en cuenta: Los diagramas de Mquinas de estado eran conocidos como diagramas de estado.
Un diagrama de Mquina de estados ilustra cmo un elemento (a menudo una clase) se puede mover entre
estados, clasificando su comportamiento de acuerdo con los disparadores de transiciones y las guardas de
restricciones. Otros aspectos de los diagramas de Mquinas de Estados describen y explican el movimiento y el
comportamiento. Las representaciones de mquinas de estado en UML se basan en la notacin de cuadro de
estado Harel (vea la especificacin de la superestructura del UML de la OMG 2.1.1, seccin 15, Mquinas de
estado), y por esta razn algunas veces se refieren a estas como cuadro de estado.
Puede mostrar un Mquina de estado como un diagrama (como a continuacin) o como una tabla en uno de tres
formatos de relaciones. En todos los formatos, usa la misma caja de herramientas del UML de EA elementos and
conectores.

Para seleccionar el formato de disposicin, proceda con los siguientes pasos:

1. Haga clic con el botn derecho en el fondo del diagrama para mostrar el men contextual.
2. Seleccione la opcin Editor del cuadro de estado.
3. Seleccione la opcin de disposicin apropiada:
Diagrama
Tabla (Estado-Estado siguiente)
Tabla (Estado-Disparador)
Tabla (Disparador-Estado)
Diagrama de ejemplo
El diagrama de abajo ilustra algunas caractersticas de los diagramas de Mquina de Estados. El estado Guardado
es un estado compuesto, y los estados contenidos son sub-estados. Los pseudo-estados inicial y final indican la
entrada y la salida de la mquina de estados. Los estados compuestos y sub-estados son elementos de estado, un
estado compuesto es un elemento de estado extendido que comprende otros elementos de estado, los cuales son
luego referenciados como sub-estados.

Elementos y Conectores de la Caja de Herramientas

Seleccione los elementos y conectores del diagrama de Mquina de estado desde las pgina Estado de la caja de
herramientas del UML de EA
Consejo: Haga clic en los siguientes elementos y conectores para obtener ms informacin.
Elementos del diagrama de Mquina de Estado

Conectores del diagrama de Mquina de estado