Towards an Ontology Approach to ATAM Based Assessment - AGH

13
AUTOMATYKA/ AUTOMATICS 2012 Vol. 16 No. 2 175 http://dx.doi.org/10.7494/automat.2012.16.2.175 * AGH University of Science and Technology, Krakow, Poland Piotr Szwed*, Grzegorz Rogus*, Pawe³ Skrzyñski*, Micha³ Turek*, Jan Werewka* Towards an Ontology Approach to ATAM Based Assessment of Service Oriented Architectures 1. Introduction In this paper we describe SOAROAD (SOA Related Ontology of Architectural Deci- sions), which was developed to support the evaluation of architectures of information sys- tems using SOA technologies. The main goal of the ontology is to provide constructs for documenting service-oriented architectures, however, it is designed to support future reaso- ning. Building the ontology we focused on the requirements of the Architecture Tradeoff Analysis Method (ATAM). ATAM is a scenario-based method for architecture assessment defining a quality mo- del and an organizational framework for an evaluation process. ATAM represents expected system qualities as a mapping between scenarios and quality attributes. System architecture being the input for ATAM is expressed in the form of views describing components and their connections. During the evaluation a team of experts analyzes selected properties of components and connections to detect sensitivity points, tradeoffs and assigns risks. A limitation of the method is that it depends on expert knowledge, perception and previous experience. It may easily happen, that an inexperienced evaluator overlooks some implicit decisions and risks introduced by them. We propose SOAROAD ontology as a tool supporting the ATAM based assessment of systems following a service-orientation paradigm and deploying web services. The ontology gathering knowledge about various properties and decisions related to SOA may facilitate performing an assessment in a more exhaustive manner, helping to ask questions, revealing implicit design decisions and obtaining more reliable results. 1.1 Architecture evaluation why SOA? Nowadays, Service Oriented Architecture (SOA) might be treated as a state of the art approach to the design and implementation of enterprise software, which is driven by business requirements. In the SOA paradigm, the system is made up of loosely connected

Transcript of Towards an Ontology Approach to ATAM Based Assessment - AGH

Page 1: Towards an Ontology Approach to ATAM Based Assessment - AGH

������������������� �����������������

���

���������� ��!"����#$#%&��'%���������������

( �)*�+ ,-!. �/�0 1 -+1-%+��-1�+���"/2�!%3�425��%+�

