Investigacion Modelado de Procesos de Negocio

Tecnologas de la informacin y comunicacin
Universidad Tecnolgica del Sureste de Veracruz

Tecnologas de la Informacin y Comunicacin
INVESTIGACION
Modelado de procesos de negocio
Realizar una investigacin acerca de:
- Modelado del dominio.
- Diagramas de casos de uso.
- Diagramas de componentes.
- Diagramas de colaboracin.
- Diagramas de objetos.
PRESENTAN
Eneida Isabel Domnguez Ramos
CUATRIMESTRE Y GRUPO
Sptimo 701
NOMBRE DEL DOCENTE
MC. Eunice Morales Reyes
Cd. Nanchital, Ver., Lunes 03 de Diciembre del 2012

INVESTIGACIN
Modelado del Dominio
Un Modelo de Dominio es una representacin visual de clases
conceptuales o de objetos reales en un dominio de inters [MO95].

Un Modelo de Dominio consiste en un conjunto de diagramas de clases,
sin definicin de operaciones.
Entrada:
Descripcin del problema,
Casos de Uso
Salida:
Un conjunto de diagramas de clases
El modelo de dominio proporciona una perspectiva conceptual
Objetos del dominio o clases conceptuales

Pgina 2

INVESTIGACIN
Asociaciones entre clases conceptuales

Atributos de las clases conceptuales
La informacin que contienen tambin puede ser expresada en forma de texto

plano.
Objetos
Un objeto es una cosa con identidad nica en un dominio de problema.
Carlos Prez, USB, Venezuela son objetos
Todos los objetos tienen una identidad y son distinguibles.
Los objetos se distinguen por su existencia inherente y no por las propiedades
descriptivas que puedan tener
Dos manzanas con el mismo color, forma y textura siguen siendo manzanas
individuales.
Clases y objetos
Una clase describe un grupo de objetos con las mismas propiedades,
comportamientos y relaciones posibles.
Un objeto es una instancia de una clase.

Persona, Universidad y Pas son clases.
Los objetos de un dominio son el foco del modelado.

Por qu clases conceptuales?
El poder de la abstraccin.
El nivel de abstraccin es un asunto de juicio y est relacionado con la
aplicacin.
La descripcin de un cliente de un futuro sistema puede tener una combinacin de

clases y objetos.
Clases y clases conceptuales
El modelo de dominio es una visualizacin de elementos de un dominio de inters
en el mundo real.
Pgina 3

INVESTIGACIN
Los modelos de dominio no deben mostrar clases de software.
Como crear un modelo de dominio?

Pasos:
1. Hallar las clases conceptuales.
2. Dibujar las clases conceptuales como clases de un diagrama de clases
UML.
3. Aadir asociaciones y atributos.
Hallar las clases conceptuales

Pgina 4

INVESTIGACIN
Tres estrategias:
Reusar o modificar modelos existentes

Existen modelos de dominio y de datos publicados y bien elaborados para
dominios comunes: inventario, finanzas, salud, etc.
Fowler, Analysis patterns

Hay, Data Model Patterns
Silverston, Data Model Resource Book
Usar una lista de categoras.
Identificar sustantivos/frases nominales
Diagrama de casos de usos

Pgina 5

INVESTIGACIN
Secuencia de transacciones desarrolladas por un sistema en respuesta a
un evento iniciado por un actor

Sirven para especificar la funcionalidad y el comportamiento de un sistema
Un diagrama de caso de uso muestra las relaciones entre actores y casos
de uso dentro del sistema

Un caso de uso es una unidad coherente de una funcionalidad provista por
el sistema (o una clase)

Un actor es un rol de un objeto/s. Un objeto fsico pueda tener varios roles
-> varios actores

Relacin de Caso de Uso: comunica, extiende y usa.
Medio de comunicacin entre usuarios finales, expertos del dominio y

desarrolladores sin entrar en detalles.
Representa un requisito funcional.

