Questions of Metaphysics of Software and Art (QuMeSA)

Random Sequences of Code

2011-11-06T23:44:00.011+01:00

"Random Sequences of Code" - so was it told in the movie "I, Robot" with Will Smith. It occured as part of an explanation why Robots may show indeterministic or even human like behaviour some day. I don't want to go deeper into the argument chain presented in the movie. Instead, I want to stay close to the words itself. And I will argue while probabilistic driven systems are the best chance for systems for the future.

The first one is "Random". In a very distant view, randomness means out of control. Many philosophers discussed the nature of randomness. Some say, that randomness is only a matter of perception and knowledge. We perceive a process as a random one if we are not able to explain by which laws the process works. Or in other words: for a given knowledge, there is a level of complexity where every process complexer than this level looks like a random process. In Quantum Theory, randomness gains new value and a new role in the up to this time deterministic view of the universe.

In some domains of technology, there is the term "emergent behavior". Scientists and engineers use this word if they work with systems built from small, independent but connected systems. It is a big fear for any Safety Engineer, because it is open how to assess an emergent system (as I will call it now) related to safety (see this blog post).

But the other part of the citation above is not less interesting: "Sequences of code": In the early days of software, programs were written in a few hundreds lines of code to fit in the small processors. Today, we count many programs in million lines of code. But look at the developers: their view on the software is still just a few hundred lines of code, the overall picture is lost. Well, no offense, who could keep one million lines of code in the head ? The whole software is falling apart in sequences of code.

Although this one is more a problem of perception, the emergent systems could be understand as a system going through sequences of code: every unit is small, has some sequence of code. If the emergent system induces a function, many nodes activate (parallel or in sequence) their small code blocks. Try to write down all code the system run through in every unit as one big program....

My point is this: independent if you have to mange one big block of code or an emergent system, it is not feasible anymore to request to know *exactly* at which state (which line in the code, value of variables) the system is at any time. In some sense, we're sharing a little bit the situation of the physicists in the dawn of the Quantum Theory: the well feeling of being able to predict *exactly* any system for any point in time is lost or weakened.

Humans have introduced an interesting weapon to this uncertainty: probability theory. The single unit is not important any more, only the expectation about the result of the operation of a collection of units is. Details are not important anymore, only the emergent behavior, the effect in sum. Seems to be the hope for the technical future, no ?

Well, to me, it is an open question if probability theory can be a tool to gain control. It depends also from the answer to the question if real randomness exists as constituent brick of the universe.

Assume the Onion Model of Control is true, and randomness exists: in this case, there have to be laws (independent if we found them already or not) that makes the probability theory on its level ("shell") deterministic. There would be laws which have to be the probabilistic counterparts of basic physic laws like energy conservation, Newtons laws etc. They would be the control tool for the universal building block "randomness". The bridge to find these laws could be the Statistical Thermodynamics and the Quantum Theory. Once found, such laws in effect would allow us to control and predict any system behavior, even emergent system behavior.

If randomness doesn't exist, which means all would be deterministic, probability theory would be not a universe built-in way of control, but just a human instrument to handle things which are unknown: instead of looking and control every onion shell of control, probability theory would allow us to ignore a subset of shells. Probability then would describe in a sum the things of some onion shells of control below. Probability theory would be nothing more than a pragmatic approach to the Onion Model of Control, with the danger of roughness.

Lets look at the other case: If the Calculating Universe Model would be true, then it is the question if the probability theory is useless at all. If all is given from the conditions at start and the rules in the system, then randomness can not exist and it would be just a matter of perception. But as in the case above, Probability Theory may give us again the chance to handle emergent or complex systems at least in a pragmatic way until we humans get insight in the background.

In the sum, building technical things based on Probability Theory may give us the biggest chance to control what we built or at least to useful estimate its behavior. How precise and powerful this tool set will be depends on which of the assumptions (Control Model, true randomness or not) are reality. And of course we have all options to develop further our insight of probability, so we should do it :)

At this place, I should remember the reader to the fact (which is very obvious in this post) that my blog is intended more to raise questions, not to write philosophical sound conclusions. That would be matter of a book, of which I think more and more I should write it some day :)

Get me Control - no ?

2011-11-01T09:09:00.003+01:00

As you may know, I am a safety engineer. Therefore, my task is to assess software if its use doesn't induce any unacceptable risks.

Safety engineers base this assessment on two poles: demonstrate, that the software is written by an engineering process which is suited to reduce human errors. In other words, the sources of systematic errors should be reduced. The other pole is the demonstration that the system is correct, by make evident the correct implementation of requirements, the appropriateness of tests and the handle of possible and foreseeable faults and failures. Roughly said, this pole is about to demonstrate that the real concrete system in our hands is observable safe.

As you might guess, this task is much more easy when the software engineering is well developed and if it is possible in principle to know about all functional construction and to control it. In fact, safety is about control. Now it may be clear, why I'm interested in software engineering and the question of control. If the Onion Model of Control is right, we Safety Engineers and system users have no problem at all.

But - what if the Calculating Universe Model is true ? Look at the system biology, the construction of biologic artificial life, the construction of DNA - Cell machines emerging a non calculable behavior. What if the Grown Universe Hypothesis is true ?

Well, I am convinced that the way we work with functional and product safety today is not feasible for the technical or technobiological systems in front of us. I argue that we have to drop the idea of everywhere and every time control. A system can not only be safe because we know every branch of its behavior and therefore know that nothing danger can occur. Powerful and future proof safety is when a system can be full of failures and faults, but the system handles them for itself. See the correction and fault tolerance mechanisms in biology: cells, bodies, populations ! But this needs new insights in a different class of construction principles, which is not available for human kind yet.

Without having a solution in back, my opinion is that we need another approach to engineering, to build systems doing what we need to solve problems. Computer science, understand as science of information, may take us one step further and let us build safe complex computer systems as well as designed life forms.

Chicken and Egg

2011-10-21T06:39:00.011+02:00

In all this dry and serious technical world, the call for human aspects gains more and more attention. If it is really the case that human beeings have to create all these products born out from mathematics, logic and rationality then for sure we have to look at the poor human beeings in this process. How will they feel, will they like what they do, will they be happy ?

Lets switch to a chicken farm. The fate of the chicken is to produce eggs, a thing which seems naturally for them. Chicken dump eggs. So it may be that the chicken is happy about every egg because it is the sense of its life, and it sees this sense of life. And if the egg is there the chicken bothers about the egg, until this tiny little white thing changes to a young yellow chicken. Reached that, the chicken feels good, yes ?

Now, in the nasty modern chicken farms, where the chicken are doomed to sit very close together, nearly impossible to move or to see anything other then steel and other chickens, it is hard to imagine that the chicken will be happy. It cannot see its egg, because in the moment it is released from the body the egg is taken away. The chicken has no contact with its sense of life, and there are not the conditions to produce high class eggs: different food, fresh air, sunlight, movement and normal interaction with all other chickens.

The creative mind may have the idea to produce the best eggs ever by the most luckiest chicken ever. What lucky chicken, they can walk in an english garden, the earth worms are hand selected and at least 5 inches long, room temperature is very convenient, like a warm sunny day in spring about tea time. Also the chicken has not to lay any egg if it chooses to do so. In this lucky fate any egg which we get must be the best egg ever, nor ?

What I want to say is this: the key word is balance. Is all about the product, but also about the humans and the processes (including technology) to build that product. But no factor is more important than the other. Sometimes, I have the impression that in some discussions the human factor is overstressed. All factors are interwoven with the processes and laws, which have to be considered. Neither is software development to set up like a chicken factory, nor like the paradise for self fulfillment of software developers. The balance has to be hold.

Hello, Siri

2011-10-16T09:16:00.004+02:00

Apples Siri is from my point of view the most underestimated thing at iPhone4s. It fact, it could be the start of another change touching everything. Although a good working speech recognition has still some fascination, we are got used to this the last years. Automatic call center and the speech command in my car are well known examples.

There are two other properties of Siri, which are special: using knowledge and using context. You have no longer talk some isolated commands like "Radio" "on". You can talk like you would do with a person - a beginner or child - but a person. And to the second, this "person" has knowledge and context awareness. By using data from location services, database, documents etc. it is possible to provide interpretation of what the user said. It is a first step in a much bigger world, the artificial understanding. When speech recognition is our planet, than artificial understanding is like offering the milky way to us.

For me its not the matter if Siri work exactly like described above or if there are many problems with it. It is the start of a new way to work with artificial intelligence. It is a hypotheses of mine that the universe works probabilistic. I belief that the physics we use today - with solutions of algebraic equations - is just the recognition of an average or of limits. In Quantum Theory and statistical thermodynamics the probabilistic nature is directly observable. And my strong belief is that the brain is - as far it relates to knowledge processing and control - and statistic engine, were one brick of it is association and pattern recognition.

Collecting and correlating knowledge pieces - which we can call documents - and building knowledge from it is the thing which really impresses me on the IBM Watson project. And for this judgement, it is irrelevant that Watson is built on brute force and a collection or hand-made optimizations for special problems. We come closer to a theory describing this all with time.

The important thing is this: Siri (I think) and Watson are knowledge processors in the sense above, and move our view to the probabilistic nature of the universe, also shifting our paradigm what computers can be good for, maybe even the paradigm how to use this huge knowledge and database called Internet.

This is like all things begin: small and decent ;)

Tell me a story

2011-10-12T21:12:00.002+02:00

Today, I've read architectural documents as preparation for a functional safety analysis. Such an analysis is performed to come to an assessment if the given system and its architectural elements fulfill the safety-related requirements. As you might imagine, for doing this work it is helpful to understand the effect chains and the overall operation of the architecture.

