Este documento presenta el desarrollo de un sistema de información basado en SOA para administrar una pollería. Se aplica la metodología RUP para realizar el modelado de negocios, análisis de requisitos, análisis y diseño, e implementación de la aplicación. Adicionalmente, se utiliza el framework SOMF para modelar los servicios web mediante análisis orientado a servicios, integración de negocios y diseño orientado a servicios. El sistema permite llevar el control de ventas, compras, costos de viajes

1. Desarrollo de un sistema de
Información Basado en SOA
Manuel Maldonado Mendoza

2. Benemérita Universidad Autónoma de Puebla
Facultad de Ciencias de la Computación
“Desarrollo de un sistema de información basado
en SOA (Arquitectura Orientada a Servicios)”
Tesis Profesional
Para obtener el título de:
Ingeniero en Ciencias de la Computación
Presenta:
Manuel Maldonado Mendoza
Asesor:
Dr. Abraham Sánchez López .
Puebla, Pue. Primavera 2012

3. Contenido
Capítulo 1 ............................................................................................................................................... 1
Contribución del trabajo de tesis .............................................................................................. 1
Capítulo 2 ............................................................................................................................................... 3
Estado del arte ................................................................................................................................. 3
2.1 Introducción ............................................................................................................................... 3
2.2 SOA ............................................................................................................................................... 3
2.3 Consumo de servicios ............................................................................................................ 6
2.4 Servicios web ............................................................................................................................. 6
2.5 XML ............................................................................................................................................... 7
2.6 SOAP............................................................................................................................................. 7
2.7 WSDL ............................................................................................................................................ 8
2.8 Modelado de servicios con SOMF (Service Oriented Modeling Framework) .... 8
2.8.1 Análisis orientado a servicios ....................................................................................... 9
2.8.2 Integración de negocios orientada a servicios .................................................... 12
2.8.3 Diseño orientado a servicios ...................................................................................... 17
2.9 RUP (Rational Unified Process) ......................................................................................... 23
2.9.1 Modelado de negocios ................................................................................................ 24
2.9.2 Requerimientos ............................................................................................................... 25
2.9.3 Análisis y diseño ............................................................................................................. 26
2.10 Modelado de datos con UML ......................................................................................... 26
2.11 Conclusión.............................................................................................................................. 29
Capítulo 3 ............................................................................................................................................. 30
Análisis de requisitos ................................................................................................................... 30
3.1 Introducción......................................................................................................................... 30
3.2 Historias de usuario .......................................................................................................... 30
3.3 Conclusión ............................................................................................................................ 32
Capítulo 4 ............................................................................................................................................. 33

4. Modelado de negocios RUP de la aplicación PSM ........................................................... 33
4.1 Introducción......................................................................................................................... 33
4.2 Casos de uso de negocios .............................................................................................. 33
4.2.1 Actores del negocio....................................................................................................... 33
4.2.2 Diagramas de casos de uso ........................................................................................ 34
4.2.3 Requerimientos funcionales caso de uso ComprarPolloAlProveedor......... 35
Descripción .................................................................................................................................. 35
Pre-Condiciones ........................................................................................................................ 35
Flujo de eventos principal ...................................................................................................... 35
Flujos de eventos alternativos .............................................................................................. 35
Encadenamiento de errores .................................................................................................. 36
4.2.4 Requerimientos funcionales caso de uso VenderPollosAClientes ................ 38
Descripción .................................................................................................................................. 38
Pre-Condiciones ........................................................................................................................ 38
Flujo de eventos principal ...................................................................................................... 38
Flujo de eventos alternativos ................................................................................................ 38
Encadenamiento de errores .................................................................................................. 38
Puntos de extensión ................................................................................................................ 38
Flujos de eventos principales puntos de extensión...................................................... 38
Flujos de eventos alternativos puntos de extensión .................................................... 39
Post-Condiciones ...................................................................................................................... 39
4.2.5 Requerimientos funcionales caso de uso VenderPedidos .............................. 42
Pre-Condiciones ........................................................................................................................ 42
Flujo de eventos principal ...................................................................................................... 42
Sub-Flujo de eventos principal ............................................................................................ 42
Flujos de eventos alternativos .............................................................................................. 42
Encadenamiento de errores .................................................................................................. 42
Post-Condiciones ...................................................................................................................... 43

5. 4.2.6 Requerimientos funcionales caso de uso ObtenerInventario ........................ 45
Pre-Condiciones ........................................................................................................................ 45
Flujo de eventos principal ...................................................................................................... 45
Flujos de eventos alternativos .............................................................................................. 45
Encadenamiento de errores .................................................................................................. 45
Post-Condiciones ...................................................................................................................... 46
4.2.7 Requerimientos funcionales caso de uso RealizarGastos Pagos .................. 48
Pre-Condiciones ........................................................................................................................ 48
Flujo de eventos principal ...................................................................................................... 48
Encadenamiento de errores .................................................................................................. 48
Post-Condiciones ...................................................................................................................... 48
4.2.8 Requerimientos funcionales caso de uso ObtenerContabilidad ................... 51
Descripción .................................................................................................................................. 51
Pre-Condiciones ........................................................................................................................ 51
Flujo de eventos principal ...................................................................................................... 51
Flujo de eventos alternativos ................................................................................................ 51
Encadenamiento de errores .................................................................................................. 51
Requerimientos funcionales caso de uso de los puntos de inclusión ................... 52
Flujos de eventos principales puntos de inclusión ....................................................... 52
Flujos de eventos alternativos puntos de inclusión ..................................................... 55
Post-Condiciones ...................................................................................................................... 57
4.2.9 Diagramas de actividades con entidades .............................................................. 58
4.3 Reglas del negocio ............................................................................................................ 65
4.4 Modelado objetos de negocios.................................................................................... 68
4.5 Conclusión ............................................................................................................................ 69
Capítulo 5 ............................................................................................................................................. 70
5.1 Introducción......................................................................................................................... 70
5.2 Descripción .......................................................................................................................... 70

6. 5.3 Análisis y diseño de la aplicación PSM ...................................................................... 71
5.4 Diseño de la base de datos para la aplicación PSM ............................................ 72
5.5 Conclusión ............................................................................................................................ 73
Capítulo 6 ............................................................................................................................................. 74
SOMF ................................................................................................................................................. 74
6.1 Introducción......................................................................................................................... 74
6.2 Análisis SOMF de la aplicación PSM ........................................................................... 74
6.3 Integración de negocios SOMF de la aplicación PSM. ......................................... 76
6.4 Relación del diseño lógico orientado a servicios de la aplicación PSM ...... 77
6.5 Diseño lógico de la composición orientada a servicios ....................................... 78
6.6 Diagrama de transacción orientado a servicios de la aplicación PSM ........... 79
6.7 Conclusión ............................................................................................................................ 80
Capítulo 7 ............................................................................................................................................. 81
Implementación ............................................................................................................................. 81
7.1 Pantalla autentificación de la aplicación PSM ......................................................... 81
7.2 Pantalla principal dueño de la aplicación PSM ....................................................... 82
7.3 Registrar embarque .......................................................................................................... 83
7.4 Registrar pago de embarque ........................................................................................ 84
7.5 Consultar compras ............................................................................................................ 85
7.6 Pantalla ventas .................................................................................................................... 86
7.7 Pantalla menudeo .............................................................................................................. 87
7.8 Pantalla registro mayoreo .............................................................................................. 88
7.9 Pantalla de pedidos .......................................................................................................... 89
7.10 Pantalla registro pedidos PSM ................................................................................... 90
7.11 Pantalla finalizar pedido ............................................................................................... 90
7.12 Pantalla gastos ................................................................................................................. 91
7.13 Pantalla registro gastos ................................................................................................. 91
7.14 Pantalla inventario PSM ................................................................................................ 92

7. 7.15 Pantalla registro inventario .......................................................................................... 93
7.16 Pantalla bonificaciones .................................................................................................. 94
7.17 Pantalla contabilidad...................................................................................................... 94
7.18 Pantalla principal del trabajador ................................................................................ 95
7.19 Pantalla pedidos del trabajador ................................................................................. 96
7.20 Pantalla registro pedidos del trabajador ................................................................ 97
7.21 Pantalla finalizar pedidos del trabajador ................................................................ 98
7.22 Pantalla gastos pagos del trabajador ..................................................................... 98
7.23 Pantalla registrar gastos .............................................................................................. 99
7.24 WSDL .................................................................................................................................100
Capítulo 8 ...........................................................................................................................................101
Pruebas y resultados ..................................................................................................................101
8.1 Descripción ........................................................................................................................101
8.2 Pruebas ................................................................................................................................101
Capítulo 9 ...........................................................................................................................................121
Conclusión .....................................................................................................................................121
Bibliografía .........................................................................................................................................123
Apéndice A ....................................................................................................................................126
Imágenes del prototipo de la interfaz de usuario.......................................................126
Pantallas de navegación principal ....................................................................................126
Compras .....................................................................................................................................127
Registrar compras ...................................................................................................................127
Registrar pagos compras .....................................................................................................128
Consultar embarques ............................................................................................................128
Contabilidad .............................................................................................................................129
Gastos..........................................................................................................................................129
Mayoreo .....................................................................................................................................130
Menudeo ....................................................................................................................................130