Definen el que (y no el como).
Se pueden describir con texto (estructurado o no) y luego con diagramas
de interaccin.
Un diagrama para el flujo principal y variaciones para los flujo flujos s

excepcionales.
Cada secuencia es un escenario (principal o secundario).
Los escenarios con a los casos de uso lo que las instancias son a las clases.
Se organizan en paquetes.
El mtodo de Punto de Caso de Uso (UCP Use Case Point)
Est basado en los tradicionales Puntos Funcin.

Es un mtodo originado de la tesis de master de Gustav Karner (Karner,
1993).
Desarrollada mientras trabajaba en Objectory AB, bajo supervisin de Ivar
Jacobson (creador de los casos de uso).
Interaccin de usuarios con componentes del sistema
Actores
Entidad externa que interacta con el software

Promueve la simulacin de eventos
Pueden ser personas, clases, herramientas de SW, etc.
Diagrama de Casos de Uso

Pgina 6

INVESTIGACIN
Grafo de actores y casos de uso
Focaliza en que acciones, mtodos, funciones, etc. Son utilizadas por que actor.
Vista de caja negra de componentes del sistema
Derivado de entrevistas del usuario y/o modelo de negocio
Ventajas
Se deben revisar los aspectos clave de los requerimientos para calcular

un recuento de Puntos Caso de Uso sin ajustar (UUCP Unadjusted Use
Case Points).
Estudiar los factores tcnicos y el entorno para crear los factores de
ajuste.
Ajustar los factores para llegar a obtener los Puntos Caso de Uso
ajustados (UCP), que posteriormente se transformarn en una estimacin
de esfuerzo (horas-hombre).
En la Figura 1 se pueden observar los pasos bsicos del mtodo de estimacin

Puntos Caso de Uso (UCP).
Pgina 7

INVESTIGACIN
Casos de uso & Actores
Un escenario es una instancia de un caso de uso.

El actor es un rol rol, no un individuo
el bibliotecario puede tener varios roles.
El actor debe ser un beneficiario del caso de uso
Pgina 8

INVESTIGACIN
Pgina 9

INVESTIGACIN
Clculo de los Puntos Caso de Uso sin ajustar (UUCP)
Para realizar el clculo de los Puntos Caso de Uso sin ajustar, se tienen que
realizar los tres pasos definidos a continuacin.
Clasificar cada interaccin entre actor y caso de uso segn su
complejidad y asignarle un peso.

Calcular la complejidad de cada caso de uso segn el nmero de
transacciones o pasos del mismo.

Calcular los Puntos Caso de Uso no ajustados (UUCP Unadjusted
Use Case Points):

1.-Clasificar cada interaccin entre actor y caso de uso segn su complejidad y
asignarle un peso:
Para clasificar la complejidad de los actores se debe determinar la forma

en la que cada actor interacta con el sistema que se va a desarrollar.
En concreto, los actores se clasifican en 3 categoras diferentes, simple,

medio y complejo.
1.-Clasificar cada interaccin entre actor y caso de uso segn su complejidad y

asignarle un peso:
Un actor simple representa otro sistema con una API definida.
un actor medio es otro sistema que interacta a travs de un protocolo

como por ejemplo TCP/IP o es una persona interactuando a travs de una
interfaz por lnea de comandos.
un actor complejo interacta a travs de una interfaz grfica.
Una vez clasificado cada actor segn su tipo de interaccin, se le asigna el peso
correspondiente asociado a dicha interaccin.
En la Tabla 1, se presenta un resumen del procedimiento de clasificacin de los
actores.
Pgina 10

INVESTIGACIN
Tabla 1. Clasificacin de los Actores

Para realizar el clculo de la complejidad de un caso de uso se debe determinar el
nmero de transacciones, incluyendo los caminos alternativos.
Una transaccin es un conjunto de actividades atmicas, donde se
ejecutan todas ellas o ninguna.

En este contexto, cada caso de uso se debe clasificar en una de las
siguientes categoras: simple, medio o complejo.
En concreto, un caso de uso simple tiene 3 o menos transacciones, un caso de