So, sitting there and trying to collect the facts spawning out of the pages into my brain, hoping to puzzle together an picture (the picture of software), one thought flashed in my mind: can architecture documents tell stories - and even should they ? (For those who read my last post, lets assume the Constructible Hypothesis is true).

Technical Systems are built from human beings (Well, at least at the moment) Because humans evolve day by day with growing experience causing shifting look at things and moving attitudes these technical systems have history. Humans learn about problems, learn about solutions and in consequence learn to evolve methods and tools.

But not only the creator has history, also the environment = the source of the problems is non-static. Customers have new wishes, technical or environmental constrains change. All this together make it undeniable that a technical product has history. For example, many things on modern ships have their roots in the old wooden sailers. The instrumentation of the airplanes are frozen history of aviation construction.

There is a move citation (I think it was "Big Trouble in Little China" with Kurt Russel): "Thats like all things begin: small and decent". Yes ! This is the power of knowing history: the first versions of things are often simple, not elegant or efficient, but small enough to not covering the basic idea behind a solution. Or better: in the beginning of technical things the intention of the architectural elements will be visible. Going back in history means going to the core part of a technical mechanism, the will of the creator. Going back means to get insight into the basic idea of things.

But there is more. We said technical things evolve. But they evolve not without reason. If technical properties or functions being added, that should be done because of a changed requirements ! So history should tell you a story about sound decisions, why this function or this effect added to the system, and why the old system was not good enough. Again, evolutionary steps have an intention behind them (hopefully !). This is far from trivial, so many team members don't know why software module x or parameter y were added. Look how many things are introduced and killed later on because the knowledge of their introduction got lost.

Now, knowing the history of a technical product seems good. But the question is now can an architectural documentation tell the history ?

Please don't think at the huge version trees of such tools like CVS or Subversion etc. It is not practical to write down a full history log, of course not. But if you see an technical product as a chain of design decisions, controlled by intentions, it might be more clear how to document:

show the basic problem and the basic idea, and show the most important intentions from the historic sequence of intentions shaping the architecture as it is today.

Showing intentions is not necessarily complicated: well chosen names and wording can suggest what the basic idea or problem was. Also, arranging the document along an level of detail gradient can have the effect to present the reader a time trip. AND: show the associated problems !

But my statement is this: just nailing down an architecture as it is in front of you is often not enough. Such documentation may be useful for rebuilding technical things only (schematics for example), but not to understand them. Or to say it much easier: show the human factor in the architecture.

I know, this is no precise plan how to write documents. This may be part of a later post :)

Agile, Architecture and other things

2011-09-09T21:27:00.009+02:00

There are questions about software development I'm really concerned about. These questions raised from my experience being a software engineer, a software architect, requirements engineer and team leader.

One expression of these question is the following problem:

How can software engineering become exactly this, engineering ?

This question is not trivial. But first we have to ask, does an answer exist at all ? If there is an answer, it should be possible to compare software engineering with other domains of engineering, say mechanical or architecture domains. Often I try to make mappings from properties of the mechanical engineering to some of software engineering. But the special way of the existence of software - to be not bound to physical resources and to have multiple instances without additional matter or energy - may have impact on the metaphysics of software.

Now, one of this special properties of software is their potentially unlimited effect. Where mechanical devices are limited by matter and energy, software is completely free, not bound, only limited by its runtime, the computer. We learned how fast computer extend their capabilities. In other words, the effects caused by a running software can be very very complex.

This observation raises this question:

Is it possible to construct technical systems of any complexity level ? (The Constructible Hypothesis) Or - as contra statement:
In general, can technical systems only be grown applying evolutionary principles ? (The Grown Universe Hypothesis)

If the first question has an positive answer, the question above (existence of engineering for software) also has. These both questions also touch another aspect of build things by human: the aspect of control. To construct things means, that the creator has control over every static and dynamic element in the cause chain. The cause chains are arranged by logic reasoning, using basic laws. Here would be the place for an engineering technique for software. But exactly here begins the area of fog, because we know that not every thing can be calculated which means that a full control of any complex system of any complexity level may not possible. If calculability is equal to controllability is an open question.

But if the Constructible Hypothesis would be not true, the only other way of building systems would be to let them grow and arrange solutions by them itself. The evolutionary principle means, to provide just environment conditions (or requirements), and let the system grow. Not necessarily by the system itself like Genetic Algorithms, enhancing a software revision by revision but by human teams is also some kind of growth and evolution. BTW, this would be a place where I see agile and lean methods useful.

If we assume that the Constructible Hypothesis is right, one may ask how we could handle this. One way may be the onion model of control: a few basic laws provide the foundation to build up simple entities and their properties (like atoms from the 4 basic forces and quantum theory, for example). These entities form own rules on their level, from which bigger entities are build with der own rules (molecules, like proteins) and so on (cells, body...). Every level has its own rules, but based on the preceding level, and narrowing the space of possible behaviors. DSLs are operating on the same idea.

Now look at a cellular automata. There are also very basic rules, which generate a special behavior of the automat over time. In the game of life for example, there are patterns coming out which itself show behavior. The "slider" is such a pattern, moving over the 2D grid of the cellular automat. But there is one big difference to the onion model of control: the slider has not its own rules, its behavior is fully and only determined by the basic cellular automata rules ! That means, to control the slider and higher level patterns is only possible by the basic cellular automata rules and the initial conditions. In the onion model of control, you would have constructive possibilities on every level (you could construct different proteins to create a special effect on this level, for example).

From this, it is clear that if the cellular automata model (or let it call after John Neumann the Calculating Universe Model) is true, only the Grown Universe Hypothesis can be true. Otherwise, if the onion model is correct, than both, the Constructible Hypothesis and the Grown Universe Hypothesis have the chance to be true.

So these questions arise:

For control behavior of human built systems, is the Onion Model of Control true ? Or
For control behavior of human built systems, is the Calculating Universe Model true ?

For me, these are important questions, even if they are seem not that pragmatic :) But it is an important question to investigate what we really can do and achieve in principle in the domain of software engineering. Of course this is no exact analysis, but it should illustrate what I'm thinking about.

If some has a hint about already available work or text from philosophers, computer scientists and so on I would be glad about a pointer :)

GDC in Cologne 2011 Special observations

2011-09-03T11:09:00.005+02:00

This year I had the opportunity to go to the GDC Europe and GDC as a press representative. This was very interesting, I've spoke to many cool people, an I've made unexpected observations. Like this one: there were so many iPads, especially used by media people. Of course the notebooks could still be found and their number was not small, but you got the feeling that nearly every one use an iPad. Some people used it as a device for writing AND photographing :)

Beside the public halls which were full and loud even at the professiona-only day (!), I also visited the business center. There, I found a association for supporting game related business contacts to Iran, UK, Netherlands, Abu Dhabi and more. So gaming is really matter of the whole world, which is very very good, I think ! Also, I visited the booth of GAME, the german association for gaming industry.

That gaming can be more than "just playing" (which is itself a value, but not what I want to point out here), it can be used for learning (see my article in the current issue 9/11 of german computer magazine iX, or the web sites seriosgames.org, serios play conference and EDUCAUSE), it can be used to bring sensitivity and money to humanitarian projects. At the GAME booth, I could speak with Jasmin Kassner (CTO) and Kaspar van Treeck (CEO) from the Berlin based company ChawaChawa UG. They do this in a charming way: players play to gain goods, which are relevant for some humanitarian project. In order to give these goods a financial value, they are paid by the money coming in by selling places for ads. Because this ads are in the context of good causes (the games, the portal...) and because online games are a huge user group, placing ads there is a value for companies. But the real charming thing is that it makes humanitarian projects and problems obvious. I could imaging that putting a little bit the game based learning below this there would be a big chance to educate young people (and managers, btw......) about the real problems in the world. Btw, an other good example for this is the game Foodforce of the UN

I think, to find a good balance in this triangle of ads business, humanitarian projects and players is challenging, but definitively worth to try it. Humanitarian projects still needs more attention in our world!

p.s. Thanks Jasmin and Kaspar for your time, I wish you great success for this fine idea!

Back to Programming - with Smalltalk

2011-09-02T23:23:00.003+02:00

Since some years I've never written down one single line of code. Some reason was the change in my profession: starting as a software engineer, I currently work as Safety Engineer, a role which only writes many documents, but no code.

Starting this year, I'm also working on games for game based learning, or Enriched Games (better known by the not irritating term "Serious Games"). In this days of Web and Cloud, it is clear that my sample games have to run as web application. So the question arises, what platform or technology to use for this.

I've seen many programming languages. Haskell I like a lot, but needs sound knowledge of Category Theory to really unwrap its full power. Lua is interesting. Scala is interesting, but a little bit complex. Sometimes, I'm afraid that Scala is in danger to become the next C++. And then there is Smalltalk, my very old love.

It still holds that Smalltalk is a productive environment for me. Together with Aida/Web or Seaside, it is easy to build really fancy web applications. Well, Seaside can get very complex, I remember that I struggled many times about how to do this or that in Seaside. Today, the situation is far better, because there is a lot of documentation about it. And Smalltalk itself still has the very big advantage to be simple - in the environment as well as in the language. Anyway if you are a strong object monk or a functional evangelist, Smalltalk invites you to write down the solution in the way it is convenient for you.

In addition, the last ESUG has shown that there are interesting evolution efforts are ongoing with this old lady. Ok, I'm still missing comfortable remote programming (via web) and the capability of taking advantage of multicores. It seems that Smalltalk has still no strong answer to the coroutines, task pools, STM and whatever constructions introduced in other environments. I hoper there will be progress some day.

