erstellt am 27.06.2009
Since February I do an internship at EADS Germany in the department of Defence Electronics. There, I hear much about aircrafts the company builds. Therefore, I wanted to see the Euro Fighter, the A380 and also Ariane 5, the European space rocket. The Paris Air Show gave me the opportunity to do all this. I don’t want to explain much here; just see it yourself.
On the first picture there is Ariane 5 on the left side.

I like this picture; it is something different to see someone talking about such devices.

There are some really cool jets, especially that in the front.

Look at this; recognize how tiny persons are in relation to the A380.

Here it is; a piece of the moon, the ultimate evidence that the NASA was there.

And last but not least; I found a small version of Miss Liberty near the Eiffel Tower.

 |
2 Kommentare |
|
|
|
erstellt am 14.06.2009
The Visual C++ compiler of Visual Studio 2010 Beta 1 supports the upcoming C++0x standard and therefore introduces a great new language feature -> lambda expressions. In this article I will look at the usage of lambda expressions by converting Scheme code constructs to C++.
First of all, let us start with a traditional "Hello World" example to see how these expressions are built. In figure 1 I created a lambda expression that simply puts “Hello World” onto the console.

The brackets [] are introducing the lambda expression. These brackets are also called capture clause, because it specifies whether the body of the expression accesses variables in the enclosing scope by value or by reference. In the example I do not need any variables, therefore the capture clause is empty. The same is with the empty parameter list. The arrow pointing to void indicates the return type of the expression. This construct can be left right away, because there is no return type needed. I just put it there for completion.
Now, let us look at lambda expressions used in Scheme. In the example below, I firstly define a procedure called make-adder. It is responsible for creating procedures, which have the task to add a specific value x to a given value y. As you can see in the example the procedure adder4 adds the value of 4 to the given parameter.

Make-adder consists of nested lambda expressions, whereas the inner one is able to access the stored variable x from its outer environment. Later on, we will see in the C++ example what this environment is and where the value of the variable x is stored. But for now it is only necessary to understand what this code does.
An equivalent code example in the upcoming C++0x standard can be seen in figure 3. Besides the wired syntax, the definition of the make_adder function looks pretty similar. The same applies to the usage of make_adder.

It is also possible to convert the C++0x code to the current C++ standard. Therefore you need to know that lambda expressions can be represented by using function objects. This means we simply need to create objects which overload the function call operator () in order to get the same functionality as the lambda expressions showed above. Such objects are also called functors.
The definition of make_adder is now a bit different. With the current C++ standard it is much more to write in order to get the same functionality. As you will probably recognize when watching the code in figure 4 is that make_adder is not really a function. It is a class object which makes use of the operator (). This technique is useful because an object of the class CAdder can now be called like a function but it also has a state.

This is exactly where the environment comes into play. Recognize the temporary variable _x which is stored in the CAdder class object. As noted above a lambda expression maintains state by using an environment. Here _x represents the environment for the CAdder class object.
For a complete understanding of the above code I suggest testing these examples on your own. You will find additional information of lambda expressions in the MSDN Library. If you have any questions just email me.
 |
2 Kommentare |
|
|
|
erstellt am 17.05.2009
There are two ways in C# for safely freeing resources, these are try-finally and the using-statement. Both call the Dispose Method introduced by the IDisposable Interface, ensuring that there is no resource leakage in case of an exception. In Managed C++ there exists no using statement. Fortunately, Managed C++ is rich enough to extend itself by using templates. In this article I will explain something about resource management and how to introduce the using statement into C++/CLI.
The Common Language Runtime (CLR) is the fundamental part of the .NET Framework and executes the Intermediate Language (IL) code to which all .NET languages are compiled to. Being the base for these languages, it determines also the borders for concepts and features a language is able to provide. Thereby the CLR provides only common functionalities and does not provide resource management out of the box. This would result in a further constraint of all other languages built upon it.
Fortunately, the .NET Framework has introduced a pattern for resource management. This pattern provides the IDisposable interface. It defines that types which encapsulate resources should provide a Dispose method to free resources if they are no longer needed.
Unlike C++, C# is a language which does not have the concept of destructors. Therefore it uses try-finally and the using statement to free resources in a reliable and safe manner. This means the resources will be freed despite of a thrown exception.