uso medio de 4 a 7 transacciones, y un caso de uno complejo ms de 7
transacciones.
Una vez clasificado cada caso de uso, segn el nmero de transacciones, se le
asigna el peso asociado a dicho nmero de transacciones.
En la Tabla 2 se presenta un resumen del procedimiento de clasificacin de los
casos de uso.
Tabla 2. Clasificacin de los Casos de Uso
Pgina 11

INVESTIGACIN
3.-Calcular los Puntos Caso de Uso no ajustados (UUCP )
Los UUCP se calculan sumando la dificultad de las interacciones y la complejidad
de los casos de uso.
Es decir, sumando el total de los pesos de los actores (clasificados en el paso 1) y
el total de los pesos para los casos de uso (clasificados en el paso 2).
Clculo de los factores tcnicos (TCF)
Pgina 12

INVESTIGACIN
Para ajustar los UUCP (Puntos Caso de Uso no ajustados) calculados en los
pasos anteriores, se deben tener en cuenta factores de ajuste, tanto factores
tcnicos, como factores de entorno.
En el caso de los factores tcnicos (TCF), a cada factor se le asigna un valor
entre 0 y 5, dependiendo de su influencia en el proyecto.
Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3
es promedio y un valor 5 significa que el factor es esencial.
Una vez que todos los factores tcnicos tienen asignado el valor de la influencia,
se procede al clculo de los resultados de cada factor, es decir, se realiza una
multiplicacin entre la influencia del factor y su peso asociado.
Cuando se han calculado los resultados de cada uno de los factores tcnicos, se
aplica la expresin descrita a continuacin, donde el sumatorio se corresponde a
la suma de los resultados de los factores tcnicos.
TCF= 0,6 + (0,01 * Sumatorio)
Clculo de los factores de entorno (EF)

Factores de entorno:
Pgina 13

INVESTIGACIN
Para ello, a cada factor de entorno definido en la Tabla 4 (R1) se le asigna un
valor entre 0 y 5 dependiendo de su influencia en el proyecto.
Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3
es promedio y un valor 5 significa que el factor es esencial.
Una vez que todos los factores de entorno tienen asignado el valor de la
influencia.
Se procede al clculo de los resultados de cada factor, es decir, se realiza una
multiplicacin entre la influencia del factor y su peso asociado, ver en la Tabla 4 la
columna Resultado.
En la Tabla 4 se presenta un resumen del procedimiento del clculo de los

factores de entorno, siendo R1 los factores concretos.
Clculo de los Puntos de Caso de Uso ajustados (UCP)
Pgina 14

INVESTIGACIN
Finalmente, para obtener los Puntos Caso de Uso ajustados (UCP) se utilizan los
datos obtenidos en los pasos anteriores, Puntos Caso de Uso fno ajustados
(UUCP) y factores de ajuste (TCF y EF), haciendo uso de la expresin que se
presentan a continuacin.
UCP = UUCP * TCF * EF
Se debe tener en cuenta que a travs del clculo de esta expresin obtenemos
una estimacin del tamao y no del esfuerzo.
Estimacin del esfuerzo
Como ocurre en otros mtodos de estimacin, una vez obtenido el tamao, se
puede obtener el esfuerzo. Para ello, se utiliza la siguiente expresin:
Esfuerzo = UCP * Factor de Productividad
Clculo de los Puntos de Caso de Uso ajustados (UCP)

El mtodo originario propone usar un factor de ajuste (Factor de Productividad) .
Similar al que se usa en el mtodo de Puntos Funcin clsico, si bien Karner
propone concretamente 20 personas hora por cada Punto Caso de Uso (UCP).
Diagramas de Componentes
Pgina 15