For me as one who want to concentrate to solutions, not studying libraries and complex design patterns which only hide the faults of the language design, Smalltalk a natural choice. Reflection and the Debugging on-the-fly make it easy to find out how given code (=libraries) work and to iterate toward the really useful and intended solution.

Smalltalk will not do all in my solutions. CouchDB and therefore Erlang will store data, communicating with XMPP to the Smalltalk application and maybe to other modules as well. But one thing is clear: Smalltalk is for me the best union of all concepts I like with the highest productivity I like. So I will use it - and Happy Smalltalking !

The base for functional safety: Requirements

2011-06-24T00:02:00.004+02:00

There are several myths around functional safety. So it is said that functional safety processes let the project costs grow. As it is true for so many things in the software or system lifecycle, if functional safety activities are not full integrated in all steps of the lifecycle, then it does it more worth than good.

So surprisingly, functional safety starts with requirement engineering ! Requirements are describing the system as it should be, and therefore, they are the base for verification and validation of the system. Roughly said, verification means to demonstrate that the system fullfil the requirements. Simple consequence: no requirements, no verification possible.

Validation means to demonstrate that the requirements are stated such that the system is usable as intended in its operational environment. But to check this doesn't make any sense if the system could not be verified. Conclusion from a wrong preposition gets nothing.

Later activities of the functional safety identify risks which arise if the system goes operational, and which additional functions the system are needed to mitigate the risks down to an acceptable level. Example: a cutting machine induces the risk that you get you hand cut off if you pull it in in the wrong moment. So the mitigation would be a protection system that would stop the machine immediately if any body part crosses a safety border.

Such additional system functions or properties will be noted as additional requirements. And checking if the system is safe includes to verify these safety requirements.

Conclusion: much effort of the functional safety activities can be done efficiently if there is a good requirement engineering in place. It helps to verify and validate the system according the safety functions and the overall safety and to render which are the safety relevant parts of the system.

But how requirements stated will be issue of another post, because this is very important for the value of requirements.

Enjoy !

The Browsers Future

2011-06-15T23:27:00.004+02:00

Today, the web browsers are on the road to become omnipotent: beside the ability to display text they now render complex graphics and video. So many examples in the Web exist providing the user Web pages which are close to pages of an expensive life style magazine with respect of their presentation quality.

Also, browsers are already an runtime environment. See Flash(TM) and JavaScript for example. Look at all the games and interactive websites available in the internet. WebGL and SVG in combination with JavaScript bring you a full desktop like experience into the browser. So it is possible to run a Smalltalk environment in a browser. The current top of this evolution is Googles ChromeOS notebook, where in fact the browser is the operating system and the only thing the user see.

But this is the moment to start thinking in another direction. Why should a single application - the browser - get bigger and bigger ? I always dream about a software ecosystem, were small little code fragments in the sum give you the value. Every fragment, which may be an app or even smaller, has a limited role in the ecosystem and only their dynamic interaction let emerge the value to the user.

And this is the important term: interaction. Every fragment in the sense above shall have a range of processing capabilities. They shall not be limited to much, but broad enough to gain value for different non-forseeable situations. And we now all the solution for this: descriptive languages, like HTML, XML etc. In fact, a browser can handle many things by "just" implementing the HTML language. In the same ways, these fragments should implement one such a language, like SVG for graphics, X3D for 3D graphics, MathML for mathematics etc.

All this things exist, yes, but as one big bunch of software (that many things are implemented as plug-ins doesn't change anything substantially). My vision would be, that the fragments for SVG, MathML, CellML and what ever should be independent small code fragments, which could running on the local machine or anywhere in the network. In this software landscape, the browser would be just a collector and lay-outer of (ready drawn) canvases. And the communication between this fragments should be only ASCII text stream or a (video) stream of bitmaps.

Of course it is difficult to control a collaborative system in its emergent behaviour. But the main question for the future is: do we have to control all behaviour of future systems in detail ? Anyway, my wish would be that the future of software moves away from monolitic systems to a network of small fragments controllable just by descriptive languages.

Enjoy !

Splitting my idendity

2011-06-04T10:58:00.002+02:00

Twitter is for me a often used tool, not just to hear what's about in the world, but to get noticed about technology, events and to get connected to other interesting people.

Now, because I am also working on own Serious Games, which I call "Enriched Games" (which is a story not for this blog), and because I am a Safety Engineer with all parts of my being and feeling there was now the time, to split up my Twitter account in 3 theme centered accounts:

From now on, I have

@haenbee for all things of life, news, technology and science in general. It was my first account on Twitter, and I want to keep it for all the stuff which match not one of the themes listed below
@EnrichedGamesHB for all things about Serious Games (aka Enriched Games), including Seaside, Pharo and WebDesign and Computer Graphics. In fact, not just gaming, but all issues which are related to the realization of my games will be covered here. For my plans, I choose Seaside and SVG, because here I have the most experience (which is not much, either) and Smalltalk is still one of the most productive environments
@QuMeSA_HB, the account which is connected to this blog, and where I consider things about Software, SW Architecture, Modeling, Functional Safety etc. Especially I want to discuss about the problems I sketched in the last post.

A special role plays AI: also one of my interests, also for gaming, but this theme is really spread over all fields: it touches human being, gaming, software, science in the same time. So you will find AI issues in all three accounts until I have a better idea ;)

So feel free to follow me or discuss with me, I really be happy for every follower and discussion peer to talk about my ideas and of course his or hers. Discourse is one of the most important things, and the Internet today gives us the chance to really do this crossing any borders and culture.

Enjoy !

Functional Safety of Software

2011-06-02T13:31:00.004+02:00

Since 3 years, I'm working as a Safety Engineer. Starting in the Air Traffic Control domain, I now have to consider the functional safety of locomotives. So in parallel, my perspective is extended to physical, mechanical things, which is really cool.

Along with this evolution, my interest is focusing on the question how software has to be built in a functional safety related context. This is a question which strongly relates to the problem of how to overcome the human imperfection and avoid human errors in concept, architecture and in the whole technical realization of a system from the beginning. It is a question for methods, provability and well known and well tested engineering practice.

In consequence, today my view on modeling of requirements, system architecture and function networks as well as on the computer science itself has changed. I see now the challenge and the benefit of tool based software development in a different light. I see, that we need a information science, not a computer science. I understand, that we are still searching for the rules of information which correspond to the rules of physics in the mechanical engineering. Software Architects, Software Engineering, are terms with today expanded meaning.

Therefore, I want to add functional safety as theme for this blog, and this is well done, because metaphysics is the only hope to get further :) I will tell stories about communication from software engineers to safety engineers, the amusing stories as well as the horror at work.

So stay tuned :)

Programming on the iPad

2010-12-14T21:57:00.008+01:00

Since a half year I use my iPad every day - for reading emails, reading the Web, reading my Perry Rhodan issues and other magazines and books. A few weeks ago, I started using iPad to write protocols and use the Numbers App from Apple more and more.
What I am missing is to write programs. I'm not talking about big software but really useful small programs. How could that be?

The iPad is the accessor to the Web. In consequence, programming on the iPad doesn't mean to program the iPad itself, but to program in the Web. Thanks to Google and others, office documents can be produced and changed in the Web. So why not programs ?

But what would a Web - or better said - Cloud hosted program look like ? In the age before the cloud, creating software was done by accessing the capabilities of the operating system - the APIs - to fetch data, build graphics, to persist data and create a data and control flow with a programming language. Well, the Cloud has no operating system, but it has also capabilities to fetch or send data, to create graphics via SVG or WebGL and to store data. Even such kind of API are available, which in fact are the REST, SOAP or other interfaces. Twitter, Facebook and other portals use such techniques. The problem is the language. If there would be such kind of editor in the web, and a programming language - or let's better say if there would be a Cloud hosted development environment, which would allow to use and bind this "Web API" with data and control flow, yes, then I could program with the iPad. I could program algorithms, create visualizations and would not have to think much to store data, or to access data. Where my programs are stored would not be relevant at all. Just make data processing in it's strikt and pure sense.

Unfortunately, I don't know such a Web Development Environment. Is there any ?

Future of Functional Safe Systems

2010-03-21T13:31:00.009+01:00

One of my responsibilities in my job is functional safety. Roughly speaken, functional safety means that running the software does not induce any unaccaptable risk. Typical software applications which are safety relevant are avionics software, train control applications or medical devices. Today, the general approach to gain functional safety for an application is formed part of two basic things:

to demonstrate, that the software works correctly, which means that it works as the requirements has stated, and
that everthing is done to avoid errors rooted in human factors.

There are many safety standards in civil and military area, which prescribe methods to meet the objectives 1) and 2) in a repeatable, predictable and documented way. Many best practices of hardware and software engineering have influenced this standards.

The problem is, that there is an underlaying assumption, which is critical from my point of view: that the hardware/sofware systems are complete deterministic in the sense that any state of the system can be predicted and tested for any time point. We are familiar with this from the classical physics: if an differential equation of a system is given, we can - at least in principle - predict the system state for any time point.

But it is not hard to see that all systems getting more and more complicated. To prove functional safety requires more and more effort, and get more and more gaps. We know, that systems exist with very complicated behaviour: fractal systems or cellular automats are well-kown examples. Often, the only chance to predict their behaviour is to run the system from the beginning (the boudary conditions) up to the point of interest. And we know, that complicated interwoven structures like technical systems emerging today can behave unpredictable or "chaotic". They look like indeterministic systems (even if there is no indeterministic given in a strict mathematical sense).