The using statement creates an object within an own scope. If the execution gets out of scope, the object’s Dispose-Method will be invoked and this results in freeing the resources.
Microsoft extended Managed C++ with the try-finally statement, but there exists no using statement. Now, you probably ask yourself, why do we need try-finally when there are destructors?
That is because Managed C++ is built upon the CLR and the CLR does not provide the concept of destructors, therefore something magically happens. The language pretends the use of destructors by using the same syntax. When the code gets compiled to IL the compiler emits automatically the necessary IL code to implement the Dispose method which serves as a destructor.
As you can see in the picture the object implements the IDisposable::Dispose method. This is the reason why it is not legal in C++/CLI to explicitly implement the Dispose method.

At next I will show you a snippet which introduces the using statement in C++/CLI. The following template does only one thing; it calls the destructor of some object when the template itself gets destructed.

Before I will explain how it works I will give an example of how to use it.

What happens here and how does it work?
If you execute the example code an object of the template will be created on the stack. This means, when the execution gets out of the scope the template object’s destructor gets called. Because of the handle to the DisposableObject created on the heap, the template object is able to call its Dispose-Method in order to free resources. Because the template object is created on the stack its destructor will be also called in case of an exception. The brackets around the statement are used to define a scope in C++.
If you compare the two statements between Managed C++ and C# you will recognize the similarity. You can download the code snippet here for further explorations.
 |
3 Kommentare |
|
|
|
erstellt am 10.04.2009
A couple weeks ago I held a workshop at my university in Heilbronn. Some people ask me why the C# programming language uses an extra keyword for events. During some discussions I tried to figure out why they had such a problem in that. What I recognized, was that they saw an event as a kind of a restricted delegate. In this article I will clarify the responsibilities of delegates and events. Additionally, I will emphasize the sense of such ‘restricted delegates’ by using the view of a software-engineer.
The C# language specification specifies a delegate similar as function pointers in some other languages. A great advantage of delegates is that they are type-safe and object-oriented. Figure 1 emphasizes the common principle of a delegate.

As you can see on the picture, there is a delegate declared within the scope of a namespace. This declaration is used by the notifier object to determine the signature of the handler method. The notify delegate holds a handle to the method to invoke and the notify method is used to invoke this method.
Unlike a delegate, an event has to be declared as a member of an object enabling it to provide notifications to other objects. In this context a method invoked by an event is called event handler. The following picture shows the concept of events.

If you compare the first two pictures you will probably recognize the missing delegate declaration in figure 2. That is why the framework already has a standard delegate declaration for events. The following line shows the delegate type of an event.
public delegate void EventHandler(object sender, EventArgs e);
For a better illustration, I use a delegate without parameters in the code samples of this article.
public delegate void MyDelegateDeclaration();
Apart from that, the handler and notifier objects have just renamed members. This model is now a bit more simplified for its purpose of notifying other objects and uses the event system of the language. Therefore events are a kind of delegates, but what makes the difference?
Events encapsulate delegates and restrict them in some ways. They can only be declared within objects and the operations that are permitted on an event by code that is outside the type in which that event is declared, are += and -=. Therefore, while such code can add and remove handlers for an event, it cannot directly obtain or modify the underlying list of event handlers.
In short, the difference is the behavior. Events are declared for notifying other objects; neither more, nor less. This scenario of the publish-subscribe-pattern is supported by the language itself making it trivial to get callbacks from other objects. A subscriber can register for an event and the publisher sends notifications back when events are fired.
To emphasize these differences I will show you the mapping of the above models in code.

In figure 3 you will see the delegate declaration “MyDelegateDeclaration”. Instead of using an own delegate declaration I use in figure 4 the built in type “EventHandler” as said above.

If you compare these two code snippets you should recognize, that by using events directly you can concentrate on your publish subscribe scenario and do not need the overhead of encapsulating delegates, implementing add and remove functionalities yourself. Furthermore if everyone has to implement this pattern you would probably have no standard object notification mechanisms.
 |
Keine Kommentare |
|
|
|
erstellt am 27.03.2009
Case studies showed a quite passive usage of digital information in today’s world. Furthermore, the technological infrastructure we established is used in an inefficient way. In this article I worked out a software concept helping us to set up our personal environment of electronic devices in order to use digital information in an active manner.
In today’s world, most people, whether they are in the IT, business or some other profession, carry digital information with them. This could be in form of a memory stick, compact disc or other kind of data storage. Some of them have their business data, like presentations, analysis or documents on it and others carry more personally data, like music, pictures or video clips with them.
Currently, the market shows that people tend to personalize their multimedia environment by providing their music playlists or sharing photo albums between several devices at home and on the internet. Watching this leads to the fact that digital information is an integral part of our today’s life and everybody of us spends much of electric energy, day by day, for multimedia devices.
Therefore, we have to think about improving the consumption of electric energy in order to ensure environmental sustainability. This challenge can be mastered by using the technological infrastructure we established in a more efficient way.
In the last years we could convincingly reduce manual work by automating them through the use of technology. But we still use information in a quite passive way, which means we do not let the information know itself what it is and what we want it to do. Instead of improving the automation of repeating tasks we organize everything ourselves and thus wasting much of electric energy. Therefore we need something, which manages things for us and helps to use our electronic devices surrounding us in our daily life in a more automated manner.

My vision is to use data in an active manner, which leads to the creation of our own personal multimedia environment. This is done by using Meta information and an intelligent system that processes it. Such an embedded device knows what information when to use in order to activate nearby devices forcing them to perform its predefined functions. Through this we can reach the aim to better connect our personal devices with each other and step forward to a more comfortable, automated world. Thereby, we simultaneously use the technical environment in an efficient way, thus reducing energy.
Imagine what help such a device could be. It could be used to automatically set up your system, prepare your presentation or make your documents ready to work and plays your favorite songs to make you feel more comfortable. It also offers other thousands of possibilities by following the fundamental concept ‘Hardware as a Service Invoker’ and by being a framework, which facilitates the use of information in an active way.
Hardware as a Service Invoker (HaaSI)
For years business is changing through concepts like Software as a Service to Software plus Services, on the internet people even talking about everything as a service and this rise of service oriented thinking has a big influence on the architecture of software. Software in a cloud computing world uses encapsulated services with predefined interfaces. This will result in having services everywhere, not only in the cloud or on premise, but also at home or in the car. Software is everywhere; Services will be everywhere.
To make a better usage of these services I thought about the concept ‘Hardware as a Service Invoker’ (HaaSI). Using HaaSI means, to have a core of software which handles communication with remote services. This piece of software could be running on an embedded device like a mobile phone or a specified device which fulfills the requirements to reach remote services. This resulting electronic system is then able to trigger services.

As you can see in the above figure, the concept consists of two parties. The Service Invoker is responsible for starting the communication process in order to invoke a predefined functionality on the side of the Service Provider. The Service Provider is responsible to make services visible to the outside world and to process services.
To define clear roles and to create a more tangible concept, I declared the left symbol to be a Service Invoker, but the Service Invoker can also be a Service Provider - it only depends on the requirements the device fulfills. For this reason I name the left symbol in the further context as Service Device. I declared the symbol on the right side as Service Provider, which means it could be any electronic device (TV, Radio, DVD-Player etc.), which offers services for us and therefore fulfills the interface we need to invoke services.
Did I make you curious? Then download the paper describing this concept in more detail right here. I would appreciate your feedback; just e-mail me at denis.dwornitzak@studentpartners.de.
 |
Keine Kommentare |
|
|
|
erstellt am 23.02.2009
In Software-Engineering everyone is typically confronted with diagrams and architectural descriptions containing circles, rectangles arrows and some plain text. Such descriptions are another representation of the organization of code in order to make software more tangible. They are used to clearly identify system borders and to introduce identifiers describing the problem domain. It sounds like a great way to make software internals more understandable, but how often did you sit in front of some code finally recognizing that mappings between diagrams and code are not matching. I think distinction and precision are fundamental for creating exact and meaningful software descriptions.
Imagine you are working on a project where you have to establish a connection between two servers in order to exchange newspaper articles. Figure 1 shows two different views on this system, a metaphorical and a technical. The metaphorical has identifiers, which can be used for the implementation to make the code more understandable, whereas the technical view helps you to establish the underlying infrastructure for the communication process.

Having this distinction in mind, you will create an interface, which represents the contract for the newspaper exchange. For a good understanding of the code, the contract has to reflect the metaphorical view, whereas the implementation shall represent the technical view. The following code snippet emphasizes the difference between contract and implementation.

Important to recognize is, that the user of this interface just needs to know the metaphorical view, where Paperbox A can send newspaper articles to Paperbox B. The underlying technical implementation which might describe the establishment of a TCP/IP communication process is just of interest by the implementer of the system.
Now, you should have noticed what I mean by to distinguish in order to be precise. The system described above is clearly delimited in figure 1. Furthermore, the implementation reflects the identifiers of the architectural description and therefore provides a clear understanding for a developer which tries to work with that piece of code.
There are much more things where you have to precisely differentiate things. In this article I just want to give you a hint. Keeping this in mind I bet you will still get more understandable systems.
 |
Keine Kommentare |
|
|
|