8. Pedidos .......................................................................................................................................131
Ventas .........................................................................................................................................132
Apéndice B.....................................................................................................................................133
WSDL ...........................................................................................................................................133
7.25 Compras WSDL ..............................................................................................................133
7.26 Ventas WSDL...................................................................................................................136
7.27 Pedidos WSDL ................................................................................................................139
7.28 Descuentos WSDL .........................................................................................................142
7.29 GastosPagos WSDL.......................................................................................................145
7.30 Inventario WSDL ............................................................................................................147
7.31 Bonificaciones WSDL....................................................................................................148
7.32 Contabilidad WSDL .......................................................................................................150

9. Agradecimientos
Quiero agradecer de antemano a Dios por darme la oportunidad de tener a
una excelente familia, amigos y maestros. Por compartir grandes
experiencias en la vida, tener momentos buenos, momentos malos, y
momentos muy malos, es por ello que le doy gracias a Dios por darme el
aliento y la fuerza de voluntad para seguir adelante. Así como también le
doy las gracias a mi familia de todo corazón por que con su confianza,
esfuerzo y sacrificio me dieron motivos por los cuales poder seguir
trabajando. En especial a mi padre por esos sabios consejos y ejemplos de su
gran vida para poder sobresalir, y para nunca cruzar los brazos en eso
momentos críticos de la vida. Les estoy también muy agradecido a los
profesores y amigos como lo son el Dr. García Juárez que me ayudo a
confiar en mi y me demostró que es mi amigo ya que esta en las buenas y
en las malas, dándome consejos y motivaciones, la Doctora Sandoval Solís
quien me dio una gran lección de vida al decirme que confiera en mi, el Dr.
Abraham Sánchez López por sus enseñanzas y consejos, Colmenares
Guillen, Dr. Manuel Martin, a los Maestros Anzures García y Melisa
Contreras Gonzales por ser mis sinodales y maestros, también por sus
enseñanzas, a los maestros De la Rosa Flores, Camarillo Martínez,
Palomino Jiménez, Zamora Lima y a muchos otros profesores. Así como
también a mis amigos Pablo Camarillo, Luis IbargÜen, Vélez Bello, Romero
Rincón, Sergio Olivos, Alexander Arriaga y a muchos otros amigos que
me faltaron mencionar. De todo corazón estoy muy agradecido con todos
ellos porque han sido parte de mi vida universitaria, no me queda otra cosa
más que darles las gracias por su ayuda y confianza.

10. Resumen
El proyecto está enfocado hacia la administración de la venta y compra de pollo,
teniendo en cuenta que se desea tener un sistema el cual pueda llevar el control de
las ventas y compras de pollo, costos por viajes, embarques, balance general con
descripción de ventas, pedidos, fechas de embarque.
El concepto de software como servicio, es una visión que nos permite ofrecer
soporte a las necesidades de un mercado de software muy competitivo. Gracias a la
interoperabilidad de los servicios web.
A lo largo de este trabajo nos centraremos: En el estudio del problema del sistema
PSM (Pollería San Manuel). Aplicando la metodología RUP (Rational Unified
Process). Esto con lleva a realizar las siguientes actividades:
 Modelado de negocios
 Requerimientos
 Análisis y diseño
 Implementación
 Pruebas
En base al modelado de negocios, se pueden obtener los requerimientos
funcionales. De esta manera identificamos los servicios de la aplicación PSM. Para
modelar los servicios web, se deben realizar las siguientes disciplinas del modelado
SOMF (Service-Oriented Modeling Framework).
 Modelado de análisis orientado a servicios.
 Modelado de integración de Negocios.
 Modelado de diseñó.

11. Capítulo 1
Contribución del trabajo de tesis
La Arquitectura Orientada a Servicios (SOA), surge gracias a la necesidad de
resolver las complejidades del mercado, con respecto al tiempo y a la calidad del
software. SOA considera que una aplicación está compuesta por un conjunto de
servicios autónomos.
En términos generales, SOA es un estilo arquitectónico cuyo objetivo es lograr un
acoplamiento libre entre los servicios web interactuantes. Permitiendo la creación
de sistemas altamente escalables y a su vez brinda una forma estándar de
exposición e invocación de servicios, lo cual facilita la interacción entre diferentes
sistemas propios o de terceros. SOA es un conjunto de servicios, estos servicios se
comunican entre sí [11]. La comunicación puede implicar pasar datos simples o
podría implicar la coordinación de dos o más servicios de algunas actividades.
SOA permite separar funciones en distintas unidades o servicios que los
desarrolladores hacen accesibles dentro de una red, con el fin de que los usuarios
puedan combinarlas y reutilizarlas en la producción de aplicaciones. Estos servicios
se comunican entre sí pasando información de un servicio a otro o coordinando
actividades entre dos o más servicios.
 Al igual que los objetos y componentes, un servicio es un elemento
fundamental que:
1. Combina la información y el comportamiento.
2. Oculta el funcionamiento interno de la intrusión externa.
3. Presenta una interfaz relativamente simple para el resto del
organismo.
Los servicios pueden ser publicados y consumidos, solos o como jerarquías y o
colaboraciones. SOA contribuye también a documentar el modelo de negocios de
la empresa y a utilizar el modelo de negocios documentado para integrar en él y
dar respuesta a los cambios dinámicos optimizando los recursos que se produzcan
entre ellos.
1

12. Retos de SOA:
 La capacitación en una nueva tecnología, adquisición de la misma y el punto
más importante de todos: SOA puede representar un cambio de paradigma
para los desarrolladores, por lo que es necesario la capacitación del
personal.
 El rediseño de los procesos de negocio para lograr un rendimiento óptimo.
 El identificar los problemas potenciales que llegan a surgir y de cómo
solucionarlos lo antes posible en el ciclo de implementación.
Imaginemos que requerimos una aplicación para llevar la administración de un
negocio. ¿Cuál sería el primer punto a considerar? El primer punto a considerar en
esta tesis es el uso de una metodología compatible con el modelado de servicios.
Es por ello que se utiliza la metodología RUP que como sabemos sirve para
modelar los negocios.
En el Capítulo 2 se representa el estado del arte de esta tesis. Es decir la
descripción del modelado de negocios, análisis y diseño con RUP, modelado de
servicios con SOMF, XML, Servicios Web y el modelado de datos con UML.
En el capítulo 3 se muestra el análisis de requisitos de la aplicación para la PSM. En
el capítulo 4 se detalla el modelado de negocios, así como sus artefactos de la
aplicación Pollería San Manuel (PSM). Después del modelado de negocios se
describen los requerimientos y se realiza la interfaz del usuario.
El capítulo 5 explica el modelado de análisis y diseño, es decir se identifican las
clases, y el modelado de la base de datos mapeando clases a tablas con UML.
¿Pero en qué momento se empiezan a modelar los servicios? Una vez realizado
todo el modelado de negocios y la especificación de requerimientos, se toma
como punto de partida los requerimientos funcionales. Con los requerimientos
funcionales se identifican los servicios. En el capítulo 6 se explica el ciclo de vida del
modelado orientado a Servicios de la metodología SOMF (Service Oriented
Modeling Framework). Conformado por el modelo de análisis, integración de
negocios y diseño. En el capítulo 7 se muestra la implementación de la aplicación
PSM orientada a Servicios y los WSDL, en el capitulo 8 se muestran las pruebas y
resultados realizados de la aplicación PSM. En el capítulo 9 se muestran las
conclusiones de esta tesis.
2

13. Capítulo 2
Estado del arte
2.1 Introducción
El estado del arte está conformado por la explicación de los modelos aplicados en
esta tesis. Es decir: modelado de negocios, requerimientos, análisis y diseño
con RUP, modelado de servicios con SOMF y el modelado de datos con UML.
2.2 SOA
La Arquitectura Orientada a Servicios (SOA), es un concepto de arquitectura de
software que define la utilización de servicios para dar soporte a los requisitos del
negocio. Permite además, la creación de sistemas de información altamente
escalables que reflejan el negocio de la organización, y que a su vez brindan de
una forma bien definida la exposición e invocación de servicios (de forma común,
pero no exclusiva de los servicios web), lo cual facilita la interacción entre
diferentes sistemas propios o de terceros [17].
SOA proporciona una metodología y un marco de trabajo para documentar las
capacidades de negocio y puede dar soporte a las actividades de integración y
consolidación.
Los conceptos de software futurista probablemente contribuirán a otra capa de los
entornos computacionales complejos, un demandante de recursos para el apoyo
de presupuestos. La arquitectura orientada a servicios (SOA) ayuda a resolver los
problemas de la interoperabilidad, reutilización, y otros problemas asociados con
este paradigma. La visión de SOA también se ocupa de los retos de software
fuertemente acoplados y clama por una arquitectura que se basa en el
acoplamiento de los “assets”.
SOA ayuda a la reducción del tiempo de salida al mercado y la agilidad del
negocio. De hecho, la lista de ventajas sigue creciendo. El modelado orientado a
los servicios proporciona mecanismos que nos permitan concebir productos de
software que hemos ido construyendo, adquiriendo, y a la integración en las
últimas décadas como un servicio orientado a componentes. Es importante que
3