And at this point, we are lost with our approach to functional safety. So what can we do ? Give up the objective to prove every function or behavior for correctness ! Huh, that would mean to allow errors, even not anticipated ones. Yes ! The future safe fault tolerant system (FSFTS)have to be designed that they can operate with errors, even unpredictable errors. Or in other words: the engineering methodology and practice have to be aligned to the objective that a system is safe not because we know every static and dynamic detail of it, but because errors does not harm the system (and if you see security issues as errors, it could be really interesting....).

Now, can we find conditions or characteristics of such systems, to find an start ? In fact, I always thought about it but I have no resilient conclusions yet. Many experiments have to be done for this. Anyway here are some basic assumptions I can share:

Assume, the state trajectory of a FSFTS is not known in detail for any time point, but it is limited in state space and constrainted by some attractors (well-known example: Lorentz attractor). In fact, a single line in state space will become a band of lines. The state trajectory is looped, but not necessarily closed in itself. Then, an error might move the system trajectory, but within this band, and the attractors ensure that the system will kept in its bounds.

In the next step, assume this sysem state trajectory will be partitioned in trajectories of several subsystems. Now if some attractors would influence some of other subsystems, we would get connected systems which would emerge in the sum functionality. In other words: I would expect that in future system design would mean to engineer attractors system state boundaries and trajectory bands. Engineering would mean not to engineer the system trajectory time point for time point, by cause and effect, but to engineer higher dynamics and (in behaviour) complex systems. I doubt that the available mathematical tools would help us here, I think we need some new basic insights in the area of complex chaotic systems. In this context it is also interesting to the progress and methods of system biology.

Well, we are far away from this, and many questions left. But I personally believe that will be the future of engineering.

Ideas for Processing II

2010-02-14T18:15:00.008+01:00

In the last post, I sketched the idea of a graphics subunit, which just takes render tasks describing *what* to draw, an which has the full responsibility and specialisation for *how* to draw. An graphics subunit independent in this way would have many implications, and the technology necessary to implement it goes beyond pure geometrical or mathematical techniques. Knowledge and learning of machines will also play a important role for its implementation.

Now, the questions is how we could come closer to this goal. One interesting path may be to flip the processing chain of vision: instead of recording images by an eye (camera) and process them like the humen vision system does, let us drawing pictures by using remembered pieces of images. In the wide area of computer science research

there exists already a field called image-based rendering, which tries to create renderings out from images recorded by cameras. But as extension to this more more less geometrical way of thinking, I would like to add the approach of the flipped human vision chain to the term image-based rendering (because it is simple the best term).

Where comes Processing on the scene ? Well, it is a big step to model the human vision system. One powerful and promising approach is the Hierarchical Temporal Memory Method introduced by Jeff Hawkins and his company Numenta, Inc. But for the first step, it would be too complicated, even if the underlying principles are not. I would prefer to start with small experiments, done in Processing.

One of the first experiments will be to create an Processing application, which draws some graphics with its own dynamics. It is not the objective that this graphics shows anything special. Then, I will send this application, lets call it the "Drawer", signals in form of data packages, generated by another application (Haskell or Erlang). The Drawer should then react, change its drawing dynamics according to the signal received. I want to investigate how this system can be set-up in a way that wanted graphics can be drawn by providing selected signals. BTW, the signal path is planned to be in XMPP.

The next step would be to add memory, where the course will be taken to the flipped vision processing chain. Processing is a very good tool for this, especially since it is possible to use Scala. So let's start !

Requirements for a Knowledge Management Tool

2010-02-06T20:07:00.010+01:00

We are in the information age, aren't we ? Well, we collect information, put it in big data bases, or distribute it accross the web. But in fact, we collect no information, but plain data, numbers, texts, images videos etc. All our computer based technology is designed for measurement and collection, this is their strong part. But I want to access information, and - in the best case - only that one which belongs to my problem.

So, the question is, how can we transform collected data to useful information ? Many philosophers had discussed and investigated, what knowledge, insight and information is. I love this point of view:

The humans are able to act in a free manner, but actions are conditioned by situations. In the course of the lifetime, a human experiences many situations (described by the data provided from the senses), and the actions performed in that situations induce new situations. Therefore, one thing is clear: data must be associated with situations, otherwise, they are meaningless, without any value for the existence of humans.

Another thing emerges from the necessarity of decisions: we all know, life faces us with problems, which force us to decide to go the one way or the other, to choose between options. The decision is the predecessor of the action, and the problem is the predecessor of the decision. Because we remember the association between situation, action (as consequence of a decision as a consequence of a problem) and the result, we can decide better in future, in more or less similar situations.

But background knowledge or experience for itself is not sufficient to decide well. A goal is needed, or let's say more generally, an intention. The experience (the situation-action-result tuples) tells us which action in the given situation may have the biggest chance to lead to success in respect to what we want (the goal, the intention).

Summary: facts (data) - situation (context) - problems(questions) - goals(intention) are the things which distinguish data from information: in combination, they help to determine the best action to take. For short, this is knowledge, in some sense it is the equation of facts - situation - problems - goals - actions solved for actions.

And from here on, I can tell what my requirements to a Knowledge Management Tools are (some things I can not explain more detail here):

allow to collect any kind of facts, any type of data
allow to collect context descriptions
allow to collect problems
allow to collect intentions
connect all these elements, by n:m relations
allow to weight (again) these connections at any time
allow to add or discard any connections at any time

Unfortunately, we have no advanced Artificial Intelligence today which would allow to code and access any kind of gray and color of the color set of life. We have to categorize and quantize what we experience every day. And we have technological limits. In respect to this, I would add this requirements:

visualise the connections
allow to classify context, problems and intentions
find connections automatically by statistical analysis of words or other means
allow to create context, problems and intentions recursively out of other contexts, problems, intentions, data.

The last requirement is inspired by the observation, that life is a steady flow:

allow to create contexts out of sequences of conditions or event descriptions.

Can't wait to play with a system which provides this features. So I hope, someone will implement this *few* requirements soon :-)

Ideas for Processing I

2010-01-31T14:29:00.010+01:00

Today, computer graphics is done by making geometry. Shapes like circles and rectangles, lines are placed in a canvas tagged with a (rectangular) coordinates. Colors and length are prescribed or calculated by providing numbers. In the 3D domain, the things work similar. Raytracing and other 3D to 2D renderings are based on geometric optics. Is there any problem ? Well, I will explain what I think about.

Since years, I was fascinated when Mr. Data in the Star Trek movies and serials said to the computer: "Computer, show me", and the computer draws the desired information in the best way, without being told to stretch, zoom or even use coordinates. From such scenes, I always got the vision of a computer kernel, which calculates, deduces, collects, and a graphical subunit, which does all the graphics. And the important thing for this is, both, the computer kernal and the graphics subunit, only *talk*. No API calls. In order to illustrate this, here is some example dialog:

"Hello Graphic Subunit, please display planet Venus, a starship type Klingon fighter in standard orbit"

"Hello Graphic Subunit, please display this 2D point set in a chart and this text"

In fact, the collaboration of the computer kernel and the graphics subunit should be the same as a customer which goes to an artist and says "Artist, paint a picture of me, embracing my power and glorious". Although many questions arise from this, I only want to point out the fact, that just the artist (the graphical subunit) has to bother about information which affects *how* the picture is drawn. He is the expert for graphics. The customer (the computer kernel), only should tell *what* to draw. In todays technical world, mostly the webserver or an application core has to deal with geometry and rendering. Of course, today graphics is described in abstract coordinates, presentation and content is divided by HTML and CSS. But that doesn't change the fact, that too many aspects of graphics and geometry are part of the application core. The latter has to call API by providing shapes, coordinates, colours.

Our technical possibilities are not powerful enough to come just closer to what I described above. At this point, I have to state a fundamental criticism: as far as our graphics technology is only restricted to geometry, it never will be powerful enough. Here is no place to provide reasons for this hypothesis, but it is my strong belief. To prevent misunderstandings, is important to note that, if I say geometry, I mean the mathematics as it is known and practiced today. I think it would extend our possibilities if we investigate more in things like image based rendering and to flip the human vision processing into the opposite direction. Vision then becomes rendering.

Well, I know, these are big mind steps and not a smooth chain of arguments, it is more a set of ideas. But anyway, this popped up some ideas to me for doing some experiments with Processing. The post is long already, so in a later post I will sketch some details.

Time to Change

2010-01-17T19:13:00.006+01:00

In the last year, many things happened in my life as a computer professional. I am writing no code anymore, I am now working as a safety, quality and requirements engineer. And I am glad about it. Let me explain, why.

In the last years, more and more the doubt came up to me if programming is really that what I am strong in and if it is what I enjoy. Even working in different companies, where completely different software were developed, in Smalltalk, Fortran, C, C++ and and means, I always had the feeling that I doing the same frequently. The problems of software developing repeat, the kind of solutions were well-known. I met many people, all of their own style, I had bosses which could never be compared, which was and is good. But the game - software development - still was the same from my point of view. Different in colors, in tones, in details, but in fact the same. No big progress, as also some well-kown mastes of software told. And I had and have so much more interests.

I know, this picture is not objective, my losing interest and my perception of software buisness have impact on each other and are not decoupled. But which is really the cause of what doesn't matter in consequence. So I decided to take a way in my carrier which lead me away from software development. That's why I am happy to work as I told above.

But what about the hobby ? On the private side, I looked at many programming langauges, read about software processes, design patterns and new approaches in the software domain. But the doubts described above take place here again. And at the same time, old loves came back to me: philosophy, electromagnetics, teaching electronically, the question how a set of neurons can think and get insight.

