An investigation of modelling and design for software service applications

Abstract

Software services offer the opportunity to use a component-based approach for the design of applications. However, this needs a deeper understanding of how to develop service-based applications in a systematic manner, and of the set of properties that need to be included in the ‘design model’. We have used a realistic application to explore systematically how service-based designs can be created and described. We first identified the key properties of an SOA (service oriented architecture) and then undertook a single-case case study to explore its use in the development of a design for a large-scale application in energy engineering, modelling this with existing notations wherever possible. We evaluated the resulting design model using two walkthroughs with both domain and application experts. We were able to successfully develop a design model around the ten properties identified, and to describe it by adapting existing design notations. A component-based approach to designing such systems does appear to be feasible. However, it needs the assistance of a more integrated set of notations for describing the resulting design model.

A service‐oriented method for domain and business process modelling

“…Anjum and Budgen 23 presents an investigation on the modelling of service‐based software applications, trying to answer to the following research questions: RQ1: What properties of software services need to be represented and modelled for the design of software service applications? RQ2: How well can existing software design notations be used to describe the properties identified in RQ1? …”

“…The answer to RQ1 23 is the list of features presented below; in the round parentheses, we state how and if they are considered by our ‘conceptual model of service‐oriented domains’ reported in Figure 1: Architecture (service architecture) Binding: The time at which a particular service, and provider, is chosen (our proposal is at a conceptual level, implementative details are not considered) Capability: The purpose of an SOA as viewed from an end‐user perspective (service semantics) Composition: The process by which a given set of services are assembled in order to provide a single overall service that meets an end‐user need (a service may be provided by using other services) Contracts (service contract) Delivery (definition of the behaviour of the service provider) Distributed Sources (full decoupling between service provider and service user) Identity (service name) Interoperability (our proposal is at a conceptual level, implementative details are not considered) Packaging: The characteristics of service implementation that enable it to be treated as a unique and distinct identity (definition of the service) …”

“…Concerning the notation given, 23 they propose to use many different diagrams, some provided by UML (i.e., Class, Component, Activity and Sequence Diagram) plus Data flow and Flow Chart, to fully model a service based system, and say ‘we can conclude that it is not essential to devise new notations for modelling the properties of service‐based systems, there might well be some benefits from rationalising and improving upon the ones that were used’. We agree on this point, but we believe that it is better using only one modelling language; thus, Precise SOM is based on UML diagrams, or better on a subset of its diagrams.…”

Consolidating Service Engineering Ontologies : Building Service Ontology from SOA Modeling Language (SoaML)

“…As an attempt to consolidate the non-orthogonality of competing SOA concepts, a literature survey on SOA concepts is performed in [1]. Nine core identifiers which characterize a service-orientation were extracted: (1) architecture, (2) binding, (3) capability, (4) composition, (5) contract, (6) delivery, (7) distributed sources, (8) identity, and (9) interoperability.…”

“…From these previous works, selected concepts that can be considered as a potential component for targeted ontology are: (1) architecture, mostly for software level abstraction, (2) binding, related to 'role' concept, (3) capability, as user perspective of business function, (4) composition, related to atomicity or composite nature of service, and (5) contract, as terms and conditions agreement of a service. Additionally, [9] suggests that service structural model is consisted of: (1) service operation, (2) service component, and (3) service interface.…”