SOAROAD ontology Component properties Property

Ontology of architectural decisions supporting ATAM based assessment of SOA architectures Piotr Szwed, Paweł Skrzyński, Grzegorz Rogus, Jan Werewka Department of Applied Computer Science AGH University of Science and Technology

Agenda

• Introduction: – Motivation – ATAM

• Proposed approach • SOAROAD ontology: – Foundational model – Selected classes: properties, quality attributes and design patterns

• Concept of application • Conclusion 2

Introduction SOA • Service-oriented architecture (SOA) – a standard for enterprise software. • Ingredients: – – – – –

Web services Design patterns Enterprise Service Bus (ESB), Service orchestration and choreography Various security standards.

• Growing popularity of SOA • Rapid development of new technologies and platforms • Expected business value 3

Introduction ATAM

• The ATAM is a mature method for architecture assessment proposed by SEI • The ATAM defines – a quality model based on scenarios and – an organizational framework for the evaluation process.

• During the evaluation a team of experts analyzes selected properties of the input architecture to detect sensitivity points, tradeoffs and to assign risks to the scenarios. 4

Introduction Motivation • Sources of input information: – architectural views – interviews with stakeholders.

• Problem 1: What to ask for? – Depends on expert’s knowledge – Not reliable if conducted by an inexperienced evaluator

• Problem 2: How to represent architectural decisions? – – – –

Narrative form Spreadsheet Checklist Formalized shareable representation 5

Proposed approach SOAROAD ontology • We propose to use an ontology suporting ATAM based assessment of systems following service-orientation paradigm – gathering knowledge about various properties and decisions related to SOA. – capable to represent assignments of properties to elements of system architecture.

• Expected outcomes: – facilitate performing an assessment in more exhaustive manner – helping to ask questions, – revealing implicit design decisions …. in consequence obtaining more reliable results 7

SOAROAD ontology Building steps 1. A foundational model serving as the ontology skeleton was proposed. 2. We manually gathered and analyzed information related to service oriented architectures, technologies, architectural approaches, design patterns, etc. originating from various sources: books, technical papers, reference manuals and Internet resources. 3. The ontology was populated with this information by translating intermediate textual description into OWL constructs. At present the ontology consists of 110 classes, 9 object properties (not counting roles in design patterns) and 105 individuals. 8

SOAROAD ontology Foundational Model -is_described_by

DesignPattern

* 0..1 -property

CompositionProperty

*

*

-connections

*

-property

Connection

*

1 *

-influences

ConnectionProperty

*

*

-influences

QualityAttribute

* -influences * -influences

*

*

Composition 1 1 1

-calee

Funnction

1

Interface

-property

InterfaceProperty

-interface -functions

1

*

*

*

* -caller 1 -components

* -property

Component

*

ApplicationComponent

1 1

*

ComponentProperty *

InfrastructureComponent

9

SOAROAD ontology Properties 1

• Properties are reified, i.e. they are represented by classes. • The ontology comprises a set of predefined individuals of particular properties. They can be used as decision values. Example: JavaEECompliantAS has several individuals: JBoss, Glassfish, WebLogic, Web-Sphere, ColdFusion, etc. 11

SOAROAD ontology Properties 2

12

SOAROAD ontology Component properties Property (values)

Description

PlatformTechnology (CORBA, EJB, JINI, RMI)

A set of technologies used on the platform.

ComponentLogic (flexible, fixed, rulebased)

Specifies the approach to the component logic implementation.

Platform

Defines the component platform. Has several subclasses: ApplicationServer, Hardware, OperatingSystem and VirtualServer

ProgrammingLanguage (Cpp, Java, Ruby, PHP, Erlang, Python, C, C_sharp )

Defines the programming language used to implement a component.

StatePersistence (Stateless, Statefull)

Specifies whether a component saves internal data during and in between calls of operations on the client’s behalf. 13

SOAROAD ontology Properties related to a platform Property (values)

Description

ApplicationServer

Subclass of Platform. Defines an application server on which a component is deployed, can have such attributes, as: version (string), vendor (string)

JEECompliantAS (TomEE, Glassfish, JBoss, Interstage, JOnAS, Geronimo, SAPNeatWeaver, WebSphere, Resin, ColdFusion, WebLogic )

Subclass of ApplicationServer dedicated to JEE compliant components.

DotNetCompliantAS (AppFabric, IIS, TNAPS, Base4, Mono)

Subclass of ApplicationServer; its individuals define products for .NET enviroment

JavaAS (Jetty, Enhydra, iPlanet)