I've just finished the great book "Coders at Work" of Peter Seibel, which contains interviews with some big persons of the software buisness. And the part with L Peter Deutsch, which leaves the software buisness at some late point in his life, convinced me to make this decision: even as a hobby, software development will no more the objective of my hobby activities. This means, to be precise, to look at patterns, architectures, languages for its own.

Of course, I will program to let my new ideas come to life, maybe games, graphics, experiments. But the ideas are now in front, not the question what is the best language, the best approach. I make no attempt anymore to make software development better (one exception: requirements and safety engineering). That let be the task of computer scientists, which I am not. Just be creative, as long it is possible.

For this goal, Scala and Processing had attracted my interest, which both working with the Java environment. The Java environment has so much possibilities. Erlang is nice for experiments in the artificial neural network field.

But don't misunderstand: I will not close my eyes. I will look how technology and software science is going on, because to track and judge the social impact of new things is important. But my role will be from now that of an observer, not an actor of the computer science.

Holiday Project 1

2009-08-30T23:37:00.014+02:00

As always, I planed some hobby activities for my holiday, because during workaday life there is always not enough time.
Project 1 was a drawing exercise in order to get more practice in line drawing and inking. Also, I experiment with colors and usage of Layout Markers. And here is the result (please regard it with a favor - I'm a learner :-)

I call this picture Experiment #1 : "Crossing". As can be seen, I am still fascinated from the idea of steam punk. It is an interesting task to think about which parts a steam man would comprise, and which are the characteristic building blocks of such creatures. I am very sad to have not more time to investigate this question.

One intention of this excerise was to work out to draw lines in different weights, and to get comfortable with the foundations of comic inking. Although I've done some progress, I have still huge respect to the professionals of the Comic Szene, it is really difficult to draw lines accurately ! As an result of this exercise, I am also starting to get used to Layout Markers.

It is always interesting to experience the relation of drawing to courage and resolutness. A line must be drawn without doubt or fear about error, which is also true for shadows or dark areas, or light spots. Here, only practice and strong observation will help ;-)

The next picture is planed to be carried out in oil pastels, but I can not say if my holidy is long enough. Project 2 is to create a game prototype in Processing, and Project 3 is about Erlang programming. So we'll see......

Observations from a mobile world

2009-07-11T11:38:00.010+02:00

Some weeks before, I bought a 24 inch Full HD monitor with HDMI interface. The original plan was to make the first step to a Full HD television and to have a display device for the Sony PS3. The world of BlueRay calls me loudly ......
Todays monitors can be used nearly for all, thanks to the combination of the interfaces, including sound speakers. And of course, it can be used with a Mac, in my case a white MacBook. And whow, what a feeling ! Even DVDs, rich content websites, all looks so great !

Today it was the first moment, I used the MacBook again as a notebook, with it's own display. What a shock ! All is so small, no oversight, colors and brightness, no usability, no fun. But, hey, every day, my iPhone has to show me WebSites, provide me translations and the last news from Twitter or other news portals. And this display is much smaller. And it works for me so far. Seems like a contradiction, doesn't it ?

Well, in relation to the iPhone, another effect takes place: it works the better, the more the Apps or WebSites (more exactly: their iPhone version) are adjusted for small screens. And because there are many iPhones out now and in every-day use, you can really find WebSites in fine iPhone version (and this is a completely different thing as the crappy WAP things in the past....) which show, how it could look like to design an information or an operation interface for the capabilities of the destination device. Some WebSites could be used much better in the iPhone version because they show exactly what you want, and not more (advertisements....here blinks it, there are flash something, over there a color explosion, bah) !

Now, the current or near-future internet techniques provide so much opportunities for new ways of information and operation to the users. Have a look at HTML5, O3D, AJAX, the new JavaScript engines in modern browsers: the internet world is colored and rich as never before. And why should all the Web Designers not use this things and provide us with optical beauty, operational high usable experiences ? Display space is not a problem, look at the prices of >22 inch devices !

But my poor Mac is born in another world, as the idea itself to have a movable computer, too: its screen (and resolution) was great some years ago, today, it is catched between the iPhone and the big electronic color picture devices on the wall or on the desktop. The great user interface of an Mac OS can adapt to a big screen quickly, size can be turned to usability at once. The other direction is full of restrictions. Mac OS is not an every size auto-adapting paradigma system, as all software systems I know so far.

In fact, my observation is this, based on one year usage of the iPhone, 6 years of (Apple Mac) notebooks and now a 24 inch 16:9 display: size doesn't matter, if the informational and operational design reflect and support the natural way of use of the device.
(Important remark: the WebBrowser and the native Operating Systems converge quickly, therefore the following is stated only in respect to the Web, but is valid for OSes, too).
Because the new Web technologies provide a big toolset to implement nearly all ideas, and because the Web Browser is a potential flexible thing (it looks like a simple text file tells him to look like), I expect from the UI designers to reflect and to use the nature of each possible category of display device. You *can* use a iPhone, a Netbook, a Notebook and a wide Cinemascreen with fun and operational value, *if* you adapt not only colors, text font etc but also the paradigma of visualization of information and interactiviy !

Please designers, meet the challange, use all your creativity to give as an interface for every device, and be aware, there will be more in future: tablets with touch screens, mini projectors and gesture recognition............. That would be great, and more, it would take us to a real flexible and real mobile information society :-)

Steam Gestalt

2009-04-25T11:16:00.009+02:00

At this time, I am productive in drawing. This is cool, because in the life of Software Engineer or even Software Architect, the creative part of my person has no possibility, or at least not enough, to come out. If my information is true told from many people, then I should compliment Google on let their Software People work for some fix part of the whole time on their own ideas. I am shure that gives much value back to the company, even if this benefit maybe not measurable and described by any numbers.

But back to my work. One of my friends told me about a game embedded in a fictive world where is no electricity, but steam instead. I am very excited about this idea, so that I had to draw a gestalt at once (originally I want to ink it, but unfortunatly there is no time in the moment).

So It seems, that I got an big interest on designing gestalts, their equiment, and gesture. Of course I am far from perfect, I need much more experience. But I have a sketch block now, and where ever I got some idea, I will take the pen.

UML in the Functional Programming world

2009-04-22T06:49:00.004+02:00

UML is a well known standard notation in the context of objectoriented design and programming. It allows to define classes and their relationsships. It makes it possible to display Use Cases and the Activities performed for them. They way how objects interact together can be visualized in more than one way.

The problem is: it's all about objects. But we are in the age of a new rising star: the functional programming. Here we deal only with functions. There is an input, there is an output, no state. Just a rule to map the input to the output. No behavior. Just a chain of input - output mappings. It seems that UML doesn't fit very well. Some languages interpret functions as objects, but in the end that doesn't help. Functions are a mathematical construct, they are best defined in the way we learned in our mathematics education.

Let's go a step back and ask: what is the goal if we use UML ? It is used during the design phase, so one goal might be to communicate architectures. An other goal might be to write down design elements of the software to build, on a level which allows to use abstractions and to suppress unnecessary details. Of course, abstractions and communication is not only about data structurs, but also about what is done with this data, and by which entities. And in the end this is the nature of using UML: finding out and document what is needed, what happens, and what is get.

Ups. Thats reminds us of functions. There must be something wrong. So, again, one step back: how should we document software ? Actually, the main purpose of any software (which is not used for controlling some device, because their nature is just to be an extension of mechnics) is to provide information. Information aggregated from other informations, as well as calculated, filtered, selected and transformed information. The nature of information is to be data, which have an intention: a question to answer, an goal to achive. If we describe the data and their intention, i.e. the information, and their origins and lifecycle, we have in fact described what a system is. It doesn't matter if the technical implementation is done by functions, or by interacting objects. Thats a matter of the detailed technical description, which is important only for a small set of people (and it has to be decided for every project if the code is the documentation or any detailed UML diagrams or equations are needed). Or in other words: it is in matter of level of detail.

Let us note two additional observations:
1) The data comming from or going into the real world can be modeled better by objects than functions.
2) The context as part of the system environment is the source of intention (what will I achieve, why I do something).

Bring this all together, we can see that UML helps to document the data and their intention and their lifecycle via UseCases (maybe annotated with activity diagrams, for context and intention), Collaboration diagrams (for lifecycles), Class diagrams (for the pure data). In this sense, UML should help document software independently of the programming paradigma used with a sufficient level of detail for the most cases. And if more detail is needed, UML is appropriate for the OOP and mathematical equations for FP (and PI calculus for heavy concurrency systems).

Requirements: The Picture of Software

2009-03-25T19:40:00.006+01:00

As we all now, all software development starts with the wish or the need of a customer. The customer has a problem, that he (or she) wants to solve. Then it might be, that the customer has also the idea of a possible solution in mind. "If I had .... I could..." or "if I get ... then I could" and other signs of such ideas is well known.

In most cases, this idea is embedded in the domain of the customer, it adresses data which are key parts of its domain. Or it is related to actions performed in this domain. In either way, it has no technical nature. (It may be that the customers domain contains technical things, computers, machines, but then they are part of the domain as all other and therefore are natural to him.)

Then there is the other case: the customer has no idea, just a problem. But then, he has at least a goal, which means there is an idea of a situation which he (or she) wants to achieve.

Now it is our job as software professionals, to draw a picture of a system, which, beeing embedded in the customers world, would solve his problem and let him reach his goal. If we have this picture and it its approved by the customer, we could build the system and the customer will be happy.