14. deban de ser tratadas por igual la parte de análisis, diseño, arquitectura y deben
ser reconocidos como servicios [16].
El modelado orientado a servicios es una práctica de desarrollo de software que
utiliza las disciplinas de modelado y el lenguaje UML para ofrecer soluciones
estratégicas y tácticas a los problemas de la empresa. Este paradigma de modelado
es una visión integral del análisis, diseño y arquitectura de software de todas las
entidades de la organización, concebirlos como un servicio orientado a los “assets”
[16].
SOA ofrece la posibilidad de llamar a un componente de negocios desarrollado en
una plataforma X, desde una aplicación corriendo en cualquier plataforma, en
cualquier parte del mundo, utilizando para ello protocolos estándar como SOAP,
XML y HTTP [17].
La programación orientada a servicios es un complemento de la programación
orientada a objetos e implementa mejoras a esta última, producto de la experiencia
acumulada en la última década, sobre todo en las áreas de la computación
distribuida, instalación de una solución e interoperabilidad entre sistemas [18].
SOA, a diferencia de las arquitecturas de objetos distribuidos como J2EE, refleja
más fielmente los procesos y relaciones del mundo real; es decir, SOA representa
una manera más simple y natural de modelar y construir software que soluciona
problemáticas de negocios del mundo real [18].
Los sistemas orientados a servicios, son diseñados con un bajo nivel de
acoplamiento que facilita la implementación de cambios y estos servicios pueden
ser desarrollados en cualquier lenguaje corriendo en diferentes plataformas.
Desde el punto de vista de un usuario, la diferencia entre utilizar servicios y utilizar
componentes tradicionales es imperceptible. Desde el punto de vista
arquitectónico, en cambio, podemos decir que los servicios a diferencia de los
componentes son autónomos, encapsulan sus propios datos de la aplicación. Estos
servicios pueden ser generados por distintos equipos de desarrollo, en diferentes
tiempos, plataformas y espacios; es decir, que una aplicación puede ir creciendo y
aumentando su funcionalidad a medida que se construyan nuevos servicios que no
necesariamente deben estar bajo el control del equipo de desarrollo de la
aplicación, por lo que es esencial que entre nuestras aplicaciones y los servicios
que ellas consumen, sean débilmente acopladas.
4

15. Los servicios son utilizados por una aplicación cliente que les envía mensajes
respetando un determinado contrato de servicios, pero internamente esos servicios
utilizan los conceptos de la Programación Orientada a Objetos (OOP) [18].
SOA tiene dos partes clave: servicio y arquitectura. El servicio es esencialmente la
vista hacia el exterior de las aplicaciones dentro de la organización TI (tecnologías
de la información), donde cada aplicación proporciona los "servicios empresariales"
necesarios para el acceso de otras aplicaciones. La "arquitectura" es el enfoque de
toda la organización para "utilizar" los servicios. Ya que hay múltiples aplicaciones y
soluciones dentro de la organización, tiene que existir una decisión de como
proveer un espacio de aplicación y solución que abarca múltiples aplicaciones.
Para ello utilizan los servicios expuestos por cada aplicación, y para la
estandarización mediante una infraestructura proporcionar y consumir estos
servicios, y los servicios que se consumen a través de un proceso basado en
frameworks, todo estaría compuesto por SOA "arquitectura", se muestra en la
siguiente figura 2.1, los componentes de la arquitectura SOA [17].
Figura 2.1 Componentes de la arquitectura SOA.
5

16. 2.3 Consumo de servicios
¿Una vez que los servicios están disponibles en la plataforma SOA, que se hace
con ellos?
Existen 2 escenarios de uso clave:
1. Consumir los servicios desde una aplicación cliente. Al consumir, nos
referimos a utilizar el servicio, es decir invocar el servicio en cualquier otra
aplicación.
2. Composición de los servicios en los procesos de negocio. El otro método
más popular para el uso de los servicios es en los procesos de negocio, por
la orquestación de los servicios. Esto consiste esencialmente en la
orquestación "encadenar" los servicios disponibles en el dominio para llevar
a cabo una función de negocios o procesos. Este es un enfoque de
programación relativamente de alto nivel, sus construcciones de flujo
de programación pueden definir gráficamente el proceso, tanto como el
dibujo de un diagrama de flujo o un diagrama de actividad con UML.
2.4 Servicios web
Los Servicios web son una innovación en tecnología de la World Wide Web. Un
servicio web es un programa de aplicación basado en la web con una interfaz
definida que acepta y procesa las solicitudes y devuelve una respuesta al
solicitante. Un servicio web no está directamente ligado a una aplicación específica.
En algunos aspectos, un servicio web es similar a un modelo cliente-servidor,
donde el servicio web es un servidor [18]. Los servicios web se basan en un
conjunto de estándares de comunicación, como son XML para la representación de
datos, SOAP (Simple Object Access Protocol) para el intercambio de datos y el
lenguaje WSDL (Web Services Description Language) para describir las
funcionalidades de un servicio web [18].
6

17. 2.5 XML
eXtensible Markup Language (XML) recientemente ha ganado mucha notoriedad
como una solución tecnológica para el intercambio de mensajes. Se puede utilizar
con ventaja para muchos tipos de aplicaciones tales como el movimiento de datos
entre los sistemas de negocio o describir una transacción de negocios, una
solicitud para persistir o almacenar datos en una base de datos, o una solicitud de
servicio.
XML es un fenómeno relativamente reciente (cerca de 1997) [19], pero estable, la
tecnología, XML es en realidad una forma de metadatos descriptivos. Por sí solo,
XML es una sintaxis para la aplicación de los contenedores de datos descriptivos de
un documento, transacción o mensaje. Los esquemas para ampliar las capacidades
de los metadatos XML, se efectúa mediante la definición de reglas y restricciones
de las características de los datos, tales como la estructura, las relaciones, los
valores permitidos, y los tipos de datos. Cuando la información empresarial está
contenida en un documento XML o de la transacción y se comparte con otros
sistemas empresariales o, posiblemente, con los socios externos de la empresa,
podemos ver rápidamente la necesidad de aplicar prácticas eficaces de la
arquitectura de datos.
En muchos casos, XML se utiliza para describir el contenido de un documento
sencillo. Sin embargo, las transacciones y datos de los mensajes orientados a
servicios ayudan a ofrecer oportunidades, aún mayores para las aplicaciones con
XML. También es importante XML para describir el contenido de datos y esquemas,
que incluye las reglas granulares de metadatos que se aplican a un documento de
referencia a XML. Hay varios tipos de esquemas que se pueden utilizar con XML.
2.6 SOAP
SOAP (Simple Object Access Protocol) proporciona un mecanismo para el
intercambio de información estructurada en un entorno descentralizado y
distribuido usando XML. SOAP no define en sí mismo ninguna semántica de la
aplicación como un modelo de programación, sino que define un mecanismo
simple para expresar la semántica de aplicaciones, proporcionando un modelo de
paquetes y los mecanismos de codificación dentro de los módulos de datos. Esto
permite a SOAP, ser utilizado en una gran variedad de sistemas que van desde
7

18. sistemas de mensajes a RPC (Remote Procedure Call, Llamada a Procedimiento
Remoto) [17].
SOAP consta de tres partes:
 La envolvente SOAP define la construcción de un marco general para
expresar lo que está en un mensaje, que debe lidiar con él, y si es opcional u
obligatorio.
 Las reglas de codificación SOAP, define un mecanismo de serialización que
puede ser utilizado para el intercambio de ejemplos de tipos de datos
definidos por la aplicación.
 La representación SOAP RPC, define una convención que se puede utilizar
para representar llamadas a procedimientos remotos y respuestas.
2.7 WSDL
WSDL (Web Services Description Language), es el idioma más común de describir
los servicios [19]. WSDL está escrito como un documento XML. WSDL tiene dos
Partes fundamentales:
 Interfaz: la lista de operaciones en el servicio y el contrato de cada operación
El contrato incluye la descripción del número y tipo de entrada y salida de la
operación.
 Bindings: los detalles específicos en donde el servicio se encuentra y el
protocolo para acceder al servicio.
2.8 Modelado de servicios con SOMF (Service Oriented Modeling Framework)
Es un modelo impulsado por una metodología moderna de la ingeniería cuya
disciplina específica de lenguaje de modelado y las mejores prácticas se centran en
el diseño de software en la arquitectura de distintas actividades, empleadas
durante diferentes etapas del ciclo de desarrollo de software. Por otra parte, los
arquitectos, analistas, modeladores, desarrolladores y administradores de SOMF lo
emplean para hacer frente a la arquitectura empresarial, arquitectura de
aplicaciones, arquitectura orientada a servicios (SOA), y los desafíos de la
8