INVESTIGACIN
Los diagramas de componentes describen los elementos fsicos del sistema y sus
relaciones y
Muestran las opciones de realizacin incluyendo cdigo fuente,
binario y ejecutable.
Los componentes representan todos los tipos de elementos software que entran
en la fabricacin de aplicaciones informticas, Pueden ser simples archivos,
paquetes, bibliotecas cargadas dinmicamente, etc.
La representacin grfica es la siguiente:
UML define cinco estereotipos estndar que se aplican a los componentes:
Executable: Especifica un componente que se puede ejecutar en un nodo.

Library: Especifica una biblioteca de objetos esttica o dinmica.
Table: Especifica un componente que representa una tabla de una base de
datos.
Pgina 16

INVESTIGACIN
File: Especifica un componente que representa un documento que contiene
cdigo fuente o datos.

Document: Especifica un componente que representa un documento.
Dependencias entre Componentes

Las relaciones de dependencia se utilizan en los diagramas de componentes para
indicar que un componente se refiere a los servicios ofrecidos por otro
componente
Subsistemas
Los distintos componentes pueden agruparse en paquetes segn un
criterio lgico y con vistas a simplificar la implementacin

Son paquetes estereotipados en <<subsistemas>>
Pgina 17

INVESTIGACIN
Los subsistemas organizan la vista de realizacin de un sistema

Cada subsistema puede contener componentes y otros subsistemas
La descomposicin en subsistemas no es necesariamente
descomposicin funcional
La relacin entre paquetes y clases en el nivel lgico es el que existe entre
subsistemas y componentes en el nivel fsico

Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas)
una
y componentes en el nivel fsico
El Modelo de Componentes
Este artculo describe cmo modelar los componentes de software y hardware en
UML. El modelo de componentes ilustra los componentes de software que se
usarn para construir el sistema. Se pueden construir a partir del modelo de
clases y escribir desde cero para el nuevo sistema o se pueden importar de otros
proyectos y de productos de terceros. Los componentes son agregaciones de alto
nivel de las piezas de software ms pequeas y proveen un enfoque de
construccin de bloques de caja negra para la elaboracin de software.
Pgina 18

INVESTIGACIN
Introduccin al UML
El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un
lenguaje de modelado y no un mtodo o un proceso. El UML est compuesto por
una notacin muy especfica y por las reglas semnticas relacionadas para la
construccin de sistemas de software. El UML en s mismo no prescribe ni
aconseja cmo usar esta notacin en el proceso de desarrollo o como parte de
una metodologa de diseo orientada a objetos.
El UML soporta un conjunto rico en elementos de notacin grficos. Describe la
notacin para clases, componentes, nodos, actividades, flujos de trabajo, casos
de uso, objetos, estados y cmo modelar la relacin entre esos elementos. El
UML tambin soporta la idea de extensiones personalizadas a travs elementos
estereotipados.
El UML provee beneficios significativos para los ingenieros de software y las
organizaciones al ayudarles a construir modelos rigurosos, trazables y
mantenibles, que soporten el ciclo de vida de desarrollo de software completo.
En los libros mencionados en la seccin de lectura recomendada se puede
encontrar ms informacin sobre el UML y de los documentos de especificacin
del UML que se pueden encontrar en las pginas de recursos de UML del OMG
(Object Management Group).
La Notacin de Componentes
Un componente puede ser algo como un control Actives; tanto un componente de
la interfaz de usuario como un servidor de reglas de negocio. Los componentes se
representan grficamente como muestra la figura siguiente:
Pgina 19

INVESTIGACIN
El Diagrama de Componentes
El diagrama de componentes muestra la relacin entre componentes de software,
sus dependencias, su comunicacin su ubicacin y otras condiciones.
Interfaces
Los componentes tambin pueden exponer las interfaces. Estas son los puntos
visibles de entrada o los servicios que un componente est ofreciendo y dejando
disponibles a otros componentes de software y clases. Tpicamente, un
componente est compuesto por numerosas clases y paquetes de clases
Pgina 20

INVESTIGACIN
internos. Tambin se puede crear a partir de una coleccin de componentes ms
pequeos.
Los componentes y los Nodos