That sound's easy but it is not. The customer has a sound picture of his domain in mind, but a weak imagination of the new system (well, he is no technician...). And this new element must fit in. The software professional on the other side has a strong imagination of "his" new system (what a wonder...), which must be embedded in the - from his point of view - weak picture of the customer domain. It is easy to understand, that the weak parts are in danger of beeing forced to fit and therefore getting distorted. Now the problem is obvious: all parties have different parts of the picture that are weak. In consequence, the resulting overall picture of the customer and the software developer will differ necessarily.

We know, that an iterative process for software development is the best solution. By creating prototypes and mock-ups, things that can be "touched", the picture comes out of the head of all parties and can be experienced directly by each other in early project stages. And because it is not feasibile to come through this in one step, many steps are done, where ever news prototypes and mock things display and stress different aspects. But in the sum, over all iterations, the picture should become more and more equal for all parties. The picture of software becomes clear and sharp, we've got consensus. (BTW, this would be the planing guide for iterative processes: touch all constitutive aspects at least one).

Sounds easy. But software is developed in teams, and not all members of the team can talk with the customer directly. And more worse it is not always possible to talk with one customer, there may be many stakeholders. So the picture in mind must be communicated via documents, but how ?

To find an answer, think about a patchwork image, and the task is to fill a empty place. So the first question is: the shape. Which shape I need to fill ? Related to our software project, this would be the interfaces, logical, functional and physical. Then, one might look which colors would match, then which things the part should show to continue shapes or patterns of the whole picture, and so on. That means: for communication via a documents, one should take certain point of views to the domain and the new system, explain them and why the part fits in the hole. One chapter one point of view, with the goal, to come close to the picture of software.

If all important aspects are described like this, then there is a chance that many people which read the documents become a more ore less comparable picture of software (and its environment) in their minds and the right software at the end.

BTW: There are people, which can design such missing parts of a picture handling all aspects at once - we call them artists.

Started my work on Philosophers Erlang SVG Server

2009-03-15T11:36:00.010+01:00

It is time now to start an project which is in my head a long time: the Philosophers Erlang SVG Server. A good friend helped be to get through the kick-off and to realy do it, so now I have set it up as an Google Code project. The beginning is always the hardest part, and it is done.

Details I am writing in the wiki of the Google Code. For now, there is not much to read there, but I hope it will grow steadily. Also, there is not much code yet, but Eclipse is set up with Erlang plug-in Erlide and direct contact to the SVN of Google Code, so, it can really really start.

Loving SysML

2009-01-24T19:47:00.003+01:00

Since some weeks I am working with SysML, the special UML profile for Systems Engineering. It uses the most important diagrams of the UML, like Use Case, Activity, Class Diagram, and introduces some additional, like Block diagram and Requirement diagram. The more I work with it, the more I like it because for system engineers it has some advantages over standard UML 2.0:

The concept of <<blocks>> is more flexible to use. It has class semantics, so it can have attributes like subblocks and parts, and the aggregation and composition semantics. On the other side, a block can be a broad set of things: a feature, a software or hardware component, an functional element. A block itself can be bind on parameters, equations, constraints and other. Therefore, it is a little bit more flexible than the <<component>> of standard UML. And this is, to what a systems engineer is often faced to: very differenct functional elements, which can be a physical thing, a device or a logical set of harware and software, and which are not easily match the classic categories of pure software engineering.
In SysML you can model requirements. You can relate them to each other, for example with <<refine>> You can bind them on Use Cases, on Activities and Blocks and make your solution simple traceable. Using the right tool, you can exchange requirements with Telelogic DOORS (R) and other requirement management systems.
By using the <<allocate>>, it is possible to relate elements of a conceptual level to elements of the implementation level in a simple way. So you can describe which element in the system is introduced ("allocated") because of which feature described by the concept or requirement. The consequence: bidirectional tracability is easy to maintain.
These simple but powerful constructs make it easy to model product lines: because a block can be many things, it also usable for setting up feature diagrams. Applying some additional stereotypes like <<optional>> or <<variationpoints>> to blocks and using the <<allocation>> and <<satisfy>> mechanism, a variant configurations can be documented and can be mapped to the implementation level. And that's it !

One word about tools: UML or any profile from it will be used by using a special software. Of course, sometimes you write on whiteboards or paper. But for real-world complete models, a software is needed. A good software ! If this has some useful features and good support of the Metamodell of UML, working with UML as a tool comes close to what CAD is to mechanics engineering: the model will not be just a collecton of pictures, of static documentation, it will be a complex database of knowledge, which can be modified, worked with, to which queries can be addressed.

For example, I have set up a empty UseCase diagram, and if I want to add assozations, or I want to find out which model element is connected to which other (a "query"), I drag the elements in question into the diagram. Now I have all functions needed in the context menu of the elements, and can perform my task. After this, I make the diagram empty, which does not delete the model elements, though. The empty diagram is like the texteditor, or the query interface for a database.

What I want to express is, that the way how one works with UML is influenced hard by the comfort and strengh of the software in use. Using UML as a language, as a knowledge constructor and maintainer, not as just a notation to document things, is possible, if the software is good, and only then UML let access the engineer the real power of itself.

Requirement landscape with Croquet

2008-11-17T20:10:00.005+01:00

Requirement Engineering is something which I'm looking at for many years now. And I always was and be interested in this. But one thing I am still waiting for: the visualisation of requirements.
So one might ask: visualisation ? Requirements are texutal, semantic-rich objects, nothing which would come close to that what is needed to making charts or some interesting 3D pictures. Well, this may be right. But requirements have structure: they are related to other requirements, they build groups. In addition, they have an inner structure, if they are built using methods available for professional Requirement Engineering. Visualizing requirements related to such structure aspects would be the same as visualize the network or graph of requirements. Clusters or too sparse regions of the requirement network should be visible at once.
But I think, there could be done more. The set of requirements should describe as complete as possible the system to build or to engineer. This set as a whole should be able to induce the picture of software. By reading the requirements, one after one, this picture becomes existent in the mind of the reader, and its shape and details become more and more complete with every requirement read.

But: wouldn't it be nice to visualize exactly that process ?

In the result, this visualization would show which requirements covers to which extent which aspect of a system. For example, the system would be a landscape, or a city street plan, and the size and position of the requirements show there contribution to the whole (system).
Since a while, I asked myself if Croquet would be a optimal tool for such visualizations. The space metapher and even more the collaboration possibilities of Croquet seems promising for such visualization experiments. Unfortunatly, I have no time, so I really hope that some other will do some experiments in this direction.
This is I would do:

defining a meta-model of requirements, to adress the aspect of their inner structure, just like EMOF for conventional models. I mean not a semantic model, only a structural model (Conditions, quantors, action, object, subject, test criteria ...)
defining a meta-model for describing always needed aspects (=questions) for a software project, let's call it system meta model. You could imagine this as a checklist of questions need to be answered in most projects.
defining a semantic meta model, to describe the relations between semantic in general, requirement parts, and the system meta model.

That are only raw ideas. Too bad, I had no time.....

Decisions of a Software Architect

2008-11-09T21:24:00.005+01:00

In the past, it was not so clear for me what are the things which are constitutive for the work of a Software Architect. This is especially true if the question comes up how to distinguish a Software Architect from a Software Engineer. At the moment, my work for the company is made up of UML, pure architecture design and requirement engineering. From this, I remarked some things which may be surprisingly important aspects of the work of a Software Architect. I will call them "surprising", not because I never thought about them, but because their real effect and importance for the practice hit me strong in these days.

If a new system has to be made, it all starts with requirements. Everyone know that. Some people regard requirement engineering as collecting a bunch of text or a big set of items in a database in order to describe some properties of the system to build. For me, requirement engineering is much more: it is the search for and identification of the model describing the customer universe at best. Such a model must describe the processes and informations which constitute this universe and in which the new system will be embedded. We will see why this is important.

From theory I know about the value of Use Cases and UML Activity Diagrams in the context of requirement engineering, but I was surprised how useful they are to perform that requirement engineering as desired above. By bounding requirements to Activity Diagrams and Use Cases, it is possible to get an output of a requirement engineering phase which - beside the description of the properties of the new system - give an answer to the question, which actions are performed by who, which are the needed informations, which are the resulting informations and how the system to build will fit in this universe.

This all is the input for the Software Architect, and he must use it to find answers to this question:

Which are the parts of the system to build, and how must they interact ?

Well, this seems trivial, and it is even more easy if processes and information flow in the customer univers is known. But now comes a surprising aspect:

Which of this parts of the system are described at best by the data they use and compute, and which parts are described at best by the processes they perform ?

The answer to this depends not only on the properties of the future system, it depends strongly on the nature of the processes and information flow in the customer universe. The outcome of the architectural decision has very long-range consequences because it determines the complete design- and implementation process: a data-driven architecture has other characteristics than a process-driven architecture. Shure, data and processes are not independend. But for the technical design process it is different if one think first in terms of data or if one think in terms of a sequence of actions.

In the data driven world, the next decisions are related to questions like who, how often and in which way the data access will happen. In the process related world, the Software Architect has to decide about events, sequences and has to work with the time.

Beeing at this stage, the next suprising aspect, the next decision point has to be regarded, which as hughe impact to the design:

What are the points of possible change ?

Here, the Software Architect must invest phantasy and experience to identifiy the "weak" parts in the required system. He must look for the things which may be not so fix as the requirements suggest, and as a result, he must decide what things of the system (roles, data, actions) must be designed in a way that a change would be easy. This is only possible if the requirements describe more than the system itself. I think that the best sources to find such points of possible changes are the relations of the system to the universe of the customer.

And here, we are at the heart of the work of an Software Architect, as I belive it: find a design, which make change in the forseeable way easy. This gives the material to make further design decisions, it helps to reduce the set of possible solutions for a design task, to make the system that what is every time told to us: make it simple, but not simpler. Design for change, but only for that, which will be needed. The power of design for change is that what me really surpised ....

