My name is Andreas Gaiser I'm a team lead for research and development at Axivion and I'm working in the area of architecture verification and semantic analysis of programs. It's a very broad term so you could say it's the organization of a software project into different kind software components and how they interact or depend on each other. So this is a in a nutshell what software architecture is. And normally it's specified or given in the form of a graphical model like using UML or something
similar. So this is a term that that derives from the problem that you have your architecture on the one hand and you're creating that. The architect normally is responsible for that and you have to code on the other side and the problem is they should somehow be in sync. So if you model something in the architecture it should reflect in the code and vice versa and normally you can not do that because these are two separate things. Architecture verification is a process of comparing the archite
cture to the code and to see whether there are some kind of discrepancies between those two. There are many benefits for different stakeholders so for example if you are an architect or project lead then you can start with architecture verification at the beginning of a project and you can actually keep track of the progress and see whether something goes wrong in a very early stage of the project because you have immediate feedback that something goes wrong that you have your architecture there
and in the code something is different then you can take a look at that and think about "What is the problem here?" "Is the problem in the architecture?" "Should we do another design decision there or is it in the codes and we should fix this right away?" So we have very early feedback and bugs or so can be avoided. For the developer it's very nice to have this tool because you also get immediate feedback. And the problem is, you as a developer, if you develop and you know there is an architect
ure there it's nice that it's there but you normally do not check it but now you have to check it because you get a violation or something like that. So it avoids bugs and leads to better code and you have the the nice thing that you have a reliable documentation because now if you have a new colleague you can say well look at the architecture it's actually verified so if you have an dependency there then it's there and if you have no dependency then it's not there. And you can actually do for e
xample software refactoring in a very nice way and be confident that if you change something you know what actually happens. Maybe you have a tool like Enterprise architect or Rhapsody and you have a model there which is great so this is a very very nice step if you have that. Our approach is that you can import this into our internal representation we get the information from the code you give us the model we combine them and make this check automatically. So this is a check that has to be set
up one time and then it will just work out of the box. And if you change your model you actually get the changes in the next analysis run. If you change your code it's the same yeah so this is a a quite easy process. It's a good point we have a lot of stuff going on for example if we look at architecture verification we have a lot of customers in the automotive industry there are standards like AUTOSAR and adaptive AUTOSAR and a lot of challenges for the architecture domain. We also have interes
ting topics like Freedom-from-Interference and also things like security is becoming more and more important This is also something which is interesting and where architecture can be of tremendous help and architecture verification in particular so I would say yeah there's a lot of stuff that we actually could do in this area
Comments