Un diagrama de despliegue muestra el despliegue fsico del sistema en un
ambiente de produccin (o de prueba). Muestra dnde se ubican los
componentes, en qu servidores, mquinas o hardware. Puede representar los
enlaces de redes, el ancho de banda de la LAN, etc.
Requisitos
Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones
contractuales; esto es, qu servicios proveen en el modelo. Los requisitos ayudan
a documentar el comportamiento funcional de los elementos de software.
Pgina 21

INVESTIGACIN
Restricciones
Los componentes pueden restricciones asignadas que indican el entorno en el
que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de
que un componente pueda realizar alguna funcin; las post-condiciones indican lo
que debe ser verdadero despus de que un componente haya realizado algn
trabajo y los invariantes especifican lo que debe permanecer verdadero durante la
vida del componente.
Un Ejemplo
El ejemplo siguiente muestra cmo se pueden relacionar los componentes para
proveer una vista conceptual/lgica de la construccin de un sistema. Este
ejemplo representa los elementos del servidor y la seguridad de una tienda de
Pgina 22

INVESTIGACIN
libros en lnea. Se incluyen elementos tales como el servidor WEB, el firewall, las
pginas ASP, etc.
Los Componentes de Servidor
Este diagrama ilustra la organizacin de los componentes del lado del servidor
principal que se requerir construir para una tienda de libros en lnea. Estos
componentes son una mezcla de los tems construidos a medida y adquiridos que
se ensamblarn para proveer la funcionalidad requerida.
Los Componentes de Seguridad

El diagrama de componentes de la seguridad muestra cmo trabaja en conjunto el
software de seguridad, tal como la Autoridad Certificadora (Certificate Authority),
Pgina 23

INVESTIGACIN
el navegador (Browser), el servidor WEB y otros elementos del modelo para
asegurar la provisin de la seguridad en el sistema propuesto.
Diagrama de colaboracin
En los contratos de colaboracin se incluye una primera conjetura ptima sobre
las poscondiciones referentes al inicio de las operaciones del sistema: inicio,
Pgina 24

INVESTIGACIN
introducirProducto, terminarVenta y efectuarPago. Los contratos no muestran una
solucin de cmo los objetos de software van a cumplir con ellas.
Los diagramas de colaboracin destacan la organizacin estructural de objetos
que envan y reciben mensajes.
Actividades y dependencias
Los diagramas de interaccin se realizan en la fase de diseo de un ciclo de
desarrollo. Para preparar tenemos primero debemos generar los siguientes
artefactos:
Un modelo conceptual: a partir de este modelo el diseador podr definir

las clases del software correspondientes a los conceptos. Los objetos de
las clases participan en las interacciones que se describen grficamente en
los diagramas.
Contratos de la operacin del sistema: a partir de ellos el diseador

identifica las responsabilidades y las poscondiciones que han de llenar los
diagramas de interaccin.
Ciclo de desarrollo
Pgina 25

INVESTIGACIN
Perfeccionamiento Sincronizacin
del plan
de artefactosAnlisis
2. Definir los reportes, la1.interfaz

3. Perfeccionar
y lasde
storyboards.
la arquitectura del sistema. b
Definir del
los usuario,
casos
reales
uso.
5. Definir
los diagramas
de
de diseo.
a
4. Definir
los diagramas
de interaccin.
6.clases
Definir
el esquema
de la base de datos.
Actividades de la fase de diseo dentro de un ciclo de desarrollo

Casos de uso:
- expandidos
- esenciales
Casos de uso:
- reales
Ventanas y reportesCasos de prueba
Diagramas de casos de uso

Diagramas de interaccin
Mtodos
Modelo conceptual
Glosario
Diagramas de clase de diseo

Definiciones de clase y de interfaz
Diagramas de secuencia del sistema
Diagramas de paquete de arquitectura

Contratos de operacin
Pgina 26
Diagramas de estado
Esquema de base de datos
SQL

INVESTIGACIN
Sintaxis secuencia / colaboracin

