Desarrollo de un sistema deInformación Basado en SOAManuel Maldonado Mendoza
Benemérita Universidad Autónoma de Puebla         Facultad de Ciencias de la Computación“Desarrollo de un sistema de infor...
ContenidoCapítulo 1 .........................................................................................................
Modelado de negocios RUP de la aplicación PSM ........................................................... 33  4.1 Introduc...
4.2.6 Requerimientos funcionales caso de uso ObtenerInventario ........................ 45       Pre-Condiciones ............
5.3 Análisis y diseño de la aplicación PSM ...................................................................... 71      ...
7.15 Pantalla registro inventario ...........................................................................................
Pedidos .....................................................................................................................
AgradecimientosQuiero agradecer de antemano a Dios por darme la oportunidad de tener auna excelente familia, amigos y maes...
ResumenEl proyecto está enfocado hacia la administración de la venta y compra de pollo,teniendo en cuenta que se desea ten...
Capítulo 1Contribución del trabajo de tesisLa Arquitectura Orientada a Servicios (SOA), surge gracias a la necesidad deres...
Retos de SOA:      La capacitación en una nueva tecnología, adquisición de la misma y el punto       más importante de to...
Capítulo 2Estado del arte2.1 IntroducciónEl estado del arte está conformado por la explicación de los modelos aplicados en...
deban de ser tratadas por igual la parte de análisis, diseño, arquitectura y debenser reconocidos como servicios [16].El m...
Los servicios son utilizados por una aplicación cliente que les envía mensajesrespetando un determinado contrato de servic...
2.3 Consumo de servicios¿Una vez que los servicios están disponibles en la plataforma SOA, que se hacecon ellos?Existen 2 ...
2.5 XMLeXtensible Markup Language (XML) recientemente ha ganado mucha notoriedadcomo una solución tecnológica para el inte...
sistemas de mensajes a RPC (Remote Procedure Call, Llamada a ProcedimientoRemoto) [17].SOAP consta de tres partes:      L...
computación en la nube para la organización. El marco, escrito por Michael Bell,proporciona una notación independiente de ...
Análisis de operaciones (Notaciones de las operaciones)Existen los siguientes símbolos de operaciones que pueden ser utili...
Figura 2.3 Análisis de operaciones SOMFAnálisis contextual de las operaciones SOMF:      Generalizar: Aumenta el nivel de...
Figura 2.4 Análisis contextual de las operaciones SOMF2.8.2 Integración de negocios orientada a serviciosSe debe utilizar ...
Notación de la integración de operacionesHay seis símbolos de integración que deben ser empleados para describir unainicia...
   Contenido. La actividad de contención tiene lugar entre los dominios para       formar un dominio estructurado jerárqu...
Hay dos categorías de los conectores de relación de servicios.   1. Relación aparente: Esto denota una relación visible en...
Roles en el contexto de diseño orientado a serviciosEl paradigma orientado a servicios presenta tres funciones principales...
ya sea unidireccional y bidireccional con los correspondientes consumidores yservicios.Como se mencionó anteriormente en l...
afiliaciones conceptuales. En segundo lugar, más adelante en la fase de diseño deservicios, las relaciones lógicas fueron ...
Las cuatro principales asociaciones conceptuales de los tipos de servicios son:circular, jerárquica, malla y estrella.El e...
Estilo de la composición del diseño jerárquicoLa asociación jerárquica conceptual del servicio ayuda al proceso a descubri...
Modelado de transacciones orientado a serviciosEn [19] 1983, Theo Haerder y Andreas Reuter presentaron requisitos fundamen...
ACID es un método de procesamiento de transacciones estrechamente unidas. Esdecir, este enfoque fue diseñado para hacer fr...
   Conector de la actividad de intermediación: Una actividad puede implicar       múltiples servicios y consumidores. Por...
La segunda dimensión representa el aspecto estático del proceso: la forma en quese describen los términos de los component...
2.9.1.2 Diagramas de actividadesSe utilizan para ilustrar las actividades. En el punto de vista externo, se utilizandiagra...
2.9.3 Análisis y diseño2.9.3.1 AnálisisEl modelo de análisis contiene las clases de análisis. Las clases de análisis, enco...
columnas, los tipos a tipos de datos y las asociaciones a relaciones, lo que ayudaraa los equipos a entender como la aplic...
Figura 2.11 Relaciones muchos a muchosElementos del diagrama para el diseño de la base de datos      Tabla: Agrupación de...
Figura 2.12 Diagramas para el diseño de la base de datos2.11 ConclusiónEste capítulo ha servido a entender el funcionamien...
Capítulo 3Análisis de requisitos3.1 IntroducciónAntes que nada al desarrollar una aplicación es necesario analizar el prob...
Requerimientos de ventaPSM se dedica a la venta de pollo por mayoreo y menudeo a continuación sedescribirán los tipos de v...
Control de gastosRequiere un servicio en el cual administre los gastos diarios, semanales, mensualesy anuales. Con la sigu...
Capítulo 4Modelado de negocios RUP de la aplicación PSM4.1 IntroducciónEn este capítulo se muestra el modelado de negocios...
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 ...
4.2.3 Requerimientos funcionales caso de uso ComprarPolloAlProveedorDescripción     Este caso de uso es el encargado de ll...
Encadenamiento de errores      E1. Error al conectarse al servidor, se solicita al usuario volver a intentarlo.      E3. E...
La siguiente figura muestra el diagrama de secuencia del caso de usoComprarPollosAlProveedor.sd Diagrama de secuencia Comp...
4.2.4 Requerimientos funcionales caso de uso VenderPollosAClientesDescripción     Este caso de uso es el encargado de llev...
1.3 El sistema genera el ticket con los datos especificados de la venta de      pollo.    Si el usuario es el actor Dueño:...
La siguiente figura muestra el diagrama de actividad del caso de usoVenderPolloAClientes.        act DiagramasDeActiv idad...
La siguiente figura muestra el diagrama de secuencia del caso de usoVenderPollosAClientes.   sd Modelo de casos de uso Ven...
4.2.5 Requerimientos funcionales caso de uso VenderPedidos     Este caso de uso es el encargado de realizar pedidos o pedi...
Post-Condiciones     Se muestra la siguiente notificación: Los datos se han registrado     correctamente.     El usuario r...
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza
Upcoming SlideShare
Loading in …5
×

Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza

2,563 views
2,481 views

Published on

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ñó.

La aplicación cliente fue desarrollada en wpf.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,563
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
146
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesis Desarrollo de un Sistema de información basado en SOA by Manuel Maldonado Mendoza

  1. 1. Desarrollo de un sistema deInformación Basado en SOAManuel Maldonado Mendoza
  2. 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. 3. ContenidoCapítulo 1 ............................................................................................................................................... 1 Contribución del trabajo de tesis .............................................................................................. 1Capí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.............................................................................................................................. 29Capítulo 3 ............................................................................................................................................. 30 Análisis de requisitos ................................................................................................................... 30 3.1 Introducción......................................................................................................................... 30 3.2 Historias de usuario .......................................................................................................... 30 3.3 Conclusión ............................................................................................................................ 32Capítulo 4 ............................................................................................................................................. 33
  4. 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. 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 ............................................................................................................................ 69Capítulo 5 ............................................................................................................................................. 70 5.1 Introducción......................................................................................................................... 70 5.2 Descripción .......................................................................................................................... 70
  6. 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 ............................................................................................................................ 73Capí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 ............................................................................................................................ 80Capí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. 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 .................................................................................................................................100Capítulo 8 ...........................................................................................................................................101 Pruebas y resultados ..................................................................................................................101 8.1 Descripción ........................................................................................................................101 8.2 Pruebas ................................................................................................................................101Capítulo 9 ...........................................................................................................................................121 Conclusión .....................................................................................................................................121Bibliografí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. 8. Pedidos .......................................................................................................................................131 Ventas .........................................................................................................................................132Apé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. 9. AgradecimientosQuiero agradecer de antemano a Dios por darme la oportunidad de tener auna excelente familia, amigos y maestros. Por compartir grandesexperiencias en la vida, tener momentos buenos, momentos malos, ymomentos muy malos, es por ello que le doy gracias a Dios por darme elaliento y la fuerza de voluntad para seguir adelante. Así como también ledoy las gracias a mi familia de todo corazón por que con su confianza,esfuerzo y sacrificio me dieron motivos por los cuales poder seguirtrabajando. En especial a mi padre por esos sabios consejos y ejemplos de sugran vida para poder sobresalir, y para nunca cruzar los brazos en esomomentos críticos de la vida. Les estoy también muy agradecido a losprofesores y amigos como lo son el Dr. García Juárez que me ayudo aconfiar en mi y me demostró que es mi amigo ya que esta en las buenas yen las malas, dándome consejos y motivaciones, la Doctora Sandoval Solísquien 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, ColmenaresGuillen, Dr. Manuel Martin, a los Maestros Anzures García y MelisaContreras Gonzales por ser mis sinodales y maestros, también por susenseñanzas, a los maestros De la Rosa Flores, Camarillo Martínez,Palomino Jiménez, Zamora Lima y a muchos otros profesores. Así comotambién a mis amigos Pablo Camarillo, Luis IbargÜen, Vélez Bello, RomeroRincón, Sergio Olivos, Alexander Arriaga y a muchos otros amigos queme faltaron mencionar. De todo corazón estoy muy agradecido con todosellos porque han sido parte de mi vida universitaria, no me queda otra cosamás que darles las gracias por su ayuda y confianza.
  10. 10. ResumenEl 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 delas ventas y compras de pollo, costos por viajes, embarques, balance general condescripción de ventas, pedidos, fechas de embarque.El concepto de software como servicio, es una visión que nos permite ofrecersoporte a las necesidades de un mercado de software muy competitivo. Gracias a lainteroperabilidad de los servicios web.A lo largo de este trabajo nos centraremos: En el estudio del problema del sistemaPSM (Pollería San Manuel). Aplicando la metodología RUP (Rational UnifiedProcess). Esto con lleva a realizar las siguientes actividades:  Modelado de negocios  Requerimientos  Análisis y diseño  Implementación  PruebasEn base al modelado de negocios, se pueden obtener los requerimientosfuncionales. De esta manera identificamos los servicios de la aplicación PSM. Paramodelar los servicios web, se deben realizar las siguientes disciplinas del modeladoSOMF (Service-Oriented Modeling Framework).  Modelado de análisis orientado a servicios.  Modelado de integración de Negocios.  Modelado de diseñó.
  11. 11. Capítulo 1Contribución del trabajo de tesisLa Arquitectura Orientada a Servicios (SOA), surge gracias a la necesidad deresolver las complejidades del mercado, con respecto al tiempo y a la calidad delsoftware. SOA considera que una aplicación está compuesta por un conjunto deservicios autónomos.En términos generales, SOA es un estilo arquitectónico cuyo objetivo es lograr unacoplamiento libre entre los servicios web interactuantes. Permitiendo la creaciónde sistemas altamente escalables y a su vez brinda una forma estándar deexposición e invocación de servicios, lo cual facilita la interacción entre diferentessistemas propios o de terceros. SOA es un conjunto de servicios, estos servicios secomunican entre sí [11]. La comunicación puede implicar pasar datos simples opodría implicar la coordinación de dos o más servicios de algunas actividades.SOA permite separar funciones en distintas unidades o servicios que losdesarrolladores hacen accesibles dentro de una red, con el fin de que los usuariospuedan combinarlas y reutilizarlas en la producción de aplicaciones. Estos serviciosse comunican entre sí pasando información de un servicio a otro o coordinandoactividades 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 ocolaboraciones. SOA contribuye también a documentar el modelo de negocios dela empresa y a utilizar el modelo de negocios documentado para integrar en él ydar respuesta a los cambios dinámicos optimizando los recursos que se produzcanentre ellos. 1
  12. 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 unnegocio. ¿Cuál sería el primer punto a considerar? El primer punto a considerar enesta 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 paramodelar los negocios.En el Capítulo 2 se representa el estado del arte de esta tesis. Es decir ladescripción del modelado de negocios, análisis y diseño con RUP, modelado deservicios 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. Enel capítulo 4 se detalla el modelado de negocios, así como sus artefactos de laaplicación Pollería San Manuel (PSM). Después del modelado de negocios sedescriben 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 lasclases, 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 realizadotodo el modelado de negocios y la especificación de requerimientos, se tomacomo punto de partida los requerimientos funcionales. Con los requerimientosfuncionales se identifican los servicios. En el capítulo 6 se explica el ciclo de vida delmodelado orientado a Servicios de la metodología SOMF (Service OrientedModeling Framework). Conformado por el modelo de análisis, integración denegocios y diseño. En el capítulo 7 se muestra la implementación de la aplicaciónPSM orientada a Servicios y los WSDL, en el capitulo 8 se muestran las pruebas yresultados realizados de la aplicación PSM. En el capítulo 9 se muestran lasconclusiones de esta tesis. 2
  13. 13. Capítulo 2Estado del arte2.1 IntroducciónEl estado del arte está conformado por la explicación de los modelos aplicados enesta tesis. Es decir: modelado de negocios, requerimientos, análisis y diseñocon RUP, modelado de servicios con SOMF y el modelado de datos con UML.2.2 SOALa Arquitectura Orientada a Servicios (SOA), es un concepto de arquitectura desoftware que define la utilización de servicios para dar soporte a los requisitos delnegocio. Permite además, la creación de sistemas de información altamenteescalables que reflejan el negocio de la organización, y que a su vez brindan deuna 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 entrediferentes sistemas propios o de terceros [17].SOA proporciona una metodología y un marco de trabajo para documentar lascapacidades de negocio y puede dar soporte a las actividades de integración yconsolidación.Los conceptos de software futurista probablemente contribuirán a otra capa de losentornos computacionales complejos, un demandante de recursos para el apoyode presupuestos. La arquitectura orientada a servicios (SOA) ayuda a resolver losproblemas de la interoperabilidad, reutilización, y otros problemas asociados coneste paradigma. La visión de SOA también se ocupa de los retos de softwarefuertemente acoplados y clama por una arquitectura que se basa en elacoplamiento de los “assets”.SOA ayuda a la reducción del tiempo de salida al mercado y la agilidad delnegocio. De hecho, la lista de ventajas sigue creciendo. El modelado orientado alos servicios proporciona mecanismos que nos permitan concebir productos desoftware 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. 14. deban de ser tratadas por igual la parte de análisis, diseño, arquitectura y debenser reconocidos como servicios [16].El modelado orientado a servicios es una práctica de desarrollo de software queutiliza las disciplinas de modelado y el lenguaje UML para ofrecer solucionesestratégicas y tácticas a los problemas de la empresa. Este paradigma de modeladoes una visión integral del análisis, diseño y arquitectura de software de todas lasentidades 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 enuna plataforma X, desde una aplicación corriendo en cualquier plataforma, encualquier 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ónorientada a objetos e implementa mejoras a esta última, producto de la experienciaacumulada en la última década, sobre todo en las áreas de la computacióndistribuida, instalación de una solución e interoperabilidad entre sistemas [18].SOA, a diferencia de las arquitecturas de objetos distribuidos como J2EE, reflejamás fielmente los procesos y relaciones del mundo real; es decir, SOA representauna manera más simple y natural de modelar y construir software que solucionaproblemáticas de negocios del mundo real [18].Los sistemas orientados a servicios, son diseñados con un bajo nivel deacoplamiento que facilita la implementación de cambios y estos servicios puedenser desarrollados en cualquier lenguaje corriendo en diferentes plataformas.Desde el punto de vista de un usuario, la diferencia entre utilizar servicios y utilizarcomponentes tradicionales es imperceptible. Desde el punto de vistaarquitectónico, en cambio, podemos decir que los servicios a diferencia de loscomponentes son autónomos, encapsulan sus propios datos de la aplicación. Estosservicios pueden ser generados por distintos equipos de desarrollo, en diferentestiempos, plataformas y espacios; es decir, que una aplicación puede ir creciendo yaumentando su funcionalidad a medida que se construyan nuevos servicios que nonecesariamente deben estar bajo el control del equipo de desarrollo de laaplicación, por lo que es esencial que entre nuestras aplicaciones y los serviciosque ellas consumen, sean débilmente acopladas. 4
  15. 15. Los servicios son utilizados por una aplicación cliente que les envía mensajesrespetando un determinado contrato de servicios, pero internamente esos serviciosutilizan los conceptos de la Programación Orientada a Objetos (OOP) [18].SOA tiene dos partes clave: servicio y arquitectura. El servicio es esencialmente lavista hacia el exterior de las aplicaciones dentro de la organización TI (tecnologíasde la información), donde cada aplicación proporciona los "servicios empresariales"necesarios para el acceso de otras aplicaciones. La "arquitectura" es el enfoque detoda la organización para "utilizar" los servicios. Ya que hay múltiples aplicaciones ysoluciones dentro de la organización, tiene que existir una decisión de comoproveer 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 laestandarización mediante una infraestructura proporcionar y consumir estosservicios, y los servicios que se consumen a través de un proceso basado enframeworks, todo estaría compuesto por SOA "arquitectura", se muestra en lasiguiente figura 2.1, los componentes de la arquitectura SOA [17]. Figura 2.1 Componentes de la arquitectura SOA. 5
  16. 16. 2.3 Consumo de servicios¿Una vez que los servicios están disponibles en la plataforma SOA, que se hacecon 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 webLos Servicios web son una innovación en tecnología de la World Wide Web. Unservicio web es un programa de aplicación basado en la web con una interfazdefinida que acepta y procesa las solicitudes y devuelve una respuesta alsolicitante. 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 unconjunto de estándares de comunicación, como son XML para la representación dedatos, SOAP (Simple Object Access Protocol) para el intercambio de datos y ellenguaje WSDL (Web Services Description Language) para describir lasfuncionalidades de un servicio web [18]. 6
  17. 17. 2.5 XMLeXtensible Markup Language (XML) recientemente ha ganado mucha notoriedadcomo una solución tecnológica para el intercambio de mensajes. Se puede utilizarcon ventaja para muchos tipos de aplicaciones tales como el movimiento de datosentre los sistemas de negocio o describir una transacción de negocios, unasolicitud para persistir o almacenar datos en una base de datos, o una solicitud deservicio.XML es un fenómeno relativamente reciente (cerca de 1997) [19], pero estable, latecnologí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 deun documento, transacción o mensaje. Los esquemas para ampliar las capacidadesde los metadatos XML, se efectúa mediante la definición de reglas y restriccionesde las características de los datos, tales como la estructura, las relaciones, losvalores 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 otrossistemas empresariales o, posiblemente, con los socios externos de la empresa,podemos ver rápidamente la necesidad de aplicar prácticas eficaces de laarquitectura de datos.En muchos casos, XML se utiliza para describir el contenido de un documentosencillo. Sin embargo, las transacciones y datos de los mensajes orientados aservicios ayudan a ofrecer oportunidades, aún mayores para las aplicaciones conXML. 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 dereferencia a XML. Hay varios tipos de esquemas que se pueden utilizar con XML.2.6 SOAPSOAP (Simple Object Access Protocol) proporciona un mecanismo para elintercambio de información estructurada en un entorno descentralizado ydistribuido usando XML. SOAP no define en sí mismo ninguna semántica de laaplicación como un modelo de programación, sino que define un mecanismosimple para expresar la semántica de aplicaciones, proporcionando un modelo depaquetes y los mecanismos de codificación dentro de los módulos de datos. Estopermite a SOAP, ser utilizado en una gran variedad de sistemas que van desde 7
  18. 18. sistemas de mensajes a RPC (Remote Procedure Call, Llamada a ProcedimientoRemoto) [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 WSDLWSDL (Web Services Description Language), es el idioma más común de describirlos servicios [19]. WSDL está escrito como un documento XML. WSDL tiene dosPartes 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 cuyadisciplina específica de lenguaje de modelado y las mejores prácticas se centran enel diseño de software en la arquitectura de distintas actividades, empleadasdurante diferentes etapas del ciclo de desarrollo de software. Por otra parte, losarquitectos, analistas, modeladores, desarrolladores y administradores de SOMF loemplean para hacer frente a la arquitectura empresarial, arquitectura deaplicaciones, arquitectura orientada a servicios (SOA), y los desafíos de la 8
  19. 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ónintegral 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 servicios2.8.1 Análisis orientado a serviciosUn 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. 20. Análisis de operaciones (Notaciones de las operaciones)Existen los siguientes símbolos de operaciones que pueden ser utilizados pararepresentar 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 elcual los servicios se transforman para hacer frente al dominio del problema. Porejemplo, "agregados" se refiere al estado actual de un servicio que ha sidoconformado 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 susoperaciones. Por lo tanto, la notación propuesta profundiza en las actividades deanálisis que se llevaron a cabo y describe el estado actual de los servicios y sucontribució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 elproceso de análisis de servicios [16]. 10
  21. 21. Figura 2.3 Análisis de operaciones SOMFAná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 operacionesSOMF [16]. 11
  22. 22. Figura 2.4 Análisis contextual de las operaciones SOMF2.8.2 Integración de negocios orientada a serviciosSe 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 yrepresentan una serie de operaciones que se pueden utilizar para describir laintegración de Negocios. En la figura 2.5 se muestran los elementos de laintegración de Negocios [16]. Figura 2.5 Notación de la integración de negocios orientado a servicios 12
  23. 23. Notación de la integración de operacionesHay seis símbolos de integración que deben ser empleados para describir unainiciativa empresarial orientada a los servicios de integración. Estas actividadesdeben ser representadas en un esquema de integración. También es imprescindiblepara identificar los pasos y los diferentes procesos por los cuales se llego a lapropuesta de integración final de los casos. Por lo tanto, este esquema deberegistrar el estado actual o futuro de la integración orientada a servicios. En lafigura 2.6 se muestra la integración de operaciones [16]. Figura 2.6 Integración de operacionesSe deben considerar los símbolos de integración después de la operación, quepueden 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. 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 servicioNotación de la relación lógica. Consta de cuatro conectores que hacen posibletransmitir una relación aparente o implícita entre los assets de software orientada aservicios, tales como servicios, e incluso los consumidores. Estos símbolos seutilizan para ilustrar las rutas de mensajes de datos intercambiados y la informaciónsobre una red como se muestra en la figura 2.7 [16]. Figura 2.7 Relación lógica del servicioLa forma general de un conector de relación de servicio es una línea que indica ladirección e identifica la visibilidad de los servicios. 14
  25. 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ónde la naturaleza del servicio. 15
  26. 26. Roles en el contexto de diseño orientado a serviciosEl paradigma orientado a servicios presenta tres funciones principales que puedenenvolverse 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 debeser coherente, sino que debe estar ligado a un contrato que se establece porencima de cualquier utilización de los servicios.Rol de los consumidoresUn cliente es una entidad de software orientada al servicio que está diseñada paraadquirir los servicios. Es decir, normalmente las implementaciones de software queno 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 comunicarsecon 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 contratovinculante que puede dar el seguimiento y cumplimiento en tiempo deejecución. Los consumidores también deben comprometerse al servicio deconsumo con ciertos límites y restricciones de disponibilidad del servicio. Elconsumo es generalmente medido por el volumen de mensajes intercambiados yla frecuencia de la información conforme a lo acordado en el contrato. Ladisponibilidad, en el servicio, por otra parte, tiene restricciones en el tiempo deacceso impuestas a un consumidor.Rol de servicioUn servicio es una entidad que se compromete a su oferta a través de un contratovinculante a sus consumidores suscritos. Este acuerdo estipula por lo general loque está presente en la disponibilidad de un servicio, las tasas de consumo, y eltiempo de respuesta. Además, los servicios pueden mantener una implícita relación 16
  27. 27. ya sea unidireccional y bidireccional con los correspondientes consumidores yservicios.Como se mencionó anteriormente en la sección de rol del consumidor, un serviciotambién puede actuar como un consumidor. Imaginemos un servicio que no sóloestá obligado a servir a su comunidad de consumo, sino también tiene laobligación de intercambiar mensajes con los servicios.Rol del intermediarioCualquier software orientado a servicios se encuentra entre los consumidores parafacilitar la comunicación es considerado como un intermediario.2.8.3 Diseño orientado a serviciosEs más que una formación, una forma visual, un paquete de software que suele sermoldeada por patrones predefinidos, se compone de software orientado a serviciosque se utilizan para comunicar una solución del problema que se plantee. Esto noes sólo un método táctico para proporcionar una solución a una preocupación dela organización, sino también un plan estratégico para resolver problemassimilares en el futuro. La composición del diseño es el resultado de tres aspectosimportantes que contribuyen: asociaciones de servicio, las rutas de intercambio demensajes, y los patrones generales de los servicios que ofrecen una solución. Ahoracada uno de estos contribuyentes se inspecciona para llevar a una mejorcomprensión de la esencia de este esfuerzo de embalaje orientada a servicios.Asociaciones de servicioDurante el ciclo de vida orientado a servicios, se encontraron dos tipos derelaciones de servicio: conceptual y lógico. Estas categorías de asociación deservicios influyen en la construcción de una composición de servicios: En primerlugar, en la fase de la conceptualización de servicios, comúnmente los servicios ylas diferencias se identifican en forma de negocio o vínculos tecnológicos entre losservicios que participan en una solución, los cuales son conocidos como 17
  28. 28. afiliaciones conceptuales. En segundo lugar, más adelante en la fase de diseño deservicios, las relaciones lógicas fueron descubiertas entre los servicios que sonimpulsados por la distribución de mensajes y las necesidades de cambio.Rutas de intercambio de mensajesLas relaciones de servicio afectan a las decisiones del diseño de entrega demensajes. Estas asociaciones de identificar los requisitos permiten establecer lasmejores rutas de mensaje para transacciones eficientes. Una ruta de mensajes serefiere a las rutas de red que permiten que la información se intercambie entre losconsumidores y servicios. Por lo tanto, una composición de diseño estáinfluenciada por las relaciones de servicio y formada por las rutas de intercambiode mensajes y comportamiento en servicio que fueron concebidas antes en la fasede diseño lógico de la relación orientada a servicios.Patrones de formación dirigida por estilosEl diseño de la composición orientada a servicios es la construcción de lasformaciones por posicionamiento de servicios en ciertas formas, nombradasestilos, para proporcionar soluciones. Estos acuerdos forman patrones visuales queayudan a permitir un eficiente enrutamiento de mensajes y la ejecución de latransacción. Las formaciones de servicio que se descubrieron también sonconsideradas como soluciones empaquetadas en las que se comunican lasestrategias empleadas para resolver las preocupaciones de la organización.Diseño de la composición orientada a serviciosPara ofrecer soluciones efectivas a los planos de diseño orientado a servicios, seproponen una serie de composiciones. Un estilo de composición de diseño essimplemente un patrón. Es similar a una plantilla que puede servir de guía a lavinculación de las estructuras de la atomicidad, composición y clúster de serviciospara comunicar los tipos de problemas que pueden ayudar a resolver y ayudar aforjar las estrategias de diseño, tales como la reutilización de servicios y lainteroperabilidad. Sus nombres son los estilos, ya que forman a la composición dela entrega del diseño. En pocas palabras, una composición de diseño orientada aservicios no sólo comunica una solución, sino que también proporciona unaestrategia que se puede aprovechar en el futuro. 18
  29. 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ónde diseño circular, se muestra en la figura 2.8. De la misma manera, en lasasociaciones de tipo jerárquica, malla y estrella de la red se emplean el diseño dela composición para describir una red [16]. Figura 2.8 Asociaciones de la composición orientada a serviciosEstilo de la composición del diseño circularEl 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 negocioo asociación tecnológica. El mensaje está en las manos del creador del servicio enel primer mensaje para el próximo servicio que reciben. Posteriormente a laentrega de mensajes siempre participa el próximo servicio. Cuando esta operaciónse 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 intermediariosinnecesarios. En cambio, los mensajes se entregan de un servicio a otro hasta quela respuesta se entrega al autor del mensaje. La entrega de mensajes implica unaserie de servicios que comparten la carga de procesamiento de transacciones, enlugar de aplicar la tensión a un único servicio. El estilo de la composición deldiseño circular es adecuada para la gestión de negocios y tecnologías, procesos através de la participación de las partes interesadas directamente sin laintervención de intermediarios. 19
  30. 30. Estilo de la composición del diseño jerárquicoLa asociación jerárquica conceptual del servicio ayuda al proceso a descubrirconceptos e ideas para la asociación de sus atributos comunes. También semuestra la necesidad de identificar la reutilización de clúster de servicios. Parapoder abordar el aspecto de consumo de los servicios, incluso antes de quesean transportados a su producción. El análisis suele facilitar la estructura de lasasociaciones jerárquicas de las capas del servicio.Estilo de la composición del diseño mallaCon demasiada frecuencia, los profesionales se enfrentan al tiempo de diseño y altiempo de ejecución de los desafíos ambientales que requieren la colaboración deuna planificación del servicio y en la integración del servicio. Estas dificultadessurgen debido a la interoperabilidad creciente en el entorno computacionalteniendo así complejidades, los sistemas operativos y las plataformas múltiples queemplean las organizaciones.El estilo de la composición del diseño Malla se puede utilizar para obtener lasiguiente 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 estrellaEl último estilo de diseño es la composición de estrella, que ofrece otro punto devista de la estrategia de diseño. Los estilos de diseño tratan de resolver losproblemas, pero también facilitan un plan de ataque, una estrategia y un mapa deruta para lograr los objetivos de diseño. Por lo tanto, el estilo de composiciónestrella añade otro punto de vista de los planos de diseño. Se puede mejorar lacreación de un diseño del ambiente débilmente acoplados y ayudar a medir laefectividad al dividir los ambientes en los que se elaboran. 20
  31. 31. Modelado de transacciones orientado a serviciosEn [19] 1983, Theo Haerder y Andreas Reuter presentaron requisitos fundamentalespara la ejecución de las transacciones, en el trabajo de investigación “Principios dela transacción orientada a la recuperación de las bases de datos”.Su trabajo está centrado en cuatro grandes principios que definen una transaccióny se identificaron cuatro atributos más importantes que garantizarán el buen fin delas actividades de operación. Estos grandes principios son por sus siglas en inglés(ACID): Atomicidad Coherencia Aislamiento DurabilidadSe convirtió en el estándar de la industria para la manipulación de datos fiables y laintegridad de las transacciones en un entorno multi-usuario. Haerder y Reuter,describen una transacción como: la manera en que se componen variasoperaciones de software que interactúan con una base de datos durante unperíodo determinado de tiempos. No hay cambios en los datos, se debe deducirque 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. 32. ACID es un método de procesamiento de transacciones estrechamente unidas. Esdecir, este enfoque fue diseñado para hacer frente a los problemas locales dedepósito y fiabilidad de las soluciones de cada acción, es decir, los resultadosexitosos de transacciones están garantizados sólo por un corto período detiempo. En el ambiente de computación orientado a servicios deben serinteroperables requiere un modelo que pueda manejar la interacción ycolaboración de servicios en las estructuras complejas y agregadas. Además, serequiere la integridad de las transacciones entre las formaciones de serviciosdébilmente acoplados dispersados a lo largo de múltiples líneas de negocios yorganizaciones. Un esquema de operación orientada a servicio debe serencargado de resolver desafíos de las transacciones de larga duración [19].Conectores de la actividadExisten tres conectores de la actividad de servicios que pueden ayudar en ladescripción de la interacción y colaboración de los servicios, como se ilustra en lafigura 2.9. Se deben utilizar en cada actividad una sección para describir lospasos de enrutamiento de mensajes entre los servicios participantes y losconsumidores [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. 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 dedesarrollo. Su objetivo es garantizar la producción de software de alta calidad quesatisfaga las necesidades de sus usuarios finales dentro de un horario predecible ypresupuestado. La figura 2.10 muestra la arquitectura general de RUP [9] de laAplicación PSM. Figura 2.10 Arquitectura general RUPRUP tiene dos dimensiones:El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida delproceso de medida que se desarrolla. El eje vertical representa las disciplinas, de lasactividades del grupo.La primera dimensión representa el aspecto dinámico del proceso cuando entra envigor, y se expresa en términos de fases, interacciones e hitos. 23
  34. 34. La segunda dimensión representa el aspecto estático del proceso: la forma en quese 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 iteracionestempranas, pasamos más tiempo en los requisitos, y en las iteraciones de laaplicación.¿Qué es una Disciplina? Una disciplina muestra todas las actividades que puederealizar para producir un conjunto de artefactos. Se describen estas disciplinas enuna visión general de nivel, un resumen de todas las funciones, actividades y losartefactos 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 eneste 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  Pruebas2.9.1 Modelado de negociosSe define un modelo de negocio como las soluciones generalizadas que puedenser implementadas y aplicadas en una situación problemática, y con ello eliminaruno 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 negocio2.9.1.1 Casos de uso de negociosEs un modelo de las funciones de negocio previsto. Se utiliza como un insumoesencial para identificar los roles y los resultados de la organización. 24
  35. 35. 2.9.1.2 Diagramas de actividadesSe utilizan para ilustrar las actividades. En el punto de vista externo, se utilizandiagramas de actividades para la descripción de los procesos de negocio quedescriben la funcionalidad del sistema empresarial.Los Diagramas de actividad le permiten pensar funcionalmente. Con el enfoqueorientado a objetos. Debido a que es posible describir explícitamente los eventosparalelos, el diagrama de actividades es muy adecuado para la ilustración de losprocesos de negocio, ya que los procesos de negocios rara vez se presentan enuna manera lineal y con frecuencia presentan paralelismos.2.9.1.3 Reglas de negocioSon las declaraciones de la política o las condiciones que deben cumplirse.Diagramas de objeto de negocioEs un modelo de objeto que describe la realización de casos de uso de negocio.Identificando las entidades de negocios.2.9.2 RequerimientosSon definidos como una condición o capacidad que un sistema debe cumplir. LosRequisitos se dividen en 2: requerimientos funcionales y requerimientos nofuncionales.  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 usuarioEl prototipo puede manifestarse como dibujos en papel o imágenes. 25
  36. 36. 2.9.3 Análisis y diseño2.9.3.1 AnálisisEl modelo de análisis contiene las clases de análisis. Las clases de análisis, enconjunto, representan un primer modelo conceptual del sistema. Las clases deanálisis rara vez sobreviven sin cambios en el diseño. Muchas de ellas representancolaboraciones del conjunto de objetos, a menudo encapsulados por subsistemas[13].2.9.3.2 DiseñoEs un modelo de objeto que describe la realización de casos de uso, y sirve comouna abstracción del modelo de implementación y su código fuente. El modelo dediseño se utiliza como insumo esencial para las actividades de implementación ypruebas. Se trata de un artefacto completo, compuesto, que abarca todas las clasesde diseño, subsistemas, paquetes, las colaboraciones y las relaciones entre ellos[13].2.10 Modelado de datos con UMLSe centra en la creación de tablas de las clases existentes, esto asegura todas lasclases 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ómomanejar las tablas que se crearon sobre la base de relaciones de herencia en elmodelo de clases y las clases que tomó parte en las relaciones muchos-a-muchosque se tienen que dividir en las asociaciones de las tablas. A partir de ahí el equipode diseño de bases de datos comenzará a garantizar la unicidad de las tablas y laaplicación de elementos tales como reglas de uso de restricciones sobre la base dedatos.Hay varias formas de mapear modelos. En nuestro escenario, valoraremos laaplicación y los modelos de bases de datos de diseño para el modelo de análisislógico, y vamos a mapear el modelo de diseño de la aplicación directamente en elmodelo 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 adatos en iteraciones posteriores. Se mapean las clases a tablas, los atributos a 26
  37. 37. columnas, los tipos a tipos de datos y las asociaciones a relaciones, lo que ayudaraa 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 sonpersistentes se asignarán a la base de datos, y no se pueden derivar los atributosdentro de las clases persistentes que no se asignan a las columnas. Por ejemplo, amenudo no son atributos, tales como total_ventas, que son sumas de variascolumnas de la base de datos, pero nunca son almacenados en cualquier parte dela base de datos. En lugar de almacenar el atributo, es solo un cálculo en laaplicación [14].Mapeo de las clases a tablasHay 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 maneradiferente por varias razones, incluyendo el rendimiento, seguridad, facilidad deconsulta, las preferencias del administrador de la base de datos, estándarescorporativos, las necesidades específicas de la base de datos, u otros motivos quepueden haber experimentado. También hay algunas asignaciones que se producensobre 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 lasrelaciones uno-a-muchos mediante la creación de una tabla de asociación. Es unabuena práctica tener columnas adicionales en una tabla de asociación por encimade las claves externas basadas en las relaciones con las tablas de los padres. Si nose tiene la necesidad de columnas adicionales, por lo general no es necesaria larelación de muchos a muchos y sólo se puede crear una relación uno-a-muchos oun cuadro adicional que no es realmente una tabla de asociación. Si una tabla deasociación que existe en el modelo de datos y contiene columnas, además de laclave externa, debe haber una clase de asociación relacionadas en el modelo deanálisis lógico. Una ventaja de usar UML sobre las notaciones tradicionales de laentidad-relación (ER) para el modelo lógico es el soporte para una clase deasociación al mismo tiempo que muestra la relación de muchos a muchos como seve en la figura 2.11 [14]. 27
  38. 38. Figura 2.11 Relaciones muchos a muchosElementos 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 lafigura 2.12 [14]. 28
  39. 39. Figura 2.12 Diagramas para el diseño de la base de datos2.11 ConclusiónEste capítulo ha servido a entender el funcionamiento referente a los modeladosde la aplicación PSM, es decir RUP, SOMF, y la arquitectura orientada a servicios. 29
  40. 40. Capítulo 3Análisis de requisitos3.1 IntroducciónAntes que nada al desarrollar una aplicación es necesario analizar el problema, parapoder ofrecer una solución y así resolver el problema. Es por ello que en estecapítulo se muestra la historia de Usuarios, gracias a las historias de usuarioidentificamos los puntos clave de la aplicación PSM.3.2 Historias de usuarioLa pollería san Manuel (PSM), es un negocio de venta de pollo al mayoreo ymenudeo. Para el buen funcionamiento del negocio se requieren los servicios paraadministrar 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 ciertacantidad de pollos, para después ofrecerlos al público en general.Requerimientos de compraUn primer requerimiento es el control de existencia de pollos en la granja sanManuel, la cual no debe de tener menos de 150 pollos. Al llegar al límite deexistencia se debe notificar un mensaje de advertencia, para que se puedaprogramar en tiempo la compra de embarques de pollos con el proveedor. Estocon lleva a la necesidad de tener un control de pagos al proveedor, por lo tantosurgen otros requerimientos para el sistema PSM. Adicional a la existencia demercancía, se tienen las posibles bonificaciones por parte del proveedorgeneradas por: pago puntual, oportuno y otro. De aquí la importancia de llevar elcontrol del número del embarque, fecha del embarque, total de pollos, descripcióndel embarque, promedios, fechas de cuando se tiene que pagar cada embarque,total del precio del embarque, mortalidad. En caso de que cada pago genere unabonificación mensual mostrar el total de las bonificaciones así como la fecha ynúmeros de embarque. 30
  41. 41. Requerimientos de ventaPSM se dedica a la venta de pollo por mayoreo y menudeo a continuación sedescribirán los tipos de venta y los requerimientos del sistema PSM.Venta por mayoreoLas ventas por mayoreo consisten en la venta de 450 pollos o más. Así que serequiere el control de pagos de los clientes de mayoreo, que desglose número deembarque, año, mes, día, descripción, precio, total de pollos y promedio. Unacondición para vender es que el cliente no tenga adeudos con PSMVenta por menudeoLa venta por menudeo consiste en la venta diaria menor a 450 pollos. Dichasventas 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 YorkEste tipo de venta necesita llevar un balance general: de gastos, mortalidad eingresos. Para posteriormente tener un balance diario, semanal, mensual y anual.Se tienen que generar tickets con: descripción, cantidades, precio de venta y totalpara los clientes diariamente.Un servicio adicional de PSM son los pedidos los cuales consisten en la venta pormenudeoPedidosRequiere un servicio de pedidos de pollos, los pedidos pueden ser de mayoreo omenudeo, el cual necesita almacenar los datos de las fechas, horas, promedios,descripción, costo, total, datos del cliente y pago por adelantado. Los pedidospueden ser de los tipos mayoreo y menudeo, es decir, pueden ser varios pedidosen un solo pedido. Cada pedido es identificado por un número de pedidos onombre del cliente. 31
  42. 42. Control de gastosRequiere un servicio en el cual administre los gastos diarios, semanales, mensualesy anuales. Con la siguiente información: descripción, total y fecha.Generación de ticketsNo se puede entregan facturas, dado que es pequeño contribuyente pero si sepodrían entregar tickets con el RFC de pequeño contribuyente.ContabilidadNecesita tener un servicio en el cual pueda tener el balance general de todos losservicios. Para tener el total de gastos, adeudos, pagos realizados, control deembarques, fechas. En los periodos anuales, mensuales, semanales. Es decir unbalance general.3.3 ConclusiónEn este capítulo hemos recolectado los requisitos de la aplicación PSM. Con laayuda de las historias de usuario. Esto en un punto fundamental para poderidentificar en el siguiente capítulo los casos de uso de negocios. 32
  43. 43. Capítulo 4Modelado de negocios RUP de la aplicación PSM4.1 IntroducciónEn este capítulo se muestra el modelado de negocios de la aplicación PSM, y sedescriben los artefactos del modelado de negocios.El conjunto de modelado de negocio presenta los artefactos que capturan yrepresentan el contexto del negocio del sistema. Los artefactos de modelado denegocio sirven como entrada y referencia para los requisitos del sistema. Losartefactos 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 negocio4.2 Casos de uso de negocios4.2.1 Actores del negocio en la figura 4.1 uc Actores Dueño Trabajador Figura 4.1 Actores de negocio 33
  44. 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. 45. 4.2.3 Requerimientos funcionales caso de uso ComprarPolloAlProveedorDescripció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. 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. 47. La siguiente figura muestra el diagrama de secuencia del caso de usoComprarPollosAlProveedor.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. 48. 4.2.4 Requerimientos funcionales caso de uso VenderPollosAClientesDescripció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: MayoreoFlujos 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. 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. 50. La siguiente figura muestra el diagrama de actividad del caso de usoVenderPolloAClientes. 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. 51. La siguiente figura muestra el diagrama de secuencia del caso de usoVenderPollosAClientes. 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. 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. 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

×