19. computación en la nube para la organización. El marco, escrito por Michael Bell,
proporciona una notación independiente de la tecnología que fomenta una visión
integral de las entidades de software empresarial [16].
 Modelo de análisis orientado a servicios
 Modelo de integración de negocios orientada a servicios
 Modelo de diseño lógico orientada a servicios
2.8.1 Análisis orientado a servicios
Un servicio se clasifica por sus atributos contextuales y estructurales:
 Atomicidad del servicio: un componente de software indivisible que es
muy granular y ejecuta menos funciones técnicas del negocio. Una
formación atómica es también una pieza de software que normalmente no
está sujeta a las actividades de análisis de descomposición y sus negocios
o funcionalidad tecnológica, no justifica la ruptura de componentes más
pequeños.
 Composición del servicio: un servicio compuesto, agrega estructuras más
pequeñas y servicios de grano fino. Esta formación se caracteriza por el
servicio jerárquico conocido como de grano grueso, entidad que abarca más
los procesos de negocio o técnicos. Un servicio compuesto puede agregar
servicios atómicos o de otros tipos.
 Clúster de servicios: se trata de un conjunto de servicios distribuidos y
relacionados que se han reunido a causa de su relación comercial o
tecnológica común. Un grupo de servicios a los afiliados de los servicios
y combina su oferta para resolver un problema de negocio. Una estructura
de grupos puede agregar formaciones atómicas, así como compuestos.
 Nube de servicios: un conjunto de servicios que se entregan mediante una
aplicación computacional en la nube.
La imagen 2.2 muestra los elementos de la notación del Análisis SOMF [16]:
Figura 2.2 Análisis SOMF
9

20. Análisis de operaciones (Notaciones de las operaciones)
Existen los siguientes símbolos de operaciones que pueden ser utilizados para
representar una propuesta de solución en un diagrama de análisis de servicios.
Estos iconos muestran las actividades que han ocurrido, describen el proceso por el
cual los servicios se transforman para hacer frente al dominio del problema. Por
ejemplo, "agregados" se refiere al estado actual de un servicio que ha sido
conformado por una operación de análisis de agregación. Otro ejemplo, el símbolo
"unificado", que identifica una condición por la cual dos servicios fusionaron sus
operaciones. Por lo tanto, la notación propuesta profundiza en las actividades de
análisis que se llevaron a cabo y describe el estado actual de los servicios y su
contribución a la solución global.
Cada símbolo también se describe en la lista siguiente:
 Agregación: Muestra de contención de los servicios de la composición de
Servicios o Clúster.
 Resta: se retira un servicio
 Unificación: Se une a los servicios mediante la creación de un nuevo servicio.
 Descomposición: Separa un servicio de la matriz que lo contenía. Creando
un servicio más amplio “compuesto”. A diferencia de la resta de los servicios,
los activos descompuestos siguen siendo valiosos para la organización y los
ambientes en los que se operan.
 Intersección: Intersección de dos o más grupos de servicios
 Superponen: Identifica la región de superposición entre dos o más grupos
de servicios
 Transformación: Convierte una estructura de servicio a otra formación (es
decir, desde atomicidad de servicios a composición de servicios, etc.).
 Comentarios: Un lugar para poner comentarios al lado de cada activo u
operación.
En la figura 2.3 se muestran los pictogramas de las actividades que representan el
proceso de análisis de servicios [16].
10

21. Figura 2.3 Análisis de operaciones SOMF
Análisis contextual de las operaciones SOMF:
 Generalizar: Aumenta el nivel de servicio de la abstracción y se amplia la
oferta de servicios.
 Especificar: Disminuye el nivel de abstracción del servicio y los límites de las
ofertas de los servicios.
 Contratación: Restringe las operaciones de servicio en el entorno distribuido.
 Expandir: Amplía las operaciones de servicio en un entorno distribuido.
En la figura 2.4 se muestra la notación del análisis contextual de las operaciones
SOMF [16].
11

22. Figura 2.4 Análisis contextual de las operaciones SOMF
2.8.2 Integración de negocios orientada a servicios
Se debe utilizar una notación de la Integración de negocios orientada a servicios.
Es decir un conjunto formal de símbolos que ofrece un lenguaje de integración.
Estos iconos describen los assets del negocio que participan en la integración y
representan una serie de operaciones que se pueden utilizar para describir la
integración de Negocios. En la figura 2.5 se muestran los elementos de la
integración de Negocios [16].
Figura 2.5 Notación de la integración de negocios orientado a servicios
12

23. Notación de la integración de operaciones
Hay seis símbolos de integración que deben ser empleados para describir una
iniciativa empresarial orientada a los servicios de integración. Estas actividades
deben ser representadas en un esquema de integración. También es imprescindible
para identificar los pasos y los diferentes procesos por los cuales se llego a la
propuesta de integración final de los casos. Por lo tanto, este esquema debe
registrar el estado actual o futuro de la integración orientada a servicios. En la
figura 2.6 se muestra la integración de operaciones [16].
Figura 2.6 Integración de operaciones
Se deben considerar los símbolos de integración después de la operación, que
pueden facilitar esta documentación.
 Integración. Este símbolo identifica una actividad de integración que ha
llevado a cabo entre un servicio y una estructura de dominio o entre un
servicio y una perspectiva contextual.
 Desintegración. Las actividades de integración también se pueden invertir,
es decir, un servicio puede ser retirado de un entorno de dominio por
razones estratégicas o tácticas. Por lo tanto, el símbolo identifica como una
reversión de las actividades para preservar el proceso por el que la
integración se ha producido.
13

24.  Contenido. La actividad de contención tiene lugar entre los dominios para
formar un dominio estructurado jerárquico de capas. Este símbolo también
puede ser utilizado para incluir un dominio en una capa del negocio. Esto es
similar al símbolo de la agregación de servicios. Sin embargo, aquí los
elementos estructurales de negocios están conectados.
 Separados. Este símbolo se utiliza para la separación de una capa de
dominio de una estructura jerárquica, la formación de capas de dominio, o
para quitar un dominio de su negocio que abarca ciertos niveles.
 Perspectivas. Este icono identifica una perspectiva de la arquitectura
empresarial contextual que se asocia a un dominio de negocio.
 Comentario. Se utiliza este icono para describir las acciones de integración o
un ámbito empresarial que requieren notas para ahondar en el estado de
integración.
Notación formal de la relación lógica del servicio
Notación de la relación lógica. Consta de cuatro conectores que hacen posible
transmitir una relación aparente o implícita entre los assets de software orientada a
servicios, tales como servicios, e incluso los consumidores. Estos símbolos se
utilizan para ilustrar las rutas de mensajes de datos intercambiados y la información
sobre una red como se muestra en la figura 2.7 [16].
Figura 2.7 Relación lógica del servicio
La forma general de un conector de relación de servicio es una línea que indica la
dirección e identifica la visibilidad de los servicios.
14

25. Hay dos categorías de los conectores de relación de servicios.
1. Relación aparente: Esto denota una relación visible entre dos servicios o
entre un servicio y el consumidor. El término "aparente", describe una ruta
del mensaje que vincula directamente las entidades, con la información
contenida y que establece la comunicación entre 2 partes, sin hacer uso de
intermediarios o servicios de mediación.
2. Relación implícita: Este grupo muestra en un icono la relación de servicio
invisible. La relación pertenece oculta a las asociaciones indirectas que
emplean los agentes para el mensaje de entrega. Por lo tanto, una relación
de servicio implícita se forma cuando los intermediarios, los proxis de
servicios, o centros de servicios se encuentran entre los consumidores y
servicios o entre los servicios.
La dirección de paso de mensajes es también un aspecto importante de esta
notación. Hay dos tipos de direcciones de enrutamiento de mensajes a tener
en cuenta:
1. Relación unidireccional. Una relación de servicio unidireccional identifica un
solo sentido de ese mensaje, los mensajes se entregan en una sola
dirección. No hay respuesta necesaria. Este tipo de actividad se produce
normalmente cuando las partes involucradas en el intercambio de
mensajes desea reducir al mínimo el tráfico de red o simplemente porque
un mensaje de respuesta no es necesario.
2. Relación bidireccional. Este método de entrega de mensajes denota una
conversación típica bidireccional entre un consumidor y un servicio, o entre
dos servicios. Esto es similar a los protocolos comunes de comunicación
petición/ respuesta. El ultimo emisor siempre espera una respuesta.
Por último, puede utilizarse el icono de comentario, que ayuda a explicar la relación
de la naturaleza del servicio.
15

