1

ECCF Training 2.0

Implemental Perspective (IP)

ECCF Training Working Group

January 2011

2

Outline

Implemental Perspective (IP)

• What is the Implemental Perspective ?

• IP Enterprise Viewpoint

• IP Information Viewpoint

• IP Behavioral Viewpoint

• IP Implementation Viewpoint

• IP Technology Viewpoint

• IP Specification Overview

3

Remember our Case Study:

Molecular Annotations Service:

• We have defined the Conceptual Perspective.

• “Conceptually what purpose does this service serve?”• We have defined the Logical Perspective.

• “What are the specific capabilities and what does the data model look like?”

• Now we want to define the Implemental Perspective.

• “What would a platform specific instance of this service look like?”

4

Considerations:

• What is the Implemental Perspective?

• Implementable Perspective .

• “implementable perspective”…..not necessarily “implemented perspective”

• What is the “Platform”?

• Most specifications in the NCI CBIIT SOA Enterprise the “Platform” will be web or REST services. So we need to think at the level of WSDL/WADL and/or Schema artifacts for defining operations, messages, data types, and attributes.

5

NCI CBIIT PSM Required Artifacts

6

Viewpoints for the Implementable Perspective

• Enterprise Viewpoint• Conformance Profiles – Traceability Matrix• Technology Stack

• Information Viewpoint• Domain Information Model

• Behavioral Viewpoint• Service Interface• Sequence Diagram

• Engineering/Implementation Viewpoint• Standards• Deployment Diagrams• Sequence Diagram• Deployment and Implementation Considerations

7

Enterprise Viewpoint PSM Artifacts

• The primary artifacts generated from the Enterprise Viewpoint at the Implementable Prospective include:

• Traceability Matrix (Conformance Profile): Traces back the functional interface and information model that are tied to a particular platform at the PSM specification level to the PIM specification level. This ensures that there is no loss of functionality or information from the Implementable to Logical to PSM specification levels.

• Technology Stack: Defines the list of the approved technology platforms through which the service should be realized (i.e. defines the “platform”)

8

Conformance Profiles

• Conformance profiles enable the mapping of the functional and semantic profiles at the Logical level to that described at the Implementable level to ensure that at the Implementable level no functionality, semantics, or conformance statements described in the Logical prespective is lost.

• Example:• In the “logical” prospective we define a functional profile describing a set of required

capabilities, realized by operations, that are required. In the “implementable” prospective we must be sure that each of these operations is actually specified in the service specification. We can explicitly state which functional profiles the service is going to adhere to (the conformance profile) by mapping from one in the logical prospective directly to an interface in the implementable prospective. A set of traceability matrix artifacts will define this.

9

Conformance Profiles

Example:

10

Traceability Matrix Example

The Molecular Annotation Service explicitly defines that it will implement the MA-FP1 function profile. This functional profile was specified in the logical prospective and is now being mapped in the implementable prospective to a service interface.

11

Traceability Matrix Example

Then it maps each capability from the logical prospective to the actual operation in an interface which provides the implementable prospective of that capability.

12

Technology Stack

• Enables setting guidance and requirements to implementation teams for technology choices.

• May refer to an existing enterprise technology stack such as the NCI CBIIT Technology Stack.

• Ensures technology compatibility across other implementable prospective service specifications.

• Helps to define the “platform” for which this specification is designed to be implemented on.

• Enables top level technology changes to be reflected across a wide range of service specifications.

• May also put in service specific technology requirements or choices above and beyond a referenced technology stack.

13

Technology Stack Example

• From caGrid 1.0 as an example.

https://wiki.nci.nih.gov/display/TechStack/Technology+Stack+2010

14

Information Viewpoint Implemental Perspective Artifacts

• The primary artifacts generated from the Information Viewpoint at the Implementable Prospective include:

• Domain Information Model: Further localization of the Domain Information Model defined the Logical perspective

• Enables further refinement of the model.

• Enables specification of a transport or persistence model to used in the Implementable perspective.

• Enables localization of a model for restricting values for use in the Implementable perspective specification instance.

15

Information Model Example (Class Diagram)The model created at the Implementable Prospective can localized or restricted.

16

Information Model Example (Schema/Message Types)

Creation of XSD for representing message types.

17

Information Model Example (Localization)

• Example localization of values to a particular vocabulary (ISO21090 in this case). The Person objects attributes are being defined to be of value types defined in another vocabulary.

18

Behavioral Viewpoint Implemental Perspective Artifacts

• The primary artifacts generated from the Behavioral Viewpoint at the Implementable Prospective include:

• Service Interface: Platform specific specification of service interface.

• Should be the WSDL/URL representation of the Logical Perspective functional profiles.

• Could also contain the Java API representation of the Logical Perspective functional profiles.

• Could also contain the .NET API representation of the Logical Perspective functional profiles.

• May add extra operations to facilitate required platform specific functionality.

19

Service Interface Example (DOC)

Each interface and its operations should be specified in the PSM document so that it can easily be traced back to the Logical Prospective

20

Operation Behavior

• Example operation behavior description for the “Query” operation.

21

Service Interface Example (WSDL) for soap based services

• Basic Structure • Simple Example

22

Service Interface Example (WADL) for REST based services

• platform specific functionality.

23

Implementation Viewpoint Implemental Perspective Artifacts

• The primary artifacts generated from the Implementation Viewpoint at the PSM specification include:

• Standards: A list of standards that are applicable for the chosen platform to which the service implementation needs to adhere.

• Deployment Diagrams: Deployment diagrams define the deployment model for the given service, identify various nodes on which service will be deployed, and identify the connections between them. If there are additional deployment-specific details, they need to be highlighted as well.

• Sequence Diagrams: Sequence diagrams define the sequence of events and operation calls that the client will perform, such as to discover or invoke the service, to authenticate the service, to initiate a transaction, or to obtain a connection. The sequence diagrams should showcase the non-functional platform-level interactions only.

• Deployment and Implementation Considerations: Based on the deployment model, as well as on various non-functional capabilities, the Engineering Viewpoint can inform the service developers about various deployment and implementation considerations that need to be addressed during development.

24

Standards

• Standard Models and Vocabularies are used to localize and/or restrict the service as well as semantically anchor the data types that are being used in the service help to increase interoperability.

25

Standards

Technology standards are defining the “platform” at the Implementable Prospective level. Standards such as WSDL, WSRF, and XML (technology standards from caGrid 1.X) are used to define the platform by which this service is indented to be implemented in and operate in.

26

Deployment Diagrams

• Deployment diagrams can be used to show the high level components and how they are decoupled and communicate. The diagram may also note deployment level considerations and or requirements.

27

Sequence Diagrams

• Sequence diagrams

• A sequence diagrams can help illustrate the intended flow for using the service. For instance, if there are functional dependencies like a user must first call “register” and then “query”. Or when it is expected that a user will “login” and then “query”.

28

Deployment and Implementation Considerations

• Details about errors.

29

Deployment and Implementation Considerations

• Deployment details.

30

Deployment and Implementation Considerations

• Security details.

31

Implementable Prospective Artifacts

• The primary artifacts-generated Technology Viewpoint at PSM specification include:

• Implementation Considerations

32

Case Study: Molecular Annotation Implemental Perspective

• One final Look at a complete Implementable Perspective and all its artifacts in the submitable template.

• https://wiki.nci.nih.gov/display/EAWiki/NCI+Enterprise+Services+Inventory+Blueprint

Exercises

• 1. Create Conformance Profile

• 2. Create Traceability Matrix

• 3. Create Operation Behavioral Descriptions

• 4. Create 21090 Localized Schema Model

33