Loving SysML

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

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

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

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

"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

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 !

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 :-)