Application servers for Java environment

Hardware

Subclass of Platform. Used to specify a hardware configuration on which the component is deployed. Attributes: memory (double), processor (string), number_of_cores (int)

OperatingSystem (Windows, Unix, Linux, iOS, Android, Bada, Blackberry)

Subclass of Platform. Defines types of operating systems on which a component is executed. Attributes: version (string), vendor (string), product (string)

VirtualServer (no, yes)

Subclass of Platform. Specifies whether a component 14 is deployed on a virtual server

SOAROAD ontology Additional relations * * -requires *

CompositionProperty

ComponentProperty

-supports * Property

-properties *

ConnectionProperty

Conflict *

InterfaceProperty

Reasoning about implicit decisions and inconsistency in design: • The supports relation indicates that particular elements can be used together, e.g. JBoss (ApplicationServer) supports Document.Literal (SOAP web service style). • Conflict objects (reified multirole properties) indicate sets of properties, which should not be used together, provide specification of conflict levels (e.g. partially_compatible, incompatible, error_prone) and textual description (rationales) . • The required relation can be used to specify that one element requires another.

15

SOAROAD ontology Quality Attributes

16 A partial tree of quality attributes (according to ISO/IEC 9126 and ISO/IEC 25010)

SOAROAD ontology Design Patterns 1 Design patterns are proven solutions to a common problems, usually individually documented in a consistent format and being a part of a larger collection. [http://soapatterns.org] -is_described_by

CompositionProperty

DesignPattern

-property

Composition

-components

Component

model

dp.ModelViewControler

view controler Roles of components (object properties) defined by the design pattern. 17

SOAROAD ontology Design Patterns 2

18

SOAROAD ontology A concept of application ArchiMate Import Tool Architecture Views (ArchiMate)

SOAROAD ontology TBox

OWL Java

imports

(OWL)

Jena

SOAROAD ontology ABox: predefined values (OWL)

imports

Web based architecture Description Tool

 Architecture views (components, connections, interfaces) are converted into an ABox

Architecture Views ABox

(OWL)

 They are attributed with design decisions classified in the ontology

JSF

TDB Jena

Designers and development teams

imports imports

Architecture Views ABox enriched by desing decisions (OWL)

 The resulting ontology serves as a detailed architecture documentation 19

Example An architectural view in ArchiMate language

• • •

Data Base with the SQL interface, Three Java beans: Announcement JPA, Business Logic and the Facade providing Announcement WS – web service based interface. Announcement JSF Presenter being responsible for presentation and interaction with end users. 20

Example Ontology content (ABox: views + decisions) ExcptH.soapFault OS.Ubuntu10.4

Comm.async

Announcement Facade

-interface

Announcement WS

Security.SSL

StatePers.stateless

-caller -callee

WS Presenter Connection

Ann. JSF Presenter

J2EEAS.GlassFish Netw.10GB

WSType.SOAP

HwA

JBoss

QGranularity.low -number_of_cores

8

• •

• •

-processor

Xeon 2.13GHz

-memory

4GB

Announcement Facade is deployed on Intel Xeon 2.13 GHz machine running Ubuntu 10.4 system and GlassFish application server. Announcement WS is a SOAP web service with the interface of a low query granularity and the exception handling based on soap faults. WS Presenter Connection is asynchronous, uses the SSL based protection mechanism and the 10Gb network. Announcement JSF Presenter is deployed on JBoss application server and 21 is stateless.

Example Discussion

• Missing property assertion for an element, means that nothing is known about the assignment. • A lack of decision is represented explicitly by an individual (constant), e.g. OperatingSystem.not_decided • As conflicting decisions of the same type can be attributed to a component, some kind of validation is required (e.g. with additional SWRL rules)

22

Conclusion and Outlook Planned works

• Ontology: classification of design patterns • Gathering and encoding specific knowledge related to confilicts in architectural decisions, depenedencies and influences on defined quality attributes • Using SWRL rules for checking consistency of architectural decisions • Using SWRL rules to perform (fuzzy) reasoning on infuences • Development of the architecture Description Tool (as a M.Sc. Project) 23

Conclusions • Architecture assessment must have solid foundations in a knowledge related to a particular domain. • The idea: to gather experts knowledge to enable even inexperienced users to perform ATAM-based architecture evaluation.

• SOAROAD results in a joint representation of architecture views and properties attributed to design elements. • Such centralized information resource represents a valuable artifact of software development, which can provide further reference to design decisions.

24

Thank you

25