The document provides an overview of the Arteon method and model. It discusses the context, outlines the method which involves requirements analysis, architectural decision making, and increasing knowledge. It then describes the Arteon model which represents requirements, architectural elements, and reasoning in interconnected ontologies. Finally, it discusses ongoing work to improve the ontology design, populate it with knowledge, validate it with case studies, and provide tool support.

1. Arteon
GESSI
Software Engineering for Information Systems Group

2. Arteon presentation
Outline
•
•
•
•
Context
Method
Arteon
Ongoing work
2

3. Arteon presentation
The things we must know before we enter into details
CONTEXT
3

4. Arteon presentation
Context: Related concepts
4

5. Arteon presentation
Context: Related concepts
5

6. Context: Overview
Arteon presentation
Current
and other
systems
SRSNF
Human
support
Knowledge
Arteon
ArchiTech
Method
SRSF
Architectural
decisions
Logical
Deployment
Physical
Process
Views
Generation
Architectural
views
Code
6

7. Context: Method
SRSNF
Arteon presentation
Current and
other systems
Requirements
analysis
Constraints
and Quality
goals
Human
support
Architectural
decision making
Architectural
decisions
7

8. Arteon presentation
Understanding the method with examples
METHOD
8

9. Method: The requirements
SRSNF
Arteon presentation
Current and
other systems
Requirements
analysis
Constraints
and Quality
goals
Human
support
Architectural
decision making
Architectural
decisions
9

10. Method: The requirements
Arteon presentation
• Non-Functional Requirements:
 NF1: The system should be developed with Open
Source Software (OSS)
 NF2: The data should be stored in each
organization
 NF3: The system should allow operation from
each organization
10

11. Method: Requirements analysis
SRSNF
Arteon presentation
Current and
other systems
Requirements
analysis
Constraints
and Quality
goals
Human
support
Architectural
decision making
Architectural
decisions
11

12. Method: Requirements analysis
• Requirements analysis:
Arteon presentation
 NF1: The system should be developed with Open Source Software (OSS)
• C1: Property “License type” equal to “OSS”
• G1: Community involvement
 NF2: The data should be stored in each organization
• C2: Property “Persistence” equal to “distributed”
• G2: Security
 NF3: The system should allow operation from each organization
• C3: Property “Access type” includes “remote access”
• G3: Availability
12

13. Method: Decision making
SRSNF
Arteon presentation
Current and
other systems
Requirements
analysis
Constraints
and Quality
goals
Human
support
Architectural
decision making
Architectural
decisions
13

14. Method: Decision making
• Making decisions (two ways):
 Constraint satisfaction decisions (quantitative)
Arteon presentation
•
Constraints over properties of the elements of the
system
 Quality-oriented decisions (qualitative)
•
•
Knowledge of decisions
Relation between decisions and quality attributes
• We think that both ways can be used together
14

15. st
1
Decision making:
way
• Constraint satisfaction decisions (1st way)
Arteon presentation
Evaluate
constraints
Decide to
use
elements
Add new
constraints
• Four iterations:
 Architectural styles
 Architectural
components
 Technological styles
 Technologies
15

16. st
1
way
Evaluate
constraints
Decide to
use
elements
Add new
constraints
• C1: Property “License type” equal to “OSS”
• C2: Property “Persistence” equal to “Distributed”
• C3: Property “Access type” includes “Remote access”
Arch. styles
C1 C2 C3
Arteon presentation
3-Layer
SOA
Human
support
Blackboard
Pipe and filter
MVC
16

17. st
1
way
Evaluate
constraints
Decide to
use
elements
Add new
constraints
• C4: “3-Layer” requires “Presentation layer”
• C5: “3-Layer” requires “Domain layer”
• C6: “3-Layer” requires “Persistence layer”
Arteon presentation
Arch. Components
C1
C2
C3
C4
C5
C6
Presentation layer
 Remote presentation
Persistence layer
 Distributed persistence
Domain layer
17

18. st
1
•
•
•
•
way
Evaluate
constraints
Decide to
use
elements
Add new
constraints
C1: Property “License type” equal to “OSS”
C2: Property “Persistence” equal to “Distributed”
C3: Property “Access type” includes “Remote access”
No new constraints. LAMP is an acronym of a set
Arteon presentation
of software subsystems used
to build a global solution.
Tech. styles
C1 C2 C3
Java
LAMP
Human
support
.NET
18

19. st
1
way
Evaluate
constraints
Decide to
use
elements
Add new
constraints
• C7: “LAMP” requires “Web server” implemented by
“Apache”
• C8: “LAMP” requires “DBMS” implemented by “MySQL”
Arteon presentation
Technologies
C7
C8
Web server
Apache
DBMS
MySQL
19

20. Decision making:
nd
2
way
• Quality-oriented decisions (2nd way)
Arteon presentation
Evaluate
quality
Select
decisions
Increase
knowledge
20

21. nd
2
way
Evaluate
quality
Select
decisions
Increase
knowledge
• Which are the quality goals?
Arteon presentation
 Community involvement
 Security
 Availability
• In a real case it will be similar to:
 50% security related requirements
 30% usability related requirements
 20% efficiency related requirements
Human
support
21

22. nd
2
way
Evaluate
quality
Select
decisions
Increase
knowledge
Arteon presentation
• Security related decisions




Authentication facilities
Secure communication
User account management
…
• Selecting one or more decisions will impact on
new constraints
 E.g. secure communications will require some
technology such as SSL.
22

23. nd
2
way
Evaluate
quality
Select
decisions
Increase
knowledge
Arteon presentation
• Two ways to increase the knowledge:
 Learning: when a new decision is made from a
constraint imposed by a NFR. The decision is
related to the quality property where the NFR
was classified.
 Reliability: when a decision is selected in the
quality-oriented decisions process its reliability is
increased in relation to the quality property.
23

24. Arteon presentation
Model representation of Arteon
ARTEON
24

25. Arteon: Overview
• We have 3 in 1 ontologies
Arteon presentation
 Requirements
 Architectural elements
 Reasoning
• The ontology is build in UML
• More than 20 interrelated concepts
25

26. Arteon: Requirements
Arteon presentation
• Totally simplified to reuse existing works
• The ontology can represent all kinds of
requirements, but we only consider NFRs.
• The requirements (NFRs) should be:
 Measurable / Checkable
 Classified in a quality model
 Formalized (e.g. i*)
26

27. Arteon: Architectural elements
Arteon presentation
•
•
•
•
•
•
“3-Layer”, “Layered”
“3-Layer” specializes “Layered”
“Presentation layer”, “Domain layer”, etc.
“3-Layer” use “Presentation layer”, etc.
“Distributed persistence”, “Remote presentation”
“Distributed persistence” combinable with “Remote
presentation”
• “Distributed persistence” variation for “3-layer”
27

28. Arteon presentation
Arteon: Architectural elements
•
•
•
•
•
•
•
“LAMP”, “Stack solution”
“LAMP” specializes “Stack solution”
“BDMS”, “Web server”, etc.
“Stack solution” use “BDMS”, etc.
“Distributed DBMS”
“Apache”, “MySQL”, etc.
“DBMS” implementable by “MySQL”
28

29. Arteon: Architectural elements
Arteon presentation
• There are many similarities between
architecture and technology
• So, we put it all together 
29

30. Arteon: Reasoning
Arteon presentation
• Which is the relationship with requirements?
30

31. Arteon: Reasoning
Arteon presentation
• Which is the relationship with architectural
elements?
31

32. Arteon: Reasoning
Arteon presentation
•
C1: Property “License type” equal to “OSS”
•
Element “LAMP” have the property “License type” with the
value “OSS”
32

33. Arteon: Reasoning
Arteon presentation
•
C1 is satisfied by element “LAMP”
Human
support
•
We make the decision “D1” to use element “LAMP”

We know that the “Community involvement” quality is helped by
the decision “D1” (Knowledge acquisition!)
33

34. Arteon: Reasoning
Arteon presentation
•
“LAMP” requires “SGBD”
•
Really means: “LAMP” impose the decision to use “SGBD”
34

35. Arteon presentation
What are we going to do from now on
ONGOING WORK
35

36. Arteon presentation
Ongoing work
•
•
•
•
•
•
Exploratory work: Survey, interviews
Ontology design improvements
Analysis of the ontology quality
Population of the ontology (knowledge)
Validation (case of study)
Tool support
36

37. Comments and
questions
GESSI
Software Engineering for Information Systems Group