Los diagramas de colaboracin describen las interacciones entre los objetos en
un formato de grafo red.
objetoA:A
1: <<create>>
2: mensaje1( )
3: <<destroy>>
objetoB:B
objetoC:C
2.1: mensaje2( )
2.2: mensaje3( )
Notacin bsica de los diagramas de colaboracin

Representacin grfica de las clases y de las instancias:
El UML ha adoptado un mtodo simple y uniforme de describir visualmente las
instancias para distinguirlas de los tipos:
Con cada tipo de elemento del UML (clase, actor, ), una instancia utiliza
el mismo smbolo grfico usado para representar el tipo, pero se subraya el
texto.
Pgina 27
Tecnologas
de la Informacin
y Comunicacin
:Venta
s1: Venta
Venta
INVESTIGACIN
clase
instancia
instancia
con nombre
Por tanto, para incluir la instancia de una clase en un diagrama de interaccin, se

recurre al smbolo grfico usual de la casilla de la clase, solo el nombre se
subraya.
En un diagrama de colaboracin, al nombre de la clase siempre se le antepone
dos puntos.
Finalmente, un nombre de distancia sirve para identificarla de modo inequvoco .
Representacin grfica de los vnculos

El vnculo es una trayectoria de conexin entre dos instancias; indica
alguna forma de navegacin y visibilidad que es posible entre las instancias. En
un lenguaje ms formal, el vnculo es una instancia de una asociacin.
Si vemos dos instancias en una relacin de cliente/servidor, una trayectoria de
navegacin del cliente al servidor significa que los mensajes pueden enviarse del
primero al segundo. As, existe un vnculo entre TPDV y una Ventana, a lo largo
del cual pueden fluir los mensajes; por ejemplo, el mensaje agregarPago.
Representacin grfica de los mensajes

Los mensajes entre objetos pueden representarse por medio de una flecha con un
nombre y situada sobre una lnea del vnculo. A travs de ste puede fluir un
nmero indefinido de mensajes. Se agrega un nmero de secuencia que indique
el orden consecutivo de los mensajes en la serie de control.
Pgina 28

INVESTIGACIN
Representacin grfica de los parmetros

Los parmetros de un mensaje pueden anotarse dentro de parntesis del nombre
del mensaje. Es opcional incluir o no el tipo de parmetro en cuestin.
Representacin grfica del mensaje de devolver valor

Pueden incluir un valor de retorno anteponindole al mensaje un nombre de
variable de esa instruccin y un operador de asignacin. Es opciones mostrar el
tipo de valor retorno.
Pgina 29

INVESTIGACIN
Sintaxis de los mensajes

El lenguaje UML cuenta con una sintaxis estndar para los mensajes:
retorno: mensaje(parmetro : tipoParmetro ) : tipoRetorno
Es legal servirse de otra sintaxis como la de Java o la de Smalltalk.
Recomendamos emplear la sintaxis estndar de UML a fin de que los diagramas
de colaboracin sigan siendo un lenguaje relativamente independiente.
Representacin grfica de los mensajes al emisor o a esto

Puede enviarse un mensaje de un objeto a s mismo.
Esto lo muestra grficamente un vnculo consigo mismo, donde el mensaje fluye a
lo largo del vnculo.
Pgina 30

INVESTIGACIN
Representacin grfica de la iteracin

La iteracin se indica posponiendo un asterisco(*) al nmero de secuencia.
Ese smbolo significa que, dentro de un ciclo, el mensaje va a ser enviado
repetidamente al receptor.
Tambin es posible incluir una clusula de iteracin que indique los valores de
recurrencia.
Pgina 31

INVESTIGACIN
Si se expresa ms de un mensaje que ocurre dentro de la misma clusula de
iteracin (por ejemplo, una serie de mensajes en un ciclo for), se repetir la
clusula con cada mensaje.
En los pasos siguientes se denotara la construccin del diagrama de colaboracin