26. Roles en el contexto de diseño orientado a servicios
El paradigma orientado a servicios presenta tres funciones principales que pueden
envolverse en las decisiones de diseño en términos de enrutamiento de mensajes,
la visibilidad, la sincronización de mensajes, y la colaboración de los servicios.
Los roles de servicio en una disciplina de diseño orientado al servicio no sólo debe
ser coherente, sino que debe estar ligado a un contrato que se establece por
encima de cualquier utilización de los servicios.
Rol de los consumidores
Un cliente es una entidad de software orientada al servicio que está diseñada para
adquirir los servicios. Es decir, normalmente las implementaciones de software que
no proporcionan servicios en sí mismos. Pero en las soluciones de diseño complejo,
el papel de un consumidor que también se puede aplicar a un servicio.
En el contexto de diseño orientado a servicios, un consumidor puede comunicarse
con uno o más servicios. También se puede mantener una relación implícita o apa-
rente, unidireccional o bidireccional con sus correspondientes servicios.
El permiso para acceder a un servicio particular debe ser otorgado en un contrato
vinculante que puede dar el seguimiento y cumplimiento en tiempo de
ejecución. Los consumidores también deben comprometerse al servicio de
consumo con ciertos límites y restricciones de disponibilidad del servicio. El
consumo es generalmente medido por el volumen de mensajes intercambiados y
la frecuencia de la información conforme a lo acordado en el contrato. La
disponibilidad, en el servicio, por otra parte, tiene restricciones en el tiempo de
acceso impuestas a un consumidor.
Rol de servicio
Un servicio es una entidad que se compromete a su oferta a través de un contrato
vinculante a sus consumidores suscritos. Este acuerdo estipula por lo general lo
que está presente en la disponibilidad de un servicio, las tasas de consumo, y el
tiempo de respuesta. Además, los servicios pueden mantener una implícita relación
16

27. ya sea unidireccional y bidireccional con los correspondientes consumidores y
servicios.
Como se mencionó anteriormente en la sección de rol del consumidor, un servicio
también puede actuar como un consumidor. Imaginemos un servicio que no sólo
está obligado a servir a su comunidad de consumo, sino también tiene la
obligación de intercambiar mensajes con los servicios.
Rol del intermediario
Cualquier software orientado a servicios se encuentra entre los consumidores para
facilitar la comunicación es considerado como un intermediario.
2.8.3 Diseño orientado a servicios
Es más que una formación, una forma visual, un paquete de software que suele ser
moldeada por patrones predefinidos, se compone de software orientado a servicios
que se utilizan para comunicar una solución del problema que se plantee. Esto no
es sólo un método táctico para proporcionar una solución a una preocupación de
la organización, sino también un plan estratégico para resolver problemas
similares en el futuro. La composición del diseño es el resultado de tres aspectos
importantes que contribuyen: asociaciones de servicio, las rutas de intercambio de
mensajes, y los patrones generales de los servicios que ofrecen una solución. Ahora
cada uno de estos contribuyentes se inspecciona para llevar a una mejor
comprensión de la esencia de este esfuerzo de embalaje orientada a servicios.
Asociaciones de servicio
Durante el ciclo de vida orientado a servicios, se encontraron dos tipos de
relaciones de servicio: conceptual y lógico. Estas categorías de asociación de
servicios influyen en la construcción de una composición de servicios: En primer
lugar, en la fase de la conceptualización de servicios, comúnmente los servicios y
las diferencias se identifican en forma de negocio o vínculos tecnológicos entre los
servicios que participan en una solución, los cuales son conocidos como
17

28. afiliaciones conceptuales. En segundo lugar, más adelante en la fase de diseño de
servicios, las relaciones lógicas fueron descubiertas entre los servicios que son
impulsados por la distribución de mensajes y las necesidades de cambio.
Rutas de intercambio de mensajes
Las relaciones de servicio afectan a las decisiones del diseño de entrega de
mensajes. Estas asociaciones de identificar los requisitos permiten establecer las
mejores rutas de mensaje para transacciones eficientes. Una ruta de mensajes se
refiere a las rutas de red que permiten que la información se intercambie entre los
consumidores y servicios. Por lo tanto, una composición de diseño está
influenciada por las relaciones de servicio y formada por las rutas de intercambio
de mensajes y comportamiento en servicio que fueron concebidas antes en la fase
de diseño lógico de la relación orientada a servicios.
Patrones de formación dirigida por estilos
El diseño de la composición orientada a servicios es la construcción de las
formaciones por posicionamiento de servicios en ciertas formas, nombradas
estilos, para proporcionar soluciones. Estos acuerdos forman patrones visuales que
ayudan a permitir un eficiente enrutamiento de mensajes y la ejecución de la
transacción. Las formaciones de servicio que se descubrieron también son
consideradas como soluciones empaquetadas en las que se comunican las
estrategias empleadas para resolver las preocupaciones de la organización.
Diseño de la composición orientada a servicios
Para ofrecer soluciones efectivas a los planos de diseño orientado a servicios, se
proponen una serie de composiciones. Un estilo de composición de diseño es
simplemente un patrón. Es similar a una plantilla que puede servir de guía a la
vinculación de las estructuras de la atomicidad, composición y clúster de servicios
para comunicar los tipos de problemas que pueden ayudar a resolver y ayudar a
forjar las estrategias de diseño, tales como la reutilización de servicios y la
interoperabilidad. Sus nombres son los estilos, ya que forman a la composición de
la entrega del diseño. En pocas palabras, una composición de diseño orientada a
servicios no sólo comunica una solución, sino que también proporciona una
estrategia que se puede aprovechar en el futuro.
18

29. Las cuatro principales asociaciones conceptuales de los tipos de servicios son:
circular, jerárquica, malla y estrella.
El estilo de la asociación como circular se utiliza para describir una composición
de diseño circular, se muestra en la figura 2.8. De la misma manera, en las
asociaciones de tipo jerárquica, malla y estrella de la red se emplean el diseño de
la composición para describir una red [16].
Figura 2.8 Asociaciones de la composición orientada a servicios
Estilo de la composición del diseño circular
El estilo de diseño de la composición circular representa una secuencia de eventos,
cada uno de los cuales está representado por un único servicio en una serie.
Imaginemos que un número de los servicios están vinculados por algún negocio
o asociación tecnológica. El mensaje está en las manos del creador del servicio en
el primer mensaje para el próximo servicio que reciben. Posteriormente a la
entrega de mensajes siempre participa el próximo servicio. Cuando esta operación
se ha completado, el mensaje resultante llega de retorno al punto de partida.
El estilo de composición circular reduce el tráfico de red, evitando intermediarios
innecesarios. En cambio, los mensajes se entregan de un servicio a otro hasta que
la respuesta se entrega al autor del mensaje. La entrega de mensajes implica una
serie de servicios que comparten la carga de procesamiento de transacciones, en
lugar de aplicar la tensión a un único servicio. El estilo de la composición del
diseño circular es adecuada para la gestión de negocios y tecnologías, procesos a
través de la participación de las partes interesadas directamente sin la
intervención de intermediarios.
19

30. Estilo de la composición del diseño jerárquico
La asociación jerárquica conceptual del servicio ayuda al proceso a descubrir
conceptos e ideas para la asociación de sus atributos comunes. También se
muestra la necesidad de identificar la reutilización de clúster de servicios. Para
poder abordar el aspecto de consumo de los servicios, incluso antes de que
sean transportados a su producción. El análisis suele facilitar la estructura de las
asociaciones jerárquicas de las capas del servicio.
Estilo de la composición del diseño malla
Con demasiada frecuencia, los profesionales se enfrentan al tiempo de diseño y al
tiempo de ejecución de los desafíos ambientales que requieren la colaboración de
una planificación del servicio y en la integración del servicio. Estas dificultades
surgen debido a la interoperabilidad creciente en el entorno computacional
teniendo así complejidades, los sistemas operativos y las plataformas múltiples que
emplean las organizaciones.
El estilo de la composición del diseño Malla se puede utilizar para obtener la
siguiente lógica de las ventajas del diseño:
 Aliviar el negocio y los desafíos tecnológicos de interoperabilidad.
 Las líneas de negocios y puente de dominio superan las barreras
geográficas, ya que permiten la simplificación de las complejas estructuras
de distribución de negocios, y facilitan la gestión del control sobre
federados y no federados de negocios.
 Aumentar la reutilización de assets.
Estilo de la composición del diseño estrella
El último estilo de diseño es la composición de estrella, que ofrece otro punto de
vista de la estrategia de diseño. Los estilos de diseño tratan de resolver los
problemas, pero también facilitan un plan de ataque, una estrategia y un mapa de
ruta para lograr los objetivos de diseño. Por lo tanto, el estilo de composición
estrella añade otro punto de vista de los planos de diseño. Se puede mejorar la
creación de un diseño del ambiente débilmente acoplados y ayudar a medir la
efectividad al dividir los ambientes en los que se elaboran.
20

31. Modelado de transacciones orientado a servicios
En [19] 1983, Theo Haerder y Andreas Reuter presentaron requisitos fundamentales
para la ejecución de las transacciones, en el trabajo de investigación “Principios de
la transacción orientada a la recuperación de las bases de datos”.
Su trabajo está centrado en cuatro grandes principios que definen una transacción
y se identificaron cuatro atributos más importantes que garantizarán el buen fin de
las actividades de operación. Estos grandes principios son por sus siglas en inglés
(ACID):
 Atomicidad
 Coherencia
 Aislamiento
 Durabilidad
