Lecture 3: Service Identificiation

Question 1

What are the main ingredients of services?

Answer 1

• Service contracts

- Messages

Question 2

What is a service contract?

Answer 2

• quality requirements: reliability, security, performance
• other non-functional properties: platform characteristics, legal constraints, safety regulations.
• Tacit design decisions: insurance companies might assume 1e january as start date of policy contracts.

Question 3

What are massages?

Answer 3

Properties of data exchanges: like data structures, protocols.

Question 4

Conceptual service

Answer 4

service that is not yet implemented, can be either a software service or not

Question 5

service candidate

Answer 5

conceptual service identified during analysis and candidate for software design

Question 6

service operation candidate

Answer 6

a service operation identified from functional requirements; it might become a service candidate itself, or be composed in a service candidate

Question 7

business service

Answer 7

is an self-contained business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface.

During service identification, the elicited business services become the service candidates for the software design phase. They might be service operation cahndidates.

Question 8

Task service

Answer 8

service that mainly executes a functionality

Question 9

entity service

Answer 9

service that mainly manages, and offers acces to, a data resource

Question 10

utility service

Answer 10

domain- or application idependent service offering access to generic funtions or generic data resources

Question 11

hybrid service

Answer 11

mix of task service and entity service

Question 12

What is service oriented (SO) analysis?

Answer 12

The process of determining how business requirements can be represented through service.

Question 13

What are the SO analysis steps?

Answer 13

0. Model business domain 
•  from the study of the domain and supported usage scenarios: participants and their relations, which will be potentially supported
1. Identify business services and service operation candidates
•  from the target business domain: this can be the list of functional requirements (topdown development) or (if provided) directly the list of business functions
•  from functional models of pre-existing systems (SO migration)
2.  Model service candidates
• aggregate service operation candidates into service candidates
• to do so, recognize overlaps (see next slides)
3.  Model context for service candidates
•  Combines modeled business domain and service candidates
•  In doing so, usage within and across stakeholder domains is made explicit
UML activity diagrams (behavior), UML use case diagrams (decomposition + context model); UML class diagrams (data + business domain)