5 ��! 64-�(2)!6-"�!67�"&.(25%4-8 3!6/9.3 (2� 1�%8�&!-3(2:%+;-!-43%(

����������� �����������������

�������������������������������������������

������������

In this paper we describe SOAROAD (SOA Related Ontology of Architectural Deci-sions), which was developed to support the evaluation of architectures of information sys-tems using SOA technologies. The main goal of the ontology is to provide constructs fordocumenting service-oriented architectures, however, it is designed to support future reaso-ning. Building the ontology we focused on the requirements of the Architecture TradeoffAnalysis Method (ATAM).

ATAM is a scenario-based method for architecture assessment defining a quality mo-del and an organizational framework for an evaluation process. ATAM represents expectedsystem qualities as a mapping between scenarios and quality attributes. System architecturebeing the input for ATAM is expressed in the form of views describing componentsand their connections. During the evaluation a team of experts analyzes selected propertiesof components and connections to detect sensitivity points, tradeoffs and assigns risks.

A limitation of the method is that it depends on expert knowledge, perception andprevious experience. It may easily happen, that an inexperienced evaluator overlooks someimplicit decisions and risks introduced by them.

We propose SOAROAD ontology as a tool supporting the ATAM based assessment ofsystems following a service-orientation paradigm and deploying web services.

The ontology gathering knowledge about various properties and decisions related toSOA may facilitate performing an assessment in a more exhaustive manner, helping to askquestions, revealing implicit design decisions and obtaining more reliable results.

������������������ ����� ������!

Nowadays, Service Oriented Architecture (SOA) might be treated as a state of theart approach to the design and implementation of enterprise software, which is driven bybusiness requirements. In the SOA paradigm, the system is made up of loosely connected

Page 2: Towards an Ontology Approach to ATAM Based Assessment - AGH

��� 5 ��! 64-�2)!6-"�!67�"&.25%4-8 3!6/9.3 2� 1�%8�&!-32:%+;-!-43%

services, which constitute components that can be reused many times and may occurin various compositions. The characteristic features of software developed in line withthe SOA are as follows:

< ��-%= � �/��1%��&�.-!, 1-.!-"%!��-..�0��-�-1�+���"/%+�+-�4�!3��1%� �+>

< �+-���+-1�''&+ 1%� �+.�%��+-'�'-+� +� '-2��-.-!, 1-1�+.&'-!1%+1%��&�

�+�/�+-.-!, 1-24�-!-%.��-1�''&+ 1%� �+ .�4�4%/>

< ��-0��4 . + � %�-�=/��-.-!, 1-1�+.&'-!<.-!, 1-1%��&�>

< /+1�!�+�&. 1�''&+ 1%� �+�

Another paradigm is the EDA (Event Driven Architecture) in which applications andservices exchange events in an asynchronous way one with another. EDA systems are oftencalled event-oriented SOAs: this paradigm represents an extension of the SOA and notits competitor thus this is complementary to SOA approach. The characteristic features ofthe EDA architecture are as follows:

< ��''&+ 1%� �+ + 4� 1� .�&!1-. �0 -,-+�. %!- +�� %4%!- �0 ��- -� .�-+1- �0 -,-+�

!-1 � -+�.>

< �%+/��'%+/1�''&+ 1%� �+��+--,-+�1%+=-1�+.&'-�=/'%+/.&=.1! =-!.>

< ?��4 + � %�-�=/��-=&/-!�-�-+� +"�+��--,-+��/�->

< �./+1�!�+�&. 1�''&+ 1%� �+�

Interestingly, from the implementation perspective, both architectures can use the samedesign pattern – the ESB (Enterprise Service Bus). This pattern combines both approaches,which makes integrating business modules and different platforms significantly easier. TheESB plays the role of an intermediate layer, which makes possible communication betweendifferent processes. A consumer of an event can initiate every service implemented withinthe bus. The ESB provides all the capabilities determined by both paradigms and for thisreason it is the recommended [23] way of implementing the enterprise architecture withinthis approach. Hence if one aims in creating useful ontology the concept of ESB and relatedterms must be taken into consideration.

��"�#� �������$�

Ontology of architectural decisions was proposed in [16]. It distinguished by severaltypes of decisions that can be applied to software architecture and its development process.The main categories included: Existence, Ban, Property and Executive decisions. The onto-logy defined also attributes, which were used to describe decisions, including states (Idea,Tentative, Decided, Rejected, etc.). In [9] an ontology supporting ATAM based evaluationwas proposed. The ontology specified concepts covering the ATAM metamodel, qualityattributes, architectural styles and decisions, as well as influence relations between elementsof architectural style and quality attributes. The effort to structure the knowledge aboutarchitectural decisions, was accompanied by works aimed at the development of tools ena-bling edition and graphical visualization of design decisions, often in a collaborative mode,e.g. [4, 7, 17].

Page 3: Towards an Ontology Approach to ATAM Based Assessment - AGH

��4%!�.%+�+����"/���!�%1�������@%.-��..-..'-+���� ���

This short selection of works proves, that the problem of documenting and visualizingarchitectural decisions as a support for software development process and architecture eva-luation remains a challenge. In contrast to approaches aimed at providing the classificationof concepts and their relations (TBox) we attempt to gather in the proposed ontology alsofacts (ABox) constituting ready to use dictionaries of decisions (properties of architecturaldesign) and the knowledge about their relations reflecting the current state of the art forSOA technologies.

��%�������������

ATAM (Architecture Tradeoff Analysis Method) [15, 6] is an early scenario-basedmethod for software architecture evaluation developed at SEI (Software EngineeringInstitute). Considering many different quality goals ATAM is capable of capturing theinteraction between them, setting goal dependencies and assessing that a proposed systemarchitecture can satisfy those goals. The ATAM process can work in a procedural loop. Eachiteration should be ended with improvement suggestions, including better architecturaldecisions and new development scenarios.

Briefly speaking, the greatest benefit from the ATAM methodology is an early identifi-cation of risks, what in consequence can result in appropriate mitigation actions introducedbefore the software is fully designed and implemented, thus at lower cost. ATAM multi-stepsystem analysis procedure includes detailed risks filtration, sorting and risk reducing pro-cesses. In the first place each risk is classified into particular risk themes. So-called impacts,extracted from those risk themes, are afterwards linked with business drivers or an architec-tural plans. If one of risk theme impacts requires a new business driver definition, a set ofquality attributions is made. That also leads to a new scenario developed, which should beconsidered during the next iteration of the process: a scenario of interaction of one ofthe (so called) stakeholders with the system. On the other hand, when any risk theme impactrequires a new architectural plan definition (instead of a business driver), an architectureapproach (or approaches) is being created for subsequent software architecture change.

The ATAM process also includes development team interactions. The whole ATAMprocess usage typically includes the following steps:

< �-�. �<A�5!-.-+�%� �+ B���� +�!��&1� �+'%�-=/ %+ -,%�&%� �+ �-%�-!2 =&. +-..

�! ,-!.��=-1�+. �-!-��-.1! =-�=/�!�C-1�.��3-.�-!.�+%+��!-.-+�%!1� �-1�&!-��

=- -,%�&%�-� < �-.1! =-� =/ % ./.�-' %!1� �-1� 4 �� % !-0-!-+1- �� 1&!!-+� =&. +-..

�! ,-!.� .�D2

< �-� #� �!1� �-1�&!%� %��!�%1�-. �-+� 0 1%� �+ < 1&!!-+��/ &.-! %��!�%1�-.2 4 ���&�

%+%�/. .2

< �-���E&%� �/%��! =&�-.1���-1� +"�������.-%��! =&�-..��&��=-"%��-!-� +%+%��! F

=&�-&� � �/�!--���4 ���-.1! =-1�'�!�' .-.=-�4--+./.�-'&� � �/�%!%'-�-!.2.&1�

�-!0�!'%+1-2.-1&! �/2&.%= � �/2%,% �%= � �/-�1�2

< �-����!1� �-1�&!%�%��!�%1�-.%+%�/. .<&. +"3+�4�-�"--.�%=� .�-� +.�-��2

< �-��� 1-+%! �.�! �! � 6 +"�&! +"%,�� +"�!�1-..2

Page 4: Towards an Ontology Approach to ATAM Based Assessment - AGH

��G 5 ��! 64-�2)!6-"�!67�"&.25%4-8 3!6/9.3 2� 1�%8�&!-32:%+;-!-43%

< �-�G��!1� �-1�&!%�%��!�%1�-.%+%�/. .<.�-��!-�-� � �+2=&�4 ��%.1-+%! ��! �! F

� -.3+�4�-�"-&.-�2

< �-�$�!-.&��.!-.��, +"�

As shown above, ATAM provides the necessary techniques supporting the optimiza-tion of software architecture. There are also different types of scenarios in ATAM: classicaluse case scenarios are extended by growth scenarios (showing changes made to the system)and exploratory scenarios (for extreme changes possibly hazardous to the system). TheATAM approach provides a way to deal with multiple and strongly dependent parametersbound to a different system architecture requirements and also generating different risks.Making a risk dependency tree helps to identify sensitivity points and tradeoffs points(bounded multi-attribute points). It will also refine any descriptions of the architecture’sdriving quality attribute requirements and architectural design decisions.

A great advantage of ATAM would also be another mechanism. This one providesefficient business drivers translation into quality attribute scenarios. It is based on structurescalled utility trees. Those trees would allow determining important business issues and re-strictions identifying high priority goals for future system architecture. The root of a tree(simple utility entry) leads into branches such performance, modifiability, availability, secu-rity etc. Each branch leads to detailed and decomposed information about all architecturefeatures needed to be applied to meet the assumed requirements. Therefore (due to thegraphical display of a tree) all the effort to meet enforced requirements could be balancedbetween business restrictions displayed on the utility tree branches.

"���������� �����������������������

The basic model of software architecture used in ATAM [2] defines it after [20] as a setof components and linking them to connections. We extend this simplistic model by defi-ning Interfaces and Functions of components. A connection links a component havingthe caller role with an interface (calee). Components, connections and interfaces can beattributed with: ComponentProperties, ConnectionProperties and InterfacePropertiesrespectively. Examples of such properties are: platform, web service type, communicationtype, queueing, query granularity.

A Composition is a coherent set of components and connectors. System architecture isitself a composition. For the purpose of analysis we may focus on a particular subset ofcomponents and connectors and describe their properties, e.g. the distribution of queriesamong a several databases building up a composition or realization of a design pattern.

During the ATAM based evaluation the overall system architecture and properties ofits parts are analyzed to establish the scenario responses and achievements of correspondingquality attributes. It may be, however, observed that some architecture properties or theircombinations have known influence on quality attributes, e.g. a use of asynchronous webservices or applying MVC design pattern increases modifiability and a granularity ofqueries has an impact on performance.

Page 5: Towards an Ontology Approach to ATAM Based Assessment - AGH

��4%!�.%+�+����"/���!�%1�������@%.-��..-..'-+���� ��$

Architectural decision is an assignment of a property to a component, interface, con-nector or a composition. In this context the terms property and architectural decision can beused to some extent interchangeably. However, it may happen that certain decisions or com-ponents are dependent on previously assigned properties. An example of such dependencyis the composition type – a property assigned to a set (composition) of web service com-ponents. Selecting orchestration as the composition type requires that an orchestrationcomponent, e.g. BPEL capable module is be used. The required relation or its subpropertiesin the ontological model express this dependency.

The assumed metamodel adopts the reification strategy while modeling various pro-perties of an architectural design. Properties are defined as classes, whose individuals canbe linked by additional relations indicating specific roles. An example of such a property isthe MVC design pattern – pattern, which requires identification of a components playingthe roles of a Model (typically database), a Controller (e.g. an EJB) and a View (e.g. a set ofHTML pages produced by JSP scripts).

Two types of components are distinguished: ApplicationComponents and Infrastructu-reComponents. Application components are developed and deployed software modules;infrastructure components provide such supporting functions, as message queuing or servi-ce registry.

&������-�%'��-��0.�0�4%!-%!1� �-1�&!-%+� �.�!��-!� -.

Page 6: Towards an Ontology Approach to ATAM Based Assessment - AGH

��� ������ ���� ������������ ����������������� ����� ���

������������ ������������������

Ontology engineering methodologies [10, 10, 11, 21] usually distinguish the followingcommon steps in the ontology development:

�! " ��#����������$ ��� ���%&������ �� ��$����# �� ����&���� ������" ����� ���

��$" � ���H� ������'���&�����" "����$���(����� )�$"& �!*

+! ,��� "���&�������-�� ���&�#������ "������ ���#����� "������� �� $���� �.

��� ���� ���%&��� &������*

/! 0�$�&�����������������������������&������#�$�&&������ � 1�12 I*

3! J "&��$ ��-������� ����&��������#��� ���&1

In this section we will briefly describe the assumptions determined in the specificationphase and describe the content of the ontology obtained after formalization. The ontologyhas not been yet fully deployed: a tool supporting collection and an analysis of informationabout the properties of an architecture is under development.

������������ ������'���������������

The goal of the SOAROAD (SOA Related Ontology for Architectural Decisions)ontology is to gather the knowledge from the SOA domain and organize it in such mannerthat:

- ����&& � &" ��� H� ������ �%��� (����� "�" �� � �# ����� ����& � ���� ��� � ��.

�����*

- ����&&% ��"�%& �# " � �����������$ ����#"�" �� � & (�����24� ����&�.

������ & $ ����#���� $����� ��� 1

It was assumed that the ontology would follow the metamodel described in the pre-vious section defining various properties corresponding to design decisions that can beattributed to components, connections, interfaces and compositions. If applicable, thesedesign decisions can be supplemented by additional relations. The ontology would also spe-cify design patterns.

Another assumption is related to a distribution of the knowledge between ontologyTBox (classes and properties) and ABox (individuals and their relations). It was decidedthat properties would be represented by classes, whereas their values as individuals.

The concept of the ontology application is presented in the Figure 2. The process ofbuilding of an architecture description starts with eliciting architecture views ABox, i.e.a set of linked components, interfaces and connections. This model can be prepared eithermanually or with a support of dedicated import tools converting ArchiMate [18] models ofArchi editor [1] or UML [3] from VisualParadigm.

A tool supporting architecture description uses the classes and individuals definedin the SOAROAD ontology TBox and basic ABox respectively to generate forms or

Page 7: Towards an Ontology Approach to ATAM Based Assessment - AGH

��������2���&���4""������4�4�5�� �4�� ��$ ��111 ���

questionnaires in which software architects or members of development teams can makeassignments of property values to elements of architecture views. Resulting ArchitectureABox refers elements of Architecture views ABox and individuals defined in SOAROADontology (merging two input ontologies and asserting additional relations).

������4���� "��#�""&��������#24�24J����&���

Figure 3 illustrates this approach with an excerpt from a resulting Architecture ABox.ComponentA via ConnectionAB calls functions of ComponentB exposed by the Interface B.This information originates from architectural views and is contained in the ArchitectureViews ABox. In the next step each of these nodes is attributed with properties (architecturaldecisions) being instances of concepts gathered in the SOAROAD ontology to form fullArchitecture ABox.

In the presented example:

- ,�$"�� ��4��� "&�� ���6�� &K ��+1�/�7�$����� ������8%������13���.

� $����&���0����""&�������� ( 1

- ,��� �����45 ���������������� �I%�� �"�� �����$ ������$�������%

� ����1

- 6�� #�� 5���24�� %� (�� ����&��H� �����&������� )� "��������&���

%�� ������"#��&��1

- ,�$"�� ��5��� "&�� ���66�"&��#�$��������� & ��1

The resulting graph of interconnected elements with assigned properties presented ina user-friendly browsable form can be input to ATAM analysis performed in the standardmanner.

Page 8: Towards an Ontology Approach to ATAM Based Assessment - AGH

��+ ������ ���� ������������ ����������������� ����� ���

������4� )�$"& �#����� ��� 45�)1L& $ ����#������� ����&(� �'$�� �����%�&�&�� �!

� ����%�� ������ ����� �������'����(����&��#�&��� �� #�� ����� ����&���!

������������������

As mentioned above the model of SOAROAD ontology uses the notations proposedin [18] to represent the ontology. The ontology was formalized in the OWL language andcan be accessed using standard ontology tools, e.g. Protégé or with Jena or OWL APIsoftware libraries.

Due to limited space, we will describe the SOAROAD ontology by presenting an ove-rall model (Fig. 4) and next illustrate our concepts by choosing some specific examples ofclasses (ComponentProperty).

����(�24�24J����&���

Page 9: Towards an Ontology Approach to ATAM Based Assessment - AGH

��������2���&���4""������4�4�5�� �4�� ��$ ��111 ��/

The ontology specifies also functions of components. Their list is rather related toinfrastructure components. The function is the implementation of a specific service thatrepresents dynamic behaviors of components. Examples of such function are: Routing,MessageMapping, ProtocolSwitch, MediationService.

The ontology provides a taxonomy of quality attributes. Quality attributes (Fig. 5) arethe overall factors that affect run-time behavior, system design, and user experience. Theyrepresent areas of concern that have the potential for application wide impact across layersand tiers. Some of these attributes are related to the overall system design, while others arespecific to run time, design time, or user centric issues. The extent to which the applicationpossesses a desired combination of quality attributes such as usability, performance, reliabi-lity, and security indicates the success of the design and the overall quality of the softwareapplication.

When designing applications to meet any of the quality attributes requirements, it isnecessary to consider the potential impact on other requirements by analyzing the tradeoffsbetween multiple quality attributes. SOAROAD ontology defines influences in relation todescribing the impact of architectural decisions on quality attributes.

����)�4"����&� �#H��&�������%�� �'����������6296L,:�+;���6296L,+<���!

Page 10: Towards an Ontology Approach to ATAM Based Assessment - AGH

��3 ������ ���� ������������ ����������������� ����� ���

����*����������������

In this section we discuss component properties as an example illustrating the structureof the SOAROAD ontology. Subclasses of ComponentProperty (Fig. 6) class define variousproperties and design decisions, which can be assigned to components. Software architectpreparing ATAM evaluation should consider them as an exhaustive list of questions relatedto important issues in SOA architectures. An example of such properties is Platform(Hardware, OperatingSystem, ApplicationServer), PlatformTechnology, ProgrammingLan-guage, ComponentLogic and ComponentSecurity.

Most of the classes have predefined individuals, that can be selected in assignments,e.g. JavaEECompliantAS has several predefined individuals: JBoss, Glassfish, WebLogic,WebSphere, ColdFusion, etc.

����+�,&��� ��#��$"�� ��"�" �� �

��(����,��� ����������

As indicated in the Figure 2 the specification process manages three sets of individualsand relations (ABoxes) using the common SOAROAD terminology: basic, views, andresulting Architecture ABox combining both previous and asserting additional relationsconcerning assignment of properties.

The basic SOAROAD ABox defines individuals of concepts belonging to particularclasses to be presented as choices while specifying architectural decisions. Apart fromproviding a basic set of property values, it specifies relations (Fig. 7), that can be used inarchitecture assessment. The supports relation indicates that particular elements can be usedtogether, e.g. JBoss (ApplicationServer) supports Document.Literal (SOAP web service

Page 11: Towards an Ontology Approach to ATAM Based Assessment - AGH

��������2���&���4""������4�4�5�� �4�� ��$ ��111 ��<

style). The supports property has two subproperties: supports_fully and supports_partially,that can be used to indicate possible incompatibility issues. Another way to define poten-tially conflicting architectural decisions is to use Conflict objects (reified multirole pro-perties) that indicate sets of properties, which should not be used together, provide specifi-cation of conflict levels (e.g. partially_compatible, incompatible, error_prone) and textualdescription (rationales) . The required relation can be used to specify that one elementrequires another. Such assertions can be explored, while reasoning about implicit decisions,i.e. resulting from earlier assignments.

����-�� &������% �� �"�" �� �

SOAROAD ontology is formalized in the OWL language. In consequence, the ontolo-gy should follow the Open World Assumption (OWA) to be compatible with OWL reaso-ners, e.g. Pellet, Fact+ or Racer.

According to OWA the following approach was adopted:

- 4 &��� �# �� ��� ���� �� �� "�" �� �# � "�����&� ��" � $ ��� ���� �������

��������%��� �� ������$ ��10� )�$"& ��0��� /�� ��#�$����� ��"�(�� �

�%����� ����� ��" ��������� $#��� ��$"�� ��51

- 4&����#� �������� " � �� � )"&����&�%�������(����&'��������!�#�"�����&���" �

1�1�������(����&2" �������� $1���M� ��� ����% ������ ����� ��$"�� ��51

- ,��#&������� ��������#�� ��$ ��" ���% ����%�� ������$"�� ��� 1�1��$"�.

� ��5���% ����%�� ����� ���������I���)"�" �� �1������#&���� #& ���

�������� ������ "���&� ����( �� �(���� �1J������ (�&������"�� ��'"����.

%&���""�� �%� ������������� �� �#�� "��� &�� ( &�" �� ��# �I�& �!

��������� �������% ������� ������(�&��1

- = ����( ��� ������%���"�" �� �� " � �� �%���" ���&%�� &����������

�%> �����% �������$��� ����(����&�#� � & �� � ��" 10� )�$"& ����� ����

',�$"�� ��5�%���621�����$���!���% $�� ��� 621�����$���% &���� ��

�� �&���62'�" ��������� $!1

Page 12: Towards an Ontology Approach to ATAM Based Assessment - AGH

��; ������ ���� ������������ ����������������� ����� ���

(�*���������

This paper describes the SOAROAD ontology and a concept of a tool that supportsdocumenting architectures of SOA-based systems. The proposed approach addresses theproblem that can be encountered during architecture assessment: to be reliable, a reasoningabout architecture qualities, must have solid foundations in a knowledge related to a parti-cular domain: architectural styles, design patterns, used technologies and products. The ideabehind SOAROAD ontology is to gather expert knowledge to enable even inexperiencedusers performing ATAM-based architecture evaluation.

An advantage of the presented approach is that its result is a join representationof architecture views and properties attributed to design elements formalized in OWLlanguage.

From a software engineering perspective, such centralized information resources mayrepresent a valuable artifact, which, if maintained during the software lifecycle, can providea reference to design decisions that can be examined later in the integration, testing anddeployment phases.

On the other hand, the machine interpretable representation, constituting a graph ofinterconnected objects (individuals), can be processed automatically to check consistency,detect potential flaws and calculate metrics. An extensive list of metrics related to architec-tural design was defined in [22]. We plan to adapt them to match the structural relations inthe SOAROAD ontology, as well to develop new ones.

Further plans are related to the extensions of the currently developed tool. At presentits functionality is limited to building the architecture description. Our intention is to fullyintegrate it with the ATAM process allowing specifyed scenarios, describing sensitivitypoints, tradeoffs and risks.

�� �������

N�O 4����4���$�� ��� &&������&����"?99����1� ���1��1��9����&���1��$&�+���1

N+O 5������1�@�� $������1�� ����1������������� ���� ���� � �������� ���� 1L���� ���

�-:�� ���"?99 "������1�$�1 ��9� �9/+39� +��A1

N/O 5�����1���$%�����1�����%���61����� ����� ������� ��� ������ 1+��L������14���.

���. �& ���# ������&�+��<1

N3O ,�"�&&��1�=�(�01��P �1QJ� ����1,1���� ����� ���������������������� �������� ��

� ������16�20��#��L��=�� ��/��3�+��;1

N<O ,&��������?� && �?���� �! ��� ������"�������"?99�&��"����1��$9" && �91

N;O ,& $ ��� �1� @��$�� �1� @& �� �1� ��������� ������� � ������ ���� �#� � ������ ��� $��

����� �1 4������ �& � I���$�� L6 � � 6� �#��� L���� ��� /;� 4������. �& �

��# ������&� +���� ���"?99���1�$����1��9 ) �9�%����9 �� ��R���S��� �&�� �:.+�Q"���S46=9

�+��A�3�+K

NAO J 5� �1,1� I����1�� & �41�B��B&� �71������%����� � �������&����� ��� ������ ������

� ���� ������1+��:����� �����6LLL606�,��# �� ���#��� 4���� ��� L��" ��

,��# �� ���#��� 4���� ��� ��+�<�-;��+��:1

Page 13: Towards an Ontology Approach to ATAM Based Assessment - AGH

��������2���&���4""������4�4�5�� �4�� ��$ ��111 ��A

N�O J =���&�41��������##�1�=�(��&� �1� �� '��'����� ���� ���� �� (��� ��� ���� �����%1 ��.

� ������#�;��6�� �������&,��# �� ��J���%�� ���L)" ���� $�4""&���������JLK4

+��<�,�" ���� ��J �$���+��<1

N:O L#�����41���$�4&� 01��������%����� � ������� ������� ���� � ���������� ����1��.

� ����� �# �� /� ��� �������& ������" �� ����� ��� ����� ����� ����& ����& ��

74�@ �� A:.�;� +���� ���"?99"���&1��$1��9��������1�#$R����S�/A��;+1�/A����1

N��O ��$ �.� �41� 0 ���� �.I�" ��1� ������=1���)*�+)����,#� -���� ���������� ���

)������� ���������� �� ��1 ��� ����� �# �$"����$ ��2���&�����& L���� ��� �#

4446�"����$"����$ � �����#����::A�//-3�1

N��O ������ �1�0�)�11�� �������%� ���� �� �. ������������������������� �1 6�,46T:<�

�����"��5����2���&�����&6��� ���@���& �� �������::<1

N�+O 7�����61���� &.��� �� �10�5�& �71���% �1�����#51�J ���1���!�#���� ������� �

��� � ���� � ������� ���� ��� !�� ��1 +����� +��3� �-++� ���"?99���1�/1��9����%.

$������9 �I

N�/O 6296L,:�+;1�#��� ���� ���-������H��&���'6296L,!�6296L,�+���1

N�3O 6296L,,J+<���1/?��� $� ��� ��#��� ���� ���-�#��� "�����C��&���� H�� .

$ ������L(�&������ 'C���L!-�#��� "����� H��&������ ���� $ H��&��� ���� $�� &�1

62+��:1

N�<O @��$�� �1� �)��#� � ����� ���� ������ ���� � ���������1 ,�8L6+�������3� +���� ���"?99

���1� �1�$�1 ��9"�%9����$ ���9��1 "���9"�#9�����31"�#1

N�;O @���� � �1� �� �����%� ��� ������ ������� . ��� . ������1 ��� ����� �# +�� ������ �

�����"���#��� B���%�&�������� $ �������� �=I�+��3�<<.;+1

N�AO I I1�@���� ���1�/������&��������� ������� �������. ���. ������1�#��� 4���� ���

<+:+�+����/<:-/;+1

N��O �� 2" ����"�4���$�� �1�" ��#������������"?99���1�" ����"1���+��:��1�++1

N�:O 2 I+ %2���&���I������ ������&" ��#����������0��������&.��& ����)� /,� .

��$$ �������+A2���% +��:���"?99���1�/1��9��9��&+.�����)9U6$"���1

N+�O ����1���&�� J1� ������� � ������ ���� #� ( ��' ���� �� �� �� �� ���.����'�� 1� ����

7�&&��+/�+3+�� ���� 7�&&��::;1

N+�O &����1��& %�@1�,�$� & 1��� ��1��&�����41�0����1������%� � ���� �������%

������� ��%�� ��1��� ������#�� ������� �������&���# �� ��,�$"��������&��&& ���(

��� &&�� �� ?� ����&��� �����""&����������������������,�$"��������&,�&& ���( 6�� &&�� �.

� � I=,�"��� .B &������ � �� >������=��������=��� �� ���@� $7���� 'L��1!�

B�&1���61"��� .B &���5 &���7 �� &% ��+���1

N++O B������ &��41������1���%�& ��1�0����������%�� �������� ���� �� �����#����� �'��� ���

� ��������������''�����1L& �����������&�# 6�#�$�������� $�L(�&�������B�&1���

6��� ��+��A�:�-�++1

N+/O B�&&$ @1� ��&"�� �1� ��� 1� )� � -��� �� �� ��� 2#� �� �'��� � � ���� � 3��1 C+ +����

���1#� �� 1��$��� 1

N+3O �����������$ �1� ,���� L1� J�&&�� �11� �����%� ��� ���� +�������� ���� ������� � ���

���4��� � �! '� � �����16������&6LLL6�� �������&,��# �� ��J�����&L�����.

� $����� ����&��� ��,�����4����&���0 %���+��A