Now the detail work can start. But one thing remain, which I often discussed with colleagues: what about technical constraints ? Must an Software Architect know about the possibilities and properties of certain technical solutions ? Well, at this stage, my assumption is that he must not. In the opposite: the Software Architect must find a design, which can adapt certain techniqal constraints. So the decision point would be:

How can the design made robust against the technical constraints and implementation ?

If writing an required amount of data on hard disk is not possible by simply writing to one single file, an architecture is needed which handles multiple files. The Software Architect can not know all detailed constraints which comes from the many-years experience of a software developer, or from a data base specialist, a web specialist etc. In addition, such constraints are change points "from the bottom". Yes, the architect must have a rough knowledge of what is possible with today techniques, but only in order to be not too unrealistic. Therefore, a Software Architect must keep contact with specialists . By the way, here I also see the border to the role Software Engineer: this one must have detailed technical knowledge, and therefore may be responsible for the "lower" or detailed parts of an architecture. He has to bother with detailed technical details.

So, as a summery this decisions help to come to architectural decisions:

- What are the roles, and the parts of an system, and how interact they ?
- Which parts are data driven, which are process driven ?
- What are the points of possible change in the customers universe?
- What are the points of possible change from the technical implementations ?

Of course, it will not be all of the Software Architect, but it really helps ;-)

Back to old hobbies

2008-09-22T21:00:00.006+02:00

These days I have returned to work with Erlang. I can not really say what was the reason or impetus for doing so, but anyway, Erland is an interesting language, now and in the next time. In order to support my work a little bit better I have implemented a very simple syntax highlighting, compilation phase and file type for Erlang in Apples Xcode. Of course Xcode has its flaws, but the general approach it provides has some advantages.

What to do in Erlang ? Well, I had never lost my interest in SVG, and so I will try a little render engine for SVG, Not because I think that is what the world is waiting for, just to combine to interesting issues, and to provide a graphical interface for my Artificial Neuronal Network and Cellular Computing engine (dream, dream). Such kind of applications may be well suited for the distributed computing approach of Erlang.

The other thing I returned to is drawing. In fact I never drop this hobby, but in the last months and years it was put in deep background because of time. That should be corrected. Here, my main interest are characters or figures, in the style of Cartoons, Comics or Oil Pastells. The picture in this post is one example, a result from a so-called Manga drawing course. Ok, the word "course" is not appropriate, it was just a kind of gathering, but the people there were really interesting.
So let's go on !

The word "automatism" or Secure Software, Part II

2008-07-27T18:18:00.006+02:00

"Automtism" is a difficult term. From principle, it should be a positive word, because would'nt it be positive if a machine takes care about things which otherwise I have to do in a boring, time consuming way ? Doesn't automatism mean to get the result with nearly no effort from me ? My observation is, that the more a person knows about computer and software, the more the term 'automatism' becomes negative. It may be the wish and the expactation to keep control, as a programmer has the control because he is the creator and master of the software. Interestingly, sometimes this exceeds the wish for comfort.

Because of this, I use the term "automatism" or "automatically" very carefully. Of course, the user should get what he want with as less effort as possible. Give him the result with a few actions. But this would not be the justification for an unforseeable, magic and unobservable behaviour of the machine. The user must be able to imagine whats going on, he always should be able to explain himself what the machine is doing (in principle, not in details, of course!). The feel of control should never vanish.

So, whe could extend the definition of Secure Software to

a secure software is one that always do what I want,
and so many times I want,
and which never let come up any doubt what I should want,
and which do what I want for exact all my data completely or never touch them at all
and which never let come up any doubt that it is all really true.

From this insight, it is important to base the automatism on well-defined rules. I mean not formulas, or detailed algorithms. I mean top level rules, like "all you create with this software is a document which could be saved and printed" or "a crane has a rope which can be winded". They should explain how someting works in principle. Or in other words: for the small little universe (often called "domain") every machine is embedded in, such rules would be the basic metaphysics. Therefore, I will call them "universal rules".
Of course, the set of Universal Rules should be complete in the sense, that all machine behaviour could be explained with this them. The set also should be limited, such that a human can keep the hole thing in view.

If think about an new architecture to create, I always start with identifiying roles (there is more to say about roles later) and the Universal Rules set. From this, introducing classes and behaviour is a straight forward task. In fact, this is also the reason why I love to use Smalltalk in this stage of software development: it allows my to quickly try out the rules and roles, and adapt them if they not match the problem to solve. In this sense, Smalltalk is my Universal Rules explorer :-)

In this way, I belive, it is possible to design software which can do as much as possible automatically, but not exclude the user from what is going on.

Taking new point of views

2008-06-29T12:14:00.007+02:00

In the last view weeks, some new things came up which pushed me to new point of views on the world of software.
The first is the iPhone from Apple. I tried out the SDK, and I like it very much. Old feelings and memories came up from the time I wrote my software for my Diploma thesis on the NeXTStep. I like Objective-C, I like the graphics model (Display Postscript then, Qwartz or Display PDF now).... it is an exicting way to realize ideas.
But the property "new point of view" is not a consequence from the quality of the SDK or the language. The iPhone and its new way of user experience is the guide to look different to User Interfaces. Multitouch offers new ways of interactive work with data, and the limited screen size forces to reduce the optical design down to what is really needed. For example, I observed that for some tasks the iPhone is my favorite tool: there are some web sites which are optimized for iPhone (or mobile phones) so that they are more comfortable to use with such devices. And as a result, using the iPhone I only get the relevant things are displayed instead of the information flood presented on many current web pages when using the computer - and I hope there will be a lot of such optimized web pages in the future.
These two constraints - show the relevant in a small screen in a aesthetic (!) way - and make the data or the documents itself the objects of manipulation - are the reasons to decide to work in future with the iPhone and the SDK.
One remark: of course these things are not complete new, theoretic papers or books (like the one from Raskin an other work) described such problems and solutions already. Not to forget the original idea from the DynaBook of Alan Kay. But now it has practical existence, there is an interesting device, you can play with its hard- and software.

The other thing giving me a new point of view has to do with my work at the company. Here I got some insight in the field of "safety software analysis". Working in this area means to look at possible hazards, which can be caused by the software and how strong such a hazard would be if it happens. Then, in dependency which international or national standard for safety must be applied, the analysis starts to determine which probability of failure must be required from software modules or even single functions, if the hazard should happen with a given probability at most.
All these things have to do with cause chains, probability and analysis and modeling of software. Definitively my interest, but in the sum for me also a new point of view on software :-)

Design, everywhere !

2008-05-11T11:02:00.003+02:00

We are living in the age of Web 2.0. This can be seen because the nice designed Web is growing fast. CSS and modern Web Frameworks like Seaside, Ruby an Rails or Zope give people the option to match aesthetic needs and expectations. Even standard GUI frameworks provide graphical power that a real designer is needed to use this power to gain the best result. The time is gone where the limited, gray and strong shaped windows and dialog boxes been there and to which we believed to be accustomed to the last 15 years. Today we have designed Web interfaces, designed reports, designed user interfaces.

However, the word "design" faces us not only in relation to this "outer" things, the immediatly visible parts of software. Some people also think about software design, architecture design, system design and so on. But in this case, not the aesthetic aspect is adressed, these terms belonging to the inner part of the machine, the functionality, its building blocks of programming. All the things an engineer is called to bother with, not an designer.

The suprising fact is, that even GUIs are not well designed if their functionality is bad. Every developer beeing in contact with customers know this very well. In fact, all User Interfaces need both, aesthetic and usability. In consequence, I simply ask: can it be that the architecure design must have aesthetic aspects ?

The short answer is: yes ! All the years working as software developer in many different companies had teached me one thing: aesthetics is a good advisor when judging an architecture about it technical quality. As all measurement engineers know that the human eye can draw a mean line through data points very accurate, the human perception for aesthetics is very robust. But the problem is, that is is not very explainable, what "beautiful" or "ugly" is, and it is far more less explainable in what aspects "beautiful" design of a architecture guaranties a technical plus for its functionality.

So there is a mapping to be defined, which correlates aesthetic principles which technical creation rules. The goal of such a mapping would be to understand more of the mechnisms of technical design and to be able to teach it. Some simple mappings are well known, though. Symmetry is often a design gool in aesthetics as in technical design. Another is rich simplicity (about this therm I will think later). But there are a lot more, which many of us uses without beeing conscious of them.

But there is help: at the Software Composition Group at the university at Bern (Switzerland), there is a tool developped called Code City. With it, it may be possible to visualize a software such that the aesthetic senses can be used. So this tool is a translator between the technical domain and the aesthetic domain. Of course, this is only one possible solution for this mapping, but it is one we have now ;-). This tool is positioned in the context of the Moose I mentioned in other posts, and because there are efforts to port Moose to Squeak, I will hope that I can use all the other things related to Moose soon :-)

Logging the map

2008-04-27T10:11:00.005+02:00

A good logfile can help to find errors during software development in many ways. It can show which operation happens at which time. It may show important results, data, or content of variables which determines the control flow. Consequently the most common parts of logfiles are the timestamp, followed by some information about the operation performed at this time. This may be indicated by the name of a method or function, the name of an object beeing active or similar things.

Such a logfile can bee seen as a recording of things happening or occuring in time. Therefore, I will call it "software camera". It is one-dimensional, and therefore strong sequential. A program with its many branches, with its possibilities and options, will be serialized to one linear sequence of processing steps, and the "software camera" records them. This is very useful for debugging an application working on streaming data. The data itself are ordered in a strong sequence (in time), and if some errors only occure at some parts of the stream, logging as "software camera" may be the only way to find that error.