Para elaborar un diagrama de colaboracin se debe aplicar las siguientes normas.
1. Elaborar un diagrama por cada operacin del sistema durante el ciclo
actual de desarrollo.
2. Si el diagrama se torna complejo, dividir en diagramas mas pequeos.
3. Disear un sistema de objetos interactivos que realicen las tareas, usando
como punto de partida las responsabilidades del contrato de operacin, las
poscondiciones y la descripcin de casos de uso. Aplicar el GRASP y otros
patrones para desarrollar un buen diseo.
Pgina 32

INVESTIGACIN
La relacin entre los artefactos incluye lo siguiente:
Los casos de uso indican los eventos del sistema que se muestran
explcitamente en los diagramas de su secuencia.
En los contratos se describe la mejor conjetura inicial sobre las

operaciones del sistema.
Las operaciones del sistema representa mensajes y stos originan

diagramas que explican grficamente cmo los objetos interactan para
llevar a cabo las funciones requeridas.
Pgina 33

INVESTIGACIN
Diagrama de objetos
Los diagramas de objetos de UModel 2013 representan un nico ejemplo de una
clase y se utilizan para ilustrar un punto de datos en su aplicacin.
Los diagramas de objetos UML utilizan una notacin similar a los diagramas de
clases y se utilizan para ilustrar una instancia de una clase en un momento dado.
Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de
una clase y de sus relaciones.
Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A
veces se dibujan durante el proceso de planificacin de clases o para ayudar a
partes interesadas para quienes los diagramas de clases sean demasiado
abstractos.
Un objeto tambin se puede entender como la descripcin de un individuo que
forme parte de un grupo, mientras que las clases describen las caractersticas
compartidas por el grupo. As pues "CuentaCorriente" puede definirse como una
clase UML en UModel 2013 y "Cuenta corriente de John en Agency Bank" se
ilustrara como un diagrama de objetos.
Pgina 34

INVESTIGACIN
Cuando cree un objeto nuevo, llamado especificacin de instancia en la barra de
herramientas y en los mens de UModel, podr asignar una clase ya existente al
objeto. UModel 2013 inserta automticamente en el objeto instancias de las
propiedades pertinentes desde la clase y el usuario puede insertar valores de
muestras para el objeto.
En el ejemplo que aparece a continuacin se cre un objeto nuevo basado en una
clase llamada StockTradingAccount. El diseador del modelo an no asign un
valor a las propiedades balance, id ni SecretTradingPassword.
Puesto que los diagramas de objetos utilizan notaciones muy similares a los
diagramas de clases, la barra de herramientas de diagramas de objetos usa
algunos de los iconos de la barra de herramientas de diagramas de clases. Para
editar los atributos y valores de un objeto puede utilizar la barra de herramientas,
el cuadro de dilogo de propiedades o editar estos datos directamente en el
diagrama.
Pgina 35

INVESTIGACIN
La barra de herramientas de diseo ofrece gran cantidad de opciones de
alineacin que estarn disponibles cuando seleccione varios elementos.
.
En UML, un objeto se representa por un rectngulo con un nombre subrayado.
Objeto = Identidad + Estado + Comportamiento
El estado est representado por los valores de los atributos.
Un atributo toma un valor en un dominio concreto.
Caractersticas alrededor de un objeto:

Estado:
El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el
comportamiento agrupa las competencias de un objeto y describe las acciones y
reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un
estmulo externo representado como mensaje enviado desde otro objeto.
Persistencia:
La persistencia de los objetos designa la capacidad de un objeto trascender en el
espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria
secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los
lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera
ser transparente, un objeto existe desde su creacin hasta que se destruya.
Comunicacin:
Un sistema informtico puede verse como un conjunto de objetos autnomos y
concurrentes que trabajan de manera coordinada en la consecucin de un fin
especfico. El comportamiento global se basa pues en la comunicacin entre los
objetos que la componen.
Pgina 36

