• 沒有找到結果。

D ESIGN P RINCIPLE OF S ERVICE O RIENTED M ODELING

CHAPRT 3.   A FUZZY TOPSIS METHOD FOR WEB SERVICE SELECTION

3.3.   D ESIGN P RINCIPLE OF S ERVICE O RIENTED M ODELING

System development from analysis to implementation needs to conquer many roblems which might come from end-user, computer, or designer. For example, in the phase of analysis, a designer needs to find out the ent. The req

ent defines scale, quantity, and function of all hardware and software. For example, the number of lights, air-condition units, dehumidifier or heater, etc. The comfort requirement is related to users’ preferences which are about QoS.

The requirements collected from the previous phase lay the foundation for modeling the required services. An analyst can use any modeling language such as

r r mo pecify

service flows, service relations, and service capabilities.

p

users' requirem

uirements can be separated into two types: functional requirement, and comfort requirement. Functional requirem

UML to model the requirements. Because some of the service-oriented features cannot be satisfied with UML, it equires anothe deling language to s

Figure 11 Three phase of Service Modeling Architecture

In our propose framework, we distinguish two types of requirements which are functional requirem

wn in Figure 12.

Figure 12 Service-Oriented Modeling Approach architecture

Our proposed User Centric Service-Oriented Approach provides a top-down modeling analysis method. As mentioned above, we combine MDA concepts in the software design and system implementation with web services. The requirements can be separated into two types: functional requirement, and comfort requirement.

Functional requirement defines scale, quantity, and function of all hardware and ition units, dehumidifier or heater. The comfort requirement is related to users’ preferences which are about QoS.

ent and comfort requirement in initial phase. After analysis phase, the users can use any tools or modeling language which they are familiar with to model the system. Here, we adopt the service-oriented modeling framework (SMOF) as a modeling framework. In PIM to PSM phases, we use Service Component Architecture (SCA) as transforming methodology. Also in PSM phase, we use the Service Data Object (SDO) to manipulate the connection between application and the database. Our proposed framework is based on MDA that includes SPEF and MOF. The overall architecture is sho

software. For example, the number of lights, air-cond

PSM

The requirements collected from the previous CIM phase lay the foundation for modeling the required services. An analyst can use any modeling language such as UML to model the requirements. Because some of the service-oriented features cannot be satisfied with UML, it requires another modeling language to specify service flows, service relations, and service capabilities. Hence, we adopt Service-Oriented Modeling Framework (SOMF) in the PIM phase. SOMF is a discipline of modeling business functions and system behaviors based on services.

In PSM phase, the main task is to draw SCA diagram and obtain a system meta-model. After that, the SDO (Service Data Object) and ESB (Enterprise Service Bus) can connect to database and bind services together. SDO aims to provide a consis eans of handling data within applications, regardless of its source and format. It provides a unified way of handli

used to integrate applications, coordinate resources, and manipulate information. The proposed architecture is depicted in Figure 13.

tent m

ng data of databases and services. ESB is

Figure 13 Life-cycle of our proposed service-oriented approach

The limitation of our proposed method is the services need to be given in advance without generating automatically. Our proposed method can be applies in any specific domain where service selection is made based on the independent feedback which represent the quality rating of the service content (QoS). The user centric service-oriented modeling framework (see Figure 14) and procedure (see Figure 15) presented as following.

Figure 14 User Centric Service-Oriented Modeling

Figure 15 Procedure of our proposed method

In the end, we summarize the design principle and guideline that concern about user centric and service-oriented modeling as following.

(1) Services-Oriented Modeling:

It can reduce the deficiency of object-oriented modeling in service-oriented applications, as UML meta-model cannot provide the necessary support. Designer could adopt Service-Oriented Modeling Framework (SOMF) which is a discipline of modeling business functions and system behaviors based on services. Designer needs to identify service, define the specification of service, and implementation service.

Identify service:

In service-oriented environment, software and hardware can be represented as services. Services are more transparent and loose coupled, which contain a collection of independent functions or operations as compared to objects. Objects heavily reply on their interdependencies and their internal states to operate.

Define the specification of service:

Regarding to the existence application or new services from the business domain nd the atomic business activity. Constructing service component or referencing external service can be achieved by drawing SCA diagram and obtain a system meta-model.

Implementation service:

SDO (Service Data Object) and ESB (Enterprise Service Bus) can connect to database and bind services together. SDO aims to provide a consistent means of handling data within applications, regardless of its source and format. It provides a unified way of handling data of databases and services. ESB is used to integrate applications, coordinate resources, and manipulate information.

(2) User Behavior:

A ICT system based on SOA possesses abilities such as autonomous adjustment, a

aut

oach collects the preferences from to provide a basis for system self-adjustment in ord

er. The sensor devices and their sensed data can be grouped tog

stics. This can benefit

loc rces.

onomous management, and autonomous deployment to satisfy diverse requirements from multi-user. The group consensus appr

the users and reason over them

er to meet the majority of users’ requirements. The alternatives and criteria should be given by such system that could offer the ability of group consensus computation.

(3) Annotating sensor data with semantics:

Sensor data could be value of temperature, humidity or an expression representing other conditions, but this data could imply a condition such as light brightness or weath

ether to become services and annotated with semantics for reasoning.

(4) Information Streams Fusion and resource description:

The resource including data, services, computation resource, and device profile will be described explicitly with their location and characteri

ating, allocating and re-deploying resou

相關文件