Now the question is, can be something other of interest than the time stamp and which part of the source code is active ? To explain this, I have to go into some details.

In the year 2006 and 2007, when I worked in Basel in Switzerland, I sometimes meet the guys of the Software Composition Group at Bern. I loved this, because these guys are very smart, and discussing things with them is fun. For example, I talked with Adrian Kuhn about an idea from him to create a software map. This should be like the well-known map of streets and towns, but it was not clear, which metrics should correspond to the metric "euclidean distance" as used by such a conventional map. As one possible solution, we discussed to use the distance of a data packet to the point where its processing would be ready. This idea is a consequence of data oriented design: all what matters here are the data and whats happens to them. The position of a data package would be defined by "measuring" how many processing steps are already applied and how many steps are to go. Time is only used for "speed" measurements, not as coordinate.

This thoughts were my starting point when designing a logfile for an project at my company. It is also an application acting on streaming data, and I wanted to write out information which allows me to see which data packet are at which point in the processing landscape. In detail, this was

identification of the specific datum (sometimes with or without values)
the action where the datum sits in front of
or the action where it is in
or the action where it came out.

I have not used any time stamp at all.
Going this way, it helped me to build the architecture such that it is robust to any way how datas are comming in. They could be shuffled, delayed, reorderd in many ways. Tracking the data through the scenery of processing helped my the to identify "unused roads", to small designed "roads" and important "crossings". In the next part, I will enrich the information such that I could generate SVG to create a real map. We will see.

To read more about software visualization, I suggest to look at the website of Moose , a reengineering and modeling tool. In its context there are many tools with nice ideas. It's worth to look at - and yes, this academic stuff *is* useful in practice!

Secure Software - Part I

2008-04-10T16:09:00.018+02:00

From time to time, I'm asking myself what secure software really is. Because if I would know what it is, I would be able find methods and tools to design and build such software. How should it look out, which properties should it have, how can I detect it ?

The trivial answer comming in mind immediatly is:

Secure software is one which never crashes.

That's pretty simple. Is'nt it ? But - what is a "crash", what means "never" ? "Crash" often associated with the well-known "Blue-Screen". Or with the Segmentation Fault. The program is gone away after that, it disappeared. That's the same if I click on "Exit" in a menu, which is no special thing. Well, it is not exactly the same, the further is not intended, where the latter is. So, is a "crash" the situation that a software stops doing what I want ? That description would match another observation of "crash": The program doesn't respond, the famous endless-loop. At this case, the software still exist, and it does something as well, but either it does not the thing I want, or it does it far too much.

First conclusion: a secure software is one that always do what I want, and so many times I want.

The bad thing is, that I not always now what I should want. In many situations the software must tell me about my possibilities, so that I can think about what I want. Some software is very smart: it belives that it knows what I want and does that in advance, to spare time and stupid questions (from the stupid user). Now - how can a software never crash, because it does exactly what I want all the time, if I don't know what I want or if I can't tell that poor little thing what I want ? May be I don't know what I should want to achive my goal to create something great, may be I don't know the full consequences if I want this or that ?

Second conclusion: a secure software is one that always do what I want, and so many times I want, and it never let come up any doubt what I should want to achieve my goal.

That sounds great ! But to be honest - the crash or frozen software is not the real bad thing. The real bad, evil catastrophe is that the data are killed ! That's the real reason why I would like to get a sledge hammer if faced to such a situation.....That hurts. Blue Screen or Segmentation Fault often result in bad, corrupted or even lost data. And frozen software is very good to prevent me from saving my work done in many hours. From this point of view, secure software is something which never damage my data in that sense, that they lost their value, their integrety or that they can not be processed further. Either the software can do what I want for all my data, or it never touch them at all.

Final conclusion: a secure software is one that always do what I want, and so many times I want, and which never let come up any doubt what I should want, and which do what I want for exact all my data completely or never touch them at all.

Isn't it a great result ? But it's not all. More to come later.

Live UML - explorative Modeling synchronizing

2008-03-02T05:49:00.000+01:00

One more point on modeling with Smalltalk: now, if there is a first implementation of the application starting from the Smalltalk live model as described in the last post, it must be developed further to cover all the necessary details. Theses details popping up from requirements which were unimportant for the basic model or they are caused by the translation from the Smalltalk environment to the destination language. As a result there is an runable implementation of the original live model in the destination language which nearly provide all what the requirements demand and which also matches all demands of the destination environment. So far, so good.

But there is one drawback: the implementation is certainly drifted away from the Smalltalk model, this and the implementation are never synchronized. That would not a problem for itself, but of course, the implementation is not perfect. It has bugs, or during the implementation new ideas or problems popping up (every environment has its own pitfalls :-) Or new requirements comming into view, of course ;-). And then there is a decision needed: resynchronize the Smalltalk model with the implementation, and decide about these new requirements, problems etc. there, or throw away the model and work only with the implementation ?

Well, it depends :-) But I have set up some simple rules for making this decision more easy:

Don't leave the model too early. There is certainly a time, where it makes no sense to keep the live model up-to-date. The most destination systems have big differences to Smalltalk, and if one have to bother about to many details in Smalltalk, it is time to leave it. But I observed in many cases this point in time can be delayed. The model is a good tool even if the first code in the destination environment exists.
Don't ignore too many details. Of course the nature of modelling is to ignore some details and to focus on the building blocks of a problem. But to make the model too easy forces the necessarity to keep the model synchronized much longer then really needed. Therefore, it makes also sense to anticipate and model some things which are strongly related to the destination plattform. To say: "oh, in Smalltalk I have not this problem" makes the model too easy sometimes. Also keep track on the interfaces in the destination platform, and model them by mock objects or something similar. To ignore input and output makes the model too easy.
Don't implement twice. If you have the application in Smalltalk and in the destination environment, you had leave the model too late :-) . Some details, which are not part of any model, which are only things of the destination languange, which are not essential to data structures or input output, must be solved directly in the destination environment.

For a successful result, one have to gain experience for the best level of detail and the best time point to leave the model. So, I will just using it, to get this experience

Live UML - Explorative Modeling in the small

2008-02-24T12:45:00.002+01:00

Looking at the applications programmed in the world, and looking at the programming languages used, the situation seems not positive for Smalltalk. But for me, Smalltalk is not dead. In the opposite: for me it has growing value, although my daily life is determined by C and C++. How can this be ?

If I have to build a new application or a new module, today I use Smalltalk to design the architecture. In general, if one has to do something new, classes must be identified, what they are doing, which data they work on and more. Extensibility (for new requirements) must be kept on focus, and that there will come an interface into life which could be understand and used by others. Here can help Smalltalk a lot: a few objects doing something is written in short time. Every rearrangement and new ideas can be implemented quickly. Because Smalltalk allows to modify code even in debugger, and allows to evaluate any code snipped at any place - the right design grows in a way also evolution works: simple try it. It is growing in the best sense.

At the end, I got a set of objects, a set of methods and communication network (who talks to who), which can carry the basic functionality. From this, it is easy to get UML - for communicating with managers - and the implementation in the destination language. Now, if - as in my case - the destination language is C++, there are some pitfalls of course. But because the runable Smalltalk model has partitioned the problem in static AND dynamic elements, the problems are small and solveable.

In fact, this is xM in the smallest possible scale....

In the future, I plan to create some ready-to-use moduls which are providing elements always used in our company. Radar data parser, or some kind of common displays or GUI elments are examples. Especially when combined with Seaside, this should result in a great Live UML (xM) Framework.

So Smalltalk is not dead, in the opposite, it is THE tool for robust and failure safe development !

Rendering documents - support the semantics

2008-02-14T07:08:00.002+01:00

The rendering of documents is only one part of the story. Another goal would be not only to build a tool for creating a document in the sense of set in in a certain form, but also to collect the right content for it. Now it is clear, that it is not possible today to build didactical efficient documents which are optimal for human reading and understanding. But if we not try single steps toward this direction, we will never come closer to the goal

So what can be done today ? Documents are answers to questions. Sounds trivial, but is the jumping point. So maintaining content means maintaining questions. So this could be a simple first step: manage not only content, but also manage the questions relateted to it and manage also the relations. The other thing are terms. Terms are the most basic but important building block of any content. In consequence, building term networks (and visualising them) would be another brick in the wall.

At this time, I am reading something about Husserls Phenomenology, a philosophy which looks (together with other things) how our understanding can come to see the nature of things. May be there are aspects which could be tried in the context of document rendering. And again, computer science will become practical philosophy

Of course, I also try to get an overview ofer things like semantic web.

Rendering documents

2008-01-30T08:17:00.001+01:00

Since many years I am interested in Requirement Engineering and documentation for the development process (especially UML). This needs of course to create documents. Often, to create documents they must be written by hand using some office software (like OpenOffice). That seems normal, but documents in a company environment must have a defined format, must contain defined things. On the graphical side - the UML part for example - the writer have to bother with good visible layout and design.
So I dreaming of a system which could render documents like Requirments, Testplans or even diagrams. Well, some bigger software on the CASE market can this, so it is possible to form Microsoft Office documents from data base entries. As far as I know, they are mostly based on templates. But I want my own flexible render engine, which works more with design rules and a meta model of documents than with templates. Or in other words, I want to stress the point of *rendering*.
Because all moderen office software uses XML for storing their documents, document rendering can be done in any language, and I have of course some special of them in mind (Erlang, Smalltalk.
At my new job, I have to create a lot of documents, so I hope I can build a little bit during my work.