Los servicios pueden ser llamados también métodos o procedimientos y son una parte importante de los objetos así como los son sus atributos. Debido a que los servicios involucran frecuentemente cambios en el estado de un objeto, son comúnmente analizados y diseñados usando diagramas de estado.
El análisis de servicios consiste de tres actividades:
1.
Análisis del estado del objeto: Existen atributos en cada objeto que pueden afectar su cambio de estado, es importante por tanto en este análisis encontrar esos atributos. Es recomendable preguntarse en estos casos ¿Cambiará el comportamiento del objeto cuando cambie el valor de este atributo? Si ningún atributo logra causar tal efecto en el objeto, pueden haber ciertas condiciones que hagan que el objeto cambie su comportamiento, en estos casos podría ser útil añadir un atributo de “estado”. Por ejemplo si analizando un carro de tren que tomará y dejará pasajeros, se sabe que el tren debe comportarse diferente en reacción a un mensaje “descargar pasajeros”, dependiendo de si el tren está detenido en una plataforma de estación o está en movimiento. Para tal objeto tren con una variable de estado, se puede representar un diagrama que se vería así:
La flecha en la parte superior del cuadro Estado = detenido muestra que el estado inicial cuando el objeto es creado es siempre detenido. Las otras flechas muestran cambios de estado posibles, por ejemplo, de detenido a en movimiento o de detenido a descargando. No hay forma para cambiar estados de en movimiento a descargando. Esto previene lógicamente que el objeto descargue pasajeros mientras está en movimiento. Los diagramas de estado son añadidos conforme se necesita a las plantillas de especificación para documentar tales atributos de estado.
2.
Especificación de servicio: Los servicios pueden ser de dos tipos, simples o compuestos. Los servicios simples involucran muy pocas condiciones u operaciones, y frecuentemente se aplican a cada Clase y Objeto en un sistema. Estos incluyen servicios tales como crear objetos, almacenar objeto, recuperar objeto, conectar objeto (hacer una ocurrencia de conexión), y acceder objeto (obtener o poner los valores de los atributos) y borrar objeto. Los servicios simples son implícitos, a veces especificados una sola vez en el diseño y nunca vueltos a mencionar. Algunas veces incluso estos servicios no se mencionan en el diseño por ser muy obvios por lo que se les deja a los programadores que los construyan cuando los necesiten durante la implementación.
Los servicios complejos en cambio involucran ciclos, muchas operaciones o condiciones compuestas. Estos servicios por lo general se aplican a una Clase y Objeto. Los servicios complejos pueden ocasionar servicios “compañeros” o “privados” que son similares a los módulos de subrutina. Los servicios privados son subrutinas internas, de las cuales solo el objeto mismo sabe y puede activar. Los servicios compañeros son subrutinas usadas por servicios complejos, y también pueden ser activadas como servicios distintos por mensajes de otros objetos del sistema. Los nombres de tales servicios aparecen en la sección inferior de los cuadros de clases. La figura a continuación muestra tres servicios, Mover en el objeto Vehículo, Emer.Paro en el objeto Sis Operativo y Emer.Paro en el objeto Base de Datos. Se pueden usar diferentes herramientas para representar estos servicios, tales como diagramas de flujo de programas, diagramas Warnier-Orr, tablas de decisiones o español estructurado.
3.
Especificación de mensajes: Los mensajes detallan la manera en que el comportamiento de un objeto puede activar el comportamiento de otro objeto, esto con el fin de documentar la dependencia de un proceso sobre otro proceso en un objeto diferente. Los mensajes existen solamente para comunicarse entre servicios, y ocasionan flujo de control y flujo de datos.
Los mensajes dirigidos a las clases, tales como crear objetos y borrar objeto, por lo general no son diagramados por que están implícitos en los servicios simples. Por tal razón los mensajes que sí se diagraman terminan siendo de objeto a objeto, y no de clase a clase o de objeto a clase. Los mensajes se representan por flechas direccionales como es el caso de las figuras del ejemplo anterior. Se puede notar en la parte inferior de la figura que un objeto le envía un mensaje a dos objetos, esto es lo que hace el objeto Operador, envía un solo mensaje que activa el comportamiento de paro de emergencia (Emer.Paro) en los objetos Base de Datos y Sis Operativo simultáneamente.
Debido a que los mensajes detallan servicios complejos, se alinean con el servicio emisor y el servicio receptor, sin embargo los servicios complejos son escasos en los sistemas y por consiguiente también los mensajes en el diagrama. De esta manera se resaltan las funciones realmente importantes del sistema. Los servicios complejos que no son activados por mensajes, tienden a ser activados por eventos temporales o interacción humana como es el caso de las clases sin mensajes de entrada.