Se convirtió en el estándar de la industria para la manipulación de datos fiables y la
integridad de las transacciones en un entorno multi-usuario. Haerder y Reuter,
describen una transacción como: la manera en que se componen varias
operaciones de software que interactúan con una base de datos durante un
período determinado de tiempos. No hay cambios en los datos, se debe deducir
que todas estas actividades han concluido con éxito.
Las propiedades para asegurar la integridad de los datos ACID son las siguientes:
 Atomicidad: Una transacción confirma todos los cambios aplicados a una base
de datos de su base de actividades, si sus operaciones se ejecutan con éxito. De
lo contrario, una cancelación de la operación es responsable de la restauración
de todas las modificaciones aplicadas en los datos. Esto se conoce como la
condición todo o nada.
 Coherencia: Los resultados deben estar comprometidos a ser válidos y no debe
perjudicar la integridad de los datos.
 Aislamiento: Una transacción debe ser aislada de otras transacciones que se
ejecutan simultáneamente. No deben interferir entre sí durante la ejecución.
 Durabilidad: Los cambios realizados por las transacciones de éxito deben ser
duraderas y persistentes, a pesar de cualquier error que se produzca después.
21

32. ACID es un método de procesamiento de transacciones estrechamente unidas. Es
decir, este enfoque fue diseñado para hacer frente a los problemas locales de
depósito y fiabilidad de las soluciones de cada acción, es decir, los resultados
exitosos de transacciones están garantizados sólo por un corto período de
tiempo. En el ambiente de computación orientado a servicios deben ser
interoperables requiere un modelo que pueda manejar la interacción y
colaboración de servicios en las estructuras complejas y agregadas. Además, se
requiere la integridad de las transacciones entre las formaciones de servicios
débilmente acoplados dispersados a lo largo de múltiples líneas de negocios y
organizaciones. Un esquema de operación orientada a servicio debe ser
encargado de resolver desafíos de las transacciones de larga duración [19].
Conectores de la actividad
Existen tres conectores de la actividad de servicios que pueden ayudar en la
descripción de la interacción y colaboración de los servicios, como se ilustra en la
figura 2.9. Se deben utilizar en cada actividad una sección para describir los
pasos de enrutamiento de mensajes entre los servicios participantes y los
consumidores [16].
Figura 2.9 Conectores de la actividad de transacción
 Conector de la actividad de origen. En una sección de actividades, pueden
identificarse una serie de asociaciones de los servicios, para realizar una
tarea determinada. Por lo tanto, se utiliza este conector para referirse a un
inicio de actividad y para ser capaz de identificar un servicio que origina un
mensaje (conocido como mensaje origen).
22

33.  Conector de la actividad de intermediación: Una actividad puede implicar
múltiples servicios y consumidores. Por lo tanto, para las operaciones de
transacción se utiliza el conector de intermediación. Esto también puede ser
útil cuando el entorno de producción cuenta con los servicios de proxy o
intermediarios orientados a servicios
 Indicador de la finalización de la actividad: Un diagrama de las transacciones
de servicios, puede contener una gran serie de finalizaciones en las
actividades de servicios, se emplea el conector para identificar el estado final
de una función determinada.
2.9 RUP (Rational Unified Process)
Es una metodología de ingeniería de software. Proporciona un enfoque disciplina-
do para la asignación de tareas y responsabilidades dentro de una organización de
desarrollo. Su objetivo es garantizar la producción de software de alta calidad que
satisfaga las necesidades de sus usuarios finales dentro de un horario predecible y
presupuestado. La figura 2.10 muestra la arquitectura general de RUP [9] de la
Aplicación PSM.
Figura 2.10 Arquitectura general RUP
RUP tiene dos dimensiones:
El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del
proceso de medida que se desarrolla. El eje vertical representa las disciplinas, de las
actividades del grupo.
La primera dimensión representa el aspecto dinámico del proceso cuando entra en
vigor, y se expresa en términos de fases, interacciones e hitos.
23

34. La segunda dimensión representa el aspecto estático del proceso: la forma en que
se describen los términos de los componentes de proceso, disciplinas, actividades,
flujos de trabajo, artefactos y roles.
El gráfico muestra cómo el énfasis varía con el tiempo. Por ejemplo, en iteraciones
tempranas, pasamos más tiempo en los requisitos, y en las iteraciones de la
aplicación.
¿Qué es una Disciplina? Una disciplina muestra todas las actividades que puede
realizar para producir un conjunto de artefactos. Se describen estas disciplinas en
una visión general de nivel, un resumen de todas las funciones, actividades y los
artefactos que están involucrados. También se muestran, en un nivel más detallado,
cómo los roles colaboran, y cómo utilizan y producen artefactos. A los pasos en
este nivel de detalle se les llama "los detalles del flujo de trabajo".
Disciplinas de RUP:
 Modelos de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
2.9.1 Modelado de negocios
Se define un modelo de negocio como las soluciones generalizadas que pueden
ser implementadas y aplicadas en una situación problemática, y con ello eliminar
uno o más de los problemas inherentes. Se compone de los artefactos:
 Casos de uso de negocios
 Reglas de negocio
 Diagramas de actividades
 Diagramas de objetos de negocio
2.9.1.1 Casos de uso de negocios
Es un modelo de las funciones de negocio previsto. Se utiliza como un insumo
esencial para identificar los roles y los resultados de la organización.
24

35. 2.9.1.2 Diagramas de actividades
Se utilizan para ilustrar las actividades. En el punto de vista externo, se utilizan
diagramas de actividades para la descripción de los procesos de negocio que
describen la funcionalidad del sistema empresarial.
Los Diagramas de actividad le permiten pensar funcionalmente. Con el enfoque
orientado a objetos. Debido a que es posible describir explícitamente los eventos
paralelos, el diagrama de actividades es muy adecuado para la ilustración de los
procesos de negocio, ya que los procesos de negocios rara vez se presentan en
una manera lineal y con frecuencia presentan paralelismos.
2.9.1.3 Reglas de negocio
Son las declaraciones de la política o las condiciones que deben cumplirse.
Diagramas de objeto de negocio
Es un modelo de objeto que describe la realización de casos de uso de negocio.
Identificando las entidades de negocios.
2.9.2 Requerimientos
Son definidos como una condición o capacidad que un sistema debe cumplir. Los
Requisitos se dividen en 2: requerimientos funcionales y requerimientos no
funcionales.
 Requerimientos funcionales: Especifican las acciones que un sistema debe
ser capaz de realizar, sin tener en cuenta las limitaciones físicas del
sistema. Estos a menudo se describen mejor en la especificación de los
casos de uso. Los requerimientos funcionales especifican la entrada y el
comportamiento de la producción de un sistema.
 Requerimientos no Funcionales: Normalmente describen el criterio de
desempeño, fiabilidad, seguridad y otros parámetros operacionales.
Prototipo de interfaz de usuario
El prototipo puede manifestarse como dibujos en papel o imágenes.
25

36. 2.9.3 Análisis y diseño
2.9.3.1 Análisis
El modelo de análisis contiene las clases de análisis. Las clases de análisis, en
conjunto, representan un primer modelo conceptual del sistema. Las clases de
análisis rara vez sobreviven sin cambios en el diseño. Muchas de ellas representan
colaboraciones del conjunto de objetos, a menudo encapsulados por subsistemas
[13].
2.9.3.2 Diseño
Es un modelo de objeto que describe la realización de casos de uso, y sirve como
una abstracción del modelo de implementación y su código fuente. El modelo de
diseño se utiliza como insumo esencial para las actividades de implementación y
pruebas. Se trata de un artefacto completo, compuesto, que abarca todas las clases
de diseño, subsistemas, paquetes, las colaboraciones y las relaciones entre ellos
[13].
2.10 Modelado de datos con UML
Se centra en la creación de tablas de las clases existentes, esto asegura todas las
clases que se han creado. Una vez que se ha producido el mapeo de clases a tablas,
se puede empezar a buscar formas de optimizar la base de datos, a partir de cómo
manejar las tablas que se crearon sobre la base de relaciones de herencia en el
modelo de clases y las clases que tomó parte en las relaciones muchos-a-muchos
que se tienen que dividir en las asociaciones de las tablas. A partir de ahí el equipo
de diseño de bases de datos comenzará a garantizar la unicidad de las tablas y la
aplicación de elementos tales como reglas de uso de restricciones sobre la base de
datos.
Hay varias formas de mapear modelos. En nuestro escenario, valoraremos la
aplicación y los modelos de bases de datos de diseño para el modelo de análisis
lógico, y vamos a mapear el modelo de diseño de la aplicación directamente en el
modelo de datos. Esto nos da la capacidad de entender la información importante.
El asignar el modelo de objetos al modelo de datos ayuda a construir el acceso a
datos en iteraciones posteriores. Se mapean las clases a tablas, los atributos a
26