INVESTIGACIN
Referencias Bibliogrficas
www.omg.org/uml/
Meta-links www.celigent.com/uml/ y www.cetus-links.org/oo_uml.html
Pierre-Alain Muller Instant UML
Martin Fowler, UML Destilled (UML Gota a Gota)
Terry Quatrani, Visual Modeling ..., un caso de estudio
modelo_de_componentes-1.pdf
M2tema12.pdf
http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calida
dsw/criterios.htm
http://trevinca.ei.uvigo.es/~ebalonso/asignaturas/esx/guiones/esxClase26.p
df
http://www.altova.com/es/umodel/object-diagrams.html
Pgina 37

Investigacion Modelado de Procesos de Negocio

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Investigacion Modelado de Procesos de Negocio

Hochgeladen von

Copyright:

Verfügbare Formate

Tecnologas de la informacin y comunicacin

Universidad Tecnolgica del Sureste de Veracruz

Tecnologas de la Informacin y Comunicacin

Un Modelo de Dominio es una representacin visual de clases

conceptuales o de objetos reales en un dominio de inters [MO95].

El modelo de dominio proporciona una perspectiva conceptual

Objetos del dominio o clases conceptuales

Tecnologas de la Informacin y Comunicacin

Asociaciones entre clases conceptuales

La informacin que contienen tambin puede ser expresada en forma de texto

Un objeto es una instancia de una clase.

Los objetos de un dominio son el foco del modelado.

La descripcin de un cliente de un futuro sistema puede tener una combinacin de

Tecnologas de la Informacin y Comunicacin

Los modelos de dominio no deben mostrar clases de software.

Como crear un modelo de dominio?

Hallar las clases conceptuales

Tecnologas de la Informacin y Comunicacin

Reusar o modificar modelos existentes

Fowler, Analysis patterns

Diagrama de casos de usos

Tecnologas de la Informacin y Comunicacin

Secuencia de transacciones desarrolladas por un sistema en respuesta a

un evento iniciado por un actor

de uso dentro del sistema

el sistema (o una clase)

-> varios actores

Medio de comunicacin entre usuarios finales, expertos del dominio y

Representa un requisito funcional.

Un diagrama para el flujo principal y variaciones para los flujo flujos s

El mtodo de Punto de Caso de Uso (UCP Use Case Point)

Est basado en los tradicionales Puntos Funcin.

Interaccin de usuarios con componentes del sistema

Entidad externa que interacta con el software

Diagrama de Casos de Uso

Tecnologas de la Informacin y Comunicacin

Se deben revisar los aspectos clave de los requerimientos para calcular

En la Figura 1 se pueden observar los pasos bsicos del mtodo de estimacin

Tecnologas de la Informacin y Comunicacin

Casos de uso & Actores

Un escenario es una instancia de un caso de uso.

Tecnologas de la Informacin y Comunicacin

Tecnologas de la Informacin y Comunicacin

Clasificar cada interaccin entre actor y caso de uso segn su

complejidad y asignarle un peso.

transacciones o pasos del mismo.

Clculo de los Puntos Caso de Uso sin ajustar (UUCP)

Para clasificar la complejidad de los actores se debe determinar la forma

En concreto, los actores se clasifican en 3 categoras diferentes, simple,

1.-Clasificar cada interaccin entre actor y caso de uso segn su complejidad y

Un actor simple representa otro sistema con una API definida.

un actor medio es otro sistema que interacta a travs de un protocolo

un actor complejo interacta a travs de una interfaz grfica.

Tecnologas de la Informacin y Comunicacin

Tabla 1. Clasificacin de los Actores

Una transaccin es un conjunto de actividades atmicas, donde se

ejecutan todas ellas o ninguna.

En concreto, un caso de uso simple tiene 3 o menos transacciones, un caso de

Tabla 2. Clasificacin de los Casos de Uso

Tecnologas de la Informacin y Comunicacin

Clculo de los factores tcnicos (TCF)

Tecnologas de la Informacin y Comunicacin

Clculo de los factores de entorno (EF)

Tecnologas de la Informacin y Comunicacin