So welcome everyone to our Computer Science Colloquium.

I'm very happy to have with us today Professor Klaus Leverenz from BTU Cottbus Brandenburg

Technische Universität.

He's been a professor of computer science at BTU for over 20 years I believe.

So a distinguished career he's looking at over lunch and afterwards we discussed not only computer science

but also service to the university and start-ups which of course is important to us as well.

And the start-ups he was involved in.

This topic today though is actually somewhat related I think.

Visualization of software architecture I think a long-running topic for many years already now.

So very much looking forward to the results of these many years of labor that he can show us.

So thank you very much for coming and talking.

Thank you Derek for having me here.

Welcome everybody from my side.

What I'm talking about today is some step in my research.

So 20 years ago when I started at BTU the main focus was on metrics to measure properties of software.

And then from this we quite naturally came to the area of visualizing properties of software

especially also the question of visualizing and understanding the history of development of software systems.

And I'm going to tell you a little bit about one area of this visualization approach that we are taking.

And so I choose as a topic as a key question how does your software look like.

You know the problem is that when talking about software project,

software system and also the project in which the software is developed

then you have different stakeholders, different people contributing to this project.

And each of them has a different perspective on this project and on the artifact that you are building.

So there might be architects looking at some say UML diagrams, some architecture diagrams.

Then you have the programmer who basically looks at the software from the code point of view and organization of repository and so on.

Then you might have a more quality oriented software quality and measurement based perspective.

So QA people and then you might have the project managers who are looking at schedules

and looking at some project dashboard trying to understand what's going on.

And then you may have people who are interested in resources asking how much does this cost,

where is our money spent for and these things.

So the interesting point is that in large software projects you find that these people don't have a common picture of the project, of the system.

And especially if you look into say large software structures that are developing over long periods of time,

then it's kind of a crucial question, what is our common picture and what is the basis for communicating between these different people.

How do they talk about the project? How do you talk about the software?

So the question that we try to solve somehow is the question how do you create, and I use the German word Gestalt, from data.

So how do we get some common picture, how do we integrate these different perspectives that people have on their software

into a single common picture, into a single Gestalt I would say.

And I think the interesting point is that if you discuss about software projects,

especially with people who are not developers, who are not in the code, let us say,

they very often don't have any idea about what are these people doing, all these programmers, all these software developers.

And also it was sometimes interesting when we started to do all kinds of software metrics measurement,

if you discuss the size of software projects with managers for instance, they have no idea what this means.

I mean if you tell them we are developing 10 million lines of Java code or so, they have no picture.

I mean they have no idea what this is all about, how complex is this and so on.

So basically what we tried over the last years was to choose a metaphor, an analogy,

how to present or how to create Gestalt, how to create such a common picture that is suitable for integrating different perspectives in a project.

And the metaphor that we are using, and we are not the only ones using this, is a city metaphor, a landscape metaphor.

And why is this, I think, is very suitable and very natural in a way.

You know, when cities are built, you have a strong analogy to building software,

because cities are also large scale, artifactual structures, they are large scale and they are also having a long development history.