37. columnas, los tipos a tipos de datos y las asociaciones a relaciones, lo que ayudara
a los equipos a entender como la aplicación va a interactuar con la base de datos.
No todos los elementos de cada modelo serán asignados. Sólo las clases que son
persistentes se asignarán a la base de datos, y no se pueden derivar los atributos
dentro de las clases persistentes que no se asignan a las columnas. Por ejemplo, a
menudo no son atributos, tales como total_ventas, que son sumas de varias
columnas de la base de datos, pero nunca son almacenados en cualquier parte de
la base de datos. En lugar de almacenar el atributo, es solo un cálculo en la
aplicación [14].
Mapeo de las clases a tablas
Hay cuatro formas básicas de mapeo de clases a las tablas: uno a uno, uno-a-
muchos, muchos-a-uno y muchos a muchos. Es posible que los mapas de manera
diferente por varias razones, incluyendo el rendimiento, seguridad, facilidad de
consulta, las preferencias del administrador de la base de datos, estándares
corporativos, las necesidades específicas de la base de datos, u otros motivos que
pueden haber experimentado. También hay algunas asignaciones que se producen
sobre la metodología de base de datos relacional en general: muchos-a-muchos,
subtipos, supertipos, y clases de asociación. Muchos-a-muchos se rompen en las
relaciones uno-a-muchos mediante la creación de una tabla de asociación. Es una
buena práctica tener columnas adicionales en una tabla de asociación por encima
de las claves externas basadas en las relaciones con las tablas de los padres. Si no
se tiene la necesidad de columnas adicionales, por lo general no es necesaria la
relación de muchos a muchos y sólo se puede crear una relación uno-a-muchos o
un cuadro adicional que no es realmente una tabla de asociación. Si una tabla de
asociación que existe en el modelo de datos y contiene columnas, además de la
clave externa, debe haber una clase de asociación relacionadas en el modelo de
análisis lógico. Una ventaja de usar UML sobre las notaciones tradicionales de la
entidad-relación (ER) para el modelo lógico es el soporte para una clase de
asociación al mismo tiempo que muestra la relación de muchos a muchos como se
ve en la figura 2.11 [14].
27

38. Figura 2.11 Relaciones muchos a muchos
Elementos del diagrama para el diseño de la base de datos
 Tabla: Agrupación de la información en una base de datos sobre el mismo
tema, compuesto por columnas
 Vista: un componente de una tabla que tiene un solo atributo de la tabla
 Dominio : el conjunto válido de valores para un atributo o columna
 PK: la clave candidata que se elija para identificar las filas de una tabla
también conocida como llave primaria.
 FK: una columna o un conjunto de columnas de una tabla que se asignan
a la clave primaria de otra tabla también conocida como llave foránea.
 Identificación de la relación: una relación entre dos tablas en las que la tabla
secundaria debe coexistir con la tabla principal
 Sin Identificación de la relación: una relación entre dos tablas en las
que cada tabla puede existir independientemente de otras.
Los elementos del diagrama para él diseño de la base de datos se muestra en la
figura 2.12 [14].
28

39. Figura 2.12 Diagramas para el diseño de la base de datos
2.11 Conclusión
Este capítulo ha servido a entender el funcionamiento referente a los modelados
de la aplicación PSM, es decir RUP, SOMF, y la arquitectura orientada a servicios.
29

40. Capítulo 3
Análisis de requisitos
3.1 Introducción
Antes que nada al desarrollar una aplicación es necesario analizar el problema, para
poder ofrecer una solución y así resolver el problema. Es por ello que en este
capítulo se muestra la historia de Usuarios, gracias a las historias de usuario
identificamos los puntos clave de la aplicación PSM.
3.2 Historias de usuario
La pollería san Manuel (PSM), es un negocio de venta de pollo al mayoreo y
menudeo. Para el buen funcionamiento del negocio se requieren los servicios para
administrar las compras y ventas realizadas durante diferentes periodos, es decir,
llevar un control por día, semana, mes y año. PSM tiene una granja ¨San Manuel¨
la cual es surtida por algún proveedor mediante embarques con una cierta
cantidad de pollos, para después ofrecerlos al público en general.
Requerimientos de compra
Un primer requerimiento es el control de existencia de pollos en la granja san
Manuel, la cual no debe de tener menos de 150 pollos. Al llegar al límite de
existencia se debe notificar un mensaje de advertencia, para que se pueda
programar en tiempo la compra de embarques de pollos con el proveedor. Esto
con lleva a la necesidad de tener un control de pagos al proveedor, por lo tanto
surgen otros requerimientos para el sistema PSM. Adicional a la existencia de
mercancía, se tienen las posibles bonificaciones por parte del proveedor
generadas por: pago puntual, oportuno y otro. De aquí la importancia de llevar el
control del número del embarque, fecha del embarque, total de pollos, descripción
del embarque, promedios, fechas de cuando se tiene que pagar cada embarque,
total del precio del embarque, mortalidad. En caso de que cada pago genere una
bonificación mensual mostrar el total de las bonificaciones así como la fecha y
números de embarque.
30

41. Requerimientos de venta
PSM se dedica a la venta de pollo por mayoreo y menudeo a continuación se
describirán los tipos de venta y los requerimientos del sistema PSM.
Venta por mayoreo
Las ventas por mayoreo consisten en la venta de 450 pollos o más. Así que se
requiere el control de pagos de los clientes de mayoreo, que desglose número de
embarque, año, mes, día, descripción, precio, total de pollos y promedio. Una
condición para vender es que el cliente no tenga adeudos con PSM
Venta por menudeo
La venta por menudeo consiste en la venta diaria menor a 450 pollos. Dichas
ventas pueden ser de 4 tipos:
 Mostrador:
o Maciza, Surtido, retazo con ala, retazo sin ala, pechuga, pierna sola,
pulpa de pechuga, menudencia, cabezas.
 Vivo
 Mercado
 New York
Este tipo de venta necesita llevar un balance general: de gastos, mortalidad e
ingresos. Para posteriormente tener un balance diario, semanal, mensual y anual.
Se tienen que generar tickets con: descripción, cantidades, precio de venta y total
para los clientes diariamente.
Un servicio adicional de PSM son los pedidos los cuales consisten en la venta por
menudeo
Pedidos
Requiere un servicio de pedidos de pollos, los pedidos pueden ser de mayoreo o
menudeo, el cual necesita almacenar los datos de las fechas, horas, promedios,
descripción, costo, total, datos del cliente y pago por adelantado. Los pedidos
pueden ser de los tipos mayoreo y menudeo, es decir, pueden ser varios pedidos
en un solo pedido. Cada pedido es identificado por un número de pedidos o
nombre del cliente.
31

42. Control de gastos
Requiere un servicio en el cual administre los gastos diarios, semanales, mensuales
y anuales. Con la siguiente información: descripción, total y fecha.
Generación de tickets
No se puede entregan facturas, dado que es pequeño contribuyente pero si se
podrían entregar tickets con el RFC de pequeño contribuyente.
Contabilidad
Necesita tener un servicio en el cual pueda tener el balance general de todos los
servicios. Para tener el total de gastos, adeudos, pagos realizados, control de
embarques, fechas. En los periodos anuales, mensuales, semanales. Es decir un
balance general.
3.3 Conclusión
En este capítulo hemos recolectado los requisitos de la aplicación PSM. Con la
ayuda de las historias de usuario. Esto en un punto fundamental para poder
identificar en el siguiente capítulo los casos de uso de negocios.
32

43. Capítulo 4
Modelado de negocios RUP de la aplicación PSM
4.1 Introducción
En este capítulo se muestra el modelado de negocios de la aplicación PSM, y se
describen los artefactos del modelado de negocios.
El conjunto de modelado de negocio presenta los artefactos que capturan y
representan el contexto del negocio del sistema. Los artefactos de modelado de
negocio sirven como entrada y referencia para los requisitos del sistema. Los
artefactos del modelado de negocios son los siguientes:
 Casos de uso del modelado de negocios
 Especificación de los casos de uso del negocio
 Identificar los actores y las entidades del negocio
 Modelado de objetos de negocio
 Reglas del negocio
4.2 Casos de uso de negocios
4.2.1 Actores del negocio en la figura 4.1
uc Actores
Dueño
Trabajador
Figura 4.1 Actores de negocio
33

44. 4.2.1.1 Dueño
El Dueño es el principal actor del programa PSM, es decir es el encargado
directamente del control de todos los módulos del programa.
4.2.1.2 Trabajador
El Trabajador es el trabajador del negocio, el trabajador está limitado en el
programa a ciertos módulos del sistema.
4.2.2 Diagramas de casos de uso
Figura 4.2 Casos de uso de negocios PSM
34

45. 4.2.3 Requerimientos funcionales caso de uso ComprarPolloAlProveedor
Descripción
Este caso de uso es el encargado de llevar el control de compras de pollo al
proveedor. De esta manera se tiene el inventario de la granja PSM.
El control de embarques, contratiempos del embarque, control de
bonificaciones.
Pre-Condiciones
El usuario debe de autentificarse en el sistema como dueño.
Flujo de eventos principal
El caso de uso empieza cuando:
1. El Dueño revisa el inventario de la granja en el sistema.
2. El Dueño programa el embarque o embarques de Pollo al proveedor
3. El dueño guarda todos los detalles del embarque o embarques en el
sistema.
4. El Dueño paga el embarque o embarques de Pollo al proveedor y los
datos son guardados para tener el control de pagos.
5. Si paga a tiempo se obtiene bonificación y se guarda en el sistema.
6. Finaliza el flujo de ComprasPollosAlProveedor.
Flujos de eventos alternativos
1. Si existen más 150 pollos en la granja termina el caso de uso de
ComprasPollosAlProveedor.
2. Si no autorizan la carga no se guarda en el sistema y termina el caso de
uso de ComprasPollosAlProveedor.
3. Si existen contratiempos en la carga del embarque de pollos se registra
en el sistema dicho contratiempo para posteriormente reportarlo al
proveedor y de esta manera obtener bonificaciones por dichos
contratiempos, es decir: si el embarque tiene cierto número de
mortalidad de pollo, o si atrasaron la carga por otras circunstancias.
5. Si el pago del embarque o embarques de pollos no se paga a tiempo,
no se efectúa el caso de uso Bonificación y por lo tanto no se registra
en el sistema.
35

46. Encadenamiento de errores
E1. Error al conectarse al servidor, se solicita al usuario volver a intentarlo.
E3. Error al guardar los detalles del embarque o embarques.
act DiagramasDeActiv idadCompra
Dueño Prov eedor
Rev isarPollosGranj a
InicioDeActividad
«datastore»
Inv entarioGranj a
Embarques
ProgramarCarga
NoProgramaCarga
AutorizaciónCarga
ProgramanEmbarque
«datastore»
DetallesEmbarque
ContratiemposEmbarque ReportarProv eedor
SiExisten
BonificacionDetalleCarga
NoExistenContratiempos
PagosEmbarque
«datastore»
RegistroEmbarques
Bonificaciones
PagoenTiempo
«datastore»
ControlBonificaciones
SaldoAFav or
Contabilidad
FinalDeActividad
Figura 4.3 Diagrama de actividad ComprarPollosAlProveedor
36

47. La siguiente figura muestra el diagrama de secuencia del caso de uso
ComprarPollosAlProveedor.
sd Diagrama de secuencia ComprarPollosAProv eedor
PSM
Dueño
loop revisa el inventario de la granja en el sistema.()
MuestraResultado()
alt E1
[Si existen más 150 pollos en la granja finaliza.]
SeCancelaOperacion
programa el embarque o embarques de Pollo al proveedor()
alt
[no autorizan la carga no se guarda en el sistema]
SeCancelaOperación
AutorizanCargaProveedor()
GuardaInformación()
SeRegistraPagoProveedor()
alt Bonificacion
[No se paga a tiempo]
[Si se paga a tiempo]:Bonificacion()
Se Registra en sistema la Bonificacion()
(from Actores)
Figura 4.4 Diagrama de secuencia ComprarPollosAProveedor
37

48. 4.2.4 Requerimientos funcionales caso de uso VenderPollosAClientes
Descripción
Este caso de uso es el encargado de llevar el control de ventas de pollo al
cliente .De esta manera se tiene el control del inventario de la granja PSM y
del rastro PSM.
Este caso de uso se extiende por los casos de uso Mayoreo y Menudeo.
Pre-Condiciones
El usuario debe de autentificarse en el sistema.
Flujo de eventos principal
El caso de uso empieza cuando:
1. El usuario requiere registrar un tipo de venta.
2. El caso de uso base “VenderPolloAClientes”, pasa a los puntos de
extensión 1 y 2.
3. Se muestran las opciones de venta, de acuerdo al nivel de usuario.
Flujo de eventos alternativos
3. El Dueño selecciona el tipo de venta a realizar: “Mayoreo” o “Menudeo”.
Encadenamiento de errores
E3. El dueño no seleccione ningún tipo de venta.
E2.1 Si la venta es mayor a 450 pollos. No puede vender el trabajador.
Puntos de extensión
1. Caso de Uso: Menudeo
2. Caso de Uso: Mayoreo
Flujos de eventos principales puntos de extensión
Si el usuario es el actor Trabajador o Dueño:
PE1.
1.1 El usuario especifica los datos de la venta.
1.2 Guarda la información.
38

49. 1.3 El sistema genera el ticket con los datos especificados de la venta de
pollo.
Si el usuario es el actor Dueño:
PE2.
2.1 Consulta adeudo del cliente
2.2 Programa embarque
2.3 Guardar los detalles del embarque del cliente.
2.4 Registra Pago Cliente (Detalles, Fechas).
2.5 Termina el flujo del caso de uso Mayoreo.
Flujos de eventos alternativos puntos de extensión
2.1 No Programa embarque. Debe carga anterior.
2.3 El dueño puede hacer descuento o no.
Post-Condiciones
Sale una notificación avisando si requiere registrar más ventas o regresar al
menú de selección.
39

50. La siguiente figura muestra el diagrama de actividad del caso de uso
VenderPolloAClientes.
act DiagramasDeActiv idadVentas2
Trabaj ador Dueño
InicioDeActividad
VentasPollo
ContactaDueño VenderPolloCliente
Mayorista Menudista
Existe Adeudo
ValueSpecification
Descuento
NoExisteAdeudo
ProgramaEmbarque
Ticket
«datastore»
RegistraDatosdeEmbarqueCliente
No ha Pagado el Cliente
Si ya Pago el Cliente
«datastore»
RegistroPagosClientes
Contabilidad
FinalDeActividad
Figura 4.5 Diagrama de actividad de vender pollos al cliente PSM
40

51. La siguiente figura muestra el diagrama de secuencia del caso de uso
VenderPollosAClientes.
sd Modelo de casos de uso VenderPolloAClientes
PSM
Dueño
Trabaj ador
Se Muestran las Opciones de Venta
Mayoreo Menudeo() (from Actores)
loop SelccionaOpciónMenudeo()
Ingresa los datos de Venta()
Se Muestra el Menú Menudeo()
alt Descuento
SeEfectuaDescuento()
IngresaDatosVenta()
SeGuardan los detalles de la Venta()
Seleccion Ticket o Nota()
SeleccionOpcionTicketoNota()
alt
[SeleccionaOpcionTicket]
Se Imprime Ticket()
alt
[Selecciona la opcion Ticket]
Se ImprimeTicket()
SeleccionOpcionNota()
SeImprimeNota()
Selecciona la opción Nota()
SeImprimeNota()
loop
SelccionaOpcionMayoreo()
ConsultaAdeudoCliente()
ResultadoConsulta()
ProgramaEmbarque()
SeGuardaInformacionEmbarqueyCliente()
RegistraPagoCliente()
(from Actores)
Figura 4.6 Diagrama de secuencia de VenderPollosACliente PSM
41

52. 4.2.5 Requerimientos funcionales caso de uso VenderPedidos
Este caso de uso es el encargado de realizar pedidos o pedido de un cliente al
Dueño.
El actor Dueño necesita llevar el control de todos los pedidos con todos sus
detalles, adeudos, liquidación de pagos, descuentos, de esta manera tener un
control sobre el inventario en granja y rastro.
Pre-Condiciones
El usuario debe de autentificarse en el sistema.
Flujo de eventos principal
El caso de uso empieza cuando:
1. El usuario revisa el inventario de la granja en el sistema.
2. El usuario realiza el pedido del cliente.
3. El Dueño puede hacer descuento al cliente.
4. El usuario registra los datos del cliente y los detalles del pedido (total,
subtotal, a cuenta, resta, nombre, fecha, n_pedido).
5. El usuario genera la nota de remisión del pedido.
6. Termina el flujo de la orden del pedido.
Sub-Flujo de eventos principal
El caso de uso empieza cuando:
1.1 El usuario busca el n_pedido.
1.2 El cliente paga el adeudo.
1.3 Actualiza los datos de la nota del pedido.
1.4 Se genera la nota de remisión actualizada.
Flujos de eventos alternativos
1.1 Si no existe la nota se notifica. Y se vuelve a pedir el Número de la
nota.
3. El Trabajador no puede hacer descuento. No se le presenta esta opción
en el sistema.
Encadenamiento de errores
E1. Error al conectarse al servidor, inténtelo de nuevo por favor.
E4. Error no registro nada, por favor ingresen los datos que se piden.
42

53. Post-Condiciones
Se muestra la siguiente notificación: Los datos se han registrado
correctamente.
El usuario registra los pedidos del cliente en el sistema. Y se actualiza el
inventario y Contabilidad.
La siguiente figura muestra el diagrama de actividad Pedidos.
act DiagramasDeActiv idadPedidos
Cliente Dueño
InicioDeActividad
ClienteRequierePedidoPollo
Rev isarInv entarioGranj aYRastro
FinalDeActividad
CumplenReqCliente
PedidoCliente
Descuento
SeHaceDescuento
AnticipoPedido
«datastore»
ControlPedidos
NotaRemisiónClienteContabilidad
EntregaPedido
CompletaPagoPedidoCliente
«datastore»
ActualizaNRemisionCPagadoContabilidad
FinalDeFlujo
Figura 4.7 Diagrama de actividad de pedidos PSM
43