To continue my thoughts about the programming language Erlang and especially how an architecture for a system implemented in Erlang would look like...
Joe Armstrong's PhD Thesis provides a very good understanding of the basic principles of Erlang. I think that some of the mechanism in the language makes several pattens in Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects unnecessary.
I think it would be quite useful to describe the architecture in views. I think the "standard" 4+1 views could be used quite easy for a system implemented in Erlang as well.
However it may not be the logical view that the other views are derived from, rather I would think that the process view would be the basic view. Kruchten has an underlying assumption that the logical view is object-oriented. This is obviously not relevant for a system implemented in Erlang so a different notion of the logical view is necessary.
Joe Armstrong strongly suggest a hierarchy of processes. A problem domain model could be a good way to identify the top-level processes, e.g. the PDM classes could be the initial processes and the asynchronous interaction will be implemented as messages, since reality is asynchronous. I need to try this in practice though...
Tuesday, June 15, 2010
Friday, June 11, 2010
Architecture reconstruction pt. 3
These are some random notes the students took while doing the intial reconstruction (I translated some notes in Swedish to English).
I don't know if they will finish, since the semester has ended.
Why does the camera know about the state of the Robot?
The camera, having a relative angle could not properly determine the angle of an identified object when the vehicle is, for example turning.
The event handler gets information from the wheels and sends to the camera. Now there is both idle and turn. But the camera runs the same function regardless of the message it gets, why does then turn exist?
Conclusions:
Different ways to send states thorughut the system, some are event driven and some are conditional.
Naming standard and file structure are not the same throughout the system.
The protocol files were located in different places.
The fact that the different modules use different architectures is OK since the circumstances for them are very different.
The name OS of one of the applications on the Arduino Mega is not very suitable since it is situated at the top of the hierarchy.
"Trust is good, control is better" - a quote from a former architect colleague of mine which the students liked enough to write down
I don't know if they will finish, since the semester has ended.
Why does the camera know about the state of the Robot?
The camera, having a relative angle could not properly determine the angle of an identified object when the vehicle is, for example turning.
The event handler gets information from the wheels and sends to the camera. Now there is both idle and turn. But the camera runs the same function regardless of the message it gets, why does then turn exist?
Conclusions:
Different ways to send states thorughut the system, some are event driven and some are conditional.
Naming standard and file structure are not the same throughout the system.
The protocol files were located in different places.
The fact that the different modules use different architectures is OK since the circumstances for them are very different.
The name OS of one of the applications on the Arduino Mega is not very suitable since it is situated at the top of the hierarchy.
"Trust is good, control is better" - a quote from a former architect colleague of mine which the students liked enough to write down
Tuesday, June 8, 2010
Erlang
I don't do enough programming!
It has been years since I actually was allowed (asked?) to write any production code that goes into any of Volvo vehicle, since we buy a majority of our in-vehicle software from suppliers. Besides that, most of the in-house code we do nowadays are auto-generated from Simulink and Stateflow models.
Mostly I have reviewed what others have put in our vehicles, which is not nearly as rewarding. And this usually only happens when there is a problem, usually not a bug fix but rather more complicated, like real-time scheduling or improper use or configuration of the basic (or platform) software.
Since I will take a more active part in the a project course at the IT University which uses Erlang I think I will look into that. Erlang has some features which appeals to me personally:
Confession: I'm not really that skilled OO programmer either, I could probably not write a Java program if my life depended on it. I'm too old school, almost all professional programming I've done have been in C and Fortran, with some Assembler and IDL.
It has been years since I actually was allowed (asked?) to write any production code that goes into any of Volvo vehicle, since we buy a majority of our in-vehicle software from suppliers. Besides that, most of the in-house code we do nowadays are auto-generated from Simulink and Stateflow models.
Mostly I have reviewed what others have put in our vehicles, which is not nearly as rewarding. And this usually only happens when there is a problem, usually not a bug fix but rather more complicated, like real-time scheduling or improper use or configuration of the basic (or platform) software.
Since I will take a more active part in the a project course at the IT University which uses Erlang I think I will look into that. Erlang has some features which appeals to me personally:
- Support for asynchronous parallel processing, ideal for multi-core processors
- Functional paradigm, in contrast to the dominating OO paradigm, so I need to brush up old knowledge of things I haven't used since graduating in 1993.
- Freeware from the erlang website
- Access to some experts on the language
Confession: I'm not really that skilled OO programmer either, I could probably not write a Java program if my life depended on it. I'm too old school, almost all professional programming I've done have been in C and Fortran, with some Assembler and IDL.
Friday, June 4, 2010
Architecture reconstruction pt. 2
The students wanted to have some tool support in identifying the relationships between various functions (i..e. who called who). This was simpler in theory than in practice.
A not-so-quick search on the internet listed some potential candidates:
Code Visualizer
Crystal FLOW for C
Code Visual to Flowchart
http://www.EtherPad.com
http://www.metamill.com/
http://rigi.uvic.ca/
http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html
However none of these were very easy to use, or could not handle C as a programming language.
They also tried Rhapsody since they had a student license form another course and Enterprise Architect since it was possible to download a time-limited demo and these programs had no problems importing the code and identifying modules and functions, but they did not identity the calling relationships.
The students did not want to spend to many hours fiddling with tools so in the end they settled for manually inspecting the C code and identify what files included what other files. Since it was a distributed embedded system with 4 microprocessors and about 30 kLOC it was a doable task. Let's say that the 7 development teams had
quite different "strategies" for decomposing their code.
My personal observation is that even such a "simple" thing as decomposing you C program into files actually needs structuring principles if several development teams (or developers) work in a project, otherwise maintenance will be very difficult.
I still haven't decided if I should publish the more "awkward" ways to do it as examples to learn form, I don't want to point fingers at any particular students.
A not-so-quick search on the internet listed some potential candidates:
Code Visualizer
Crystal FLOW for C
Code Visual to Flowchart
http://www.EtherPad.com
http://www.metamill.com/
http://rigi.uvic.ca/
http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html
However none of these were very easy to use, or could not handle C as a programming language.
They also tried Rhapsody since they had a student license form another course and Enterprise Architect since it was possible to download a time-limited demo and these programs had no problems importing the code and identifying modules and functions, but they did not identity the calling relationships.
The students did not want to spend to many hours fiddling with tools so in the end they settled for manually inspecting the C code and identify what files included what other files. Since it was a distributed embedded system with 4 microprocessors and about 30 kLOC it was a doable task. Let's say that the 7 development teams had
quite different "strategies" for decomposing their code.
My personal observation is that even such a "simple" thing as decomposing you C program into files actually needs structuring principles if several development teams (or developers) work in a project, otherwise maintenance will be very difficult.
I still haven't decided if I should publish the more "awkward" ways to do it as examples to learn form, I don't want to point fingers at any particular students.
Friday, May 28, 2010
Architecture reconstruction
Each spring a project course called Industrial IT and Embedded Systems is given at the IT University. A description of the project from 2009 can be read here.
The students used trac to support their project and you can access the public project pages here.
This year I coached the students responsible for defining the overall architecture at the beginning of the project.
The project is finished with an official demo of the robot's capabilities, but some students approached me with an interest of doing a "post mortem" of the software as an additional learning experience. I thought this would be quite interesting, enough so to share any experiences on this blog.
These were the primary goals the students defined for the exercise:
Second priority goals:
The students doing the reconstruction use the excellent tool Pirate Pad to capture notes and common ideas. Pirate Pad is a simple pre-runner of Google Wave where you don't have to register to create a pad, everybody just access the same web address and start collaborating.
The students used trac to support their project and you can access the public project pages here.
This year I coached the students responsible for defining the overall architecture at the beginning of the project.
The project is finished with an official demo of the robot's capabilities, but some students approached me with an interest of doing a "post mortem" of the software as an additional learning experience. I thought this would be quite interesting, enough so to share any experiences on this blog.
These were the primary goals the students defined for the exercise:
- Learning more about architecture
- Only analysis, not update current project (code)
- Reconstruct existing robot architecture
- Automatic reconstruction using a tool
- Create "logical view" from source code, showing dependencies on function level
- Variable scope, global variables
- Process view
- Evaluation, compare against first architecture
Second priority goals:
- What could have been done in other ways and what impact would those changes have made
- Improvement Ideas
The students doing the reconstruction use the excellent tool Pirate Pad to capture notes and common ideas. Pirate Pad is a simple pre-runner of Google Wave where you don't have to register to create a pad, everybody just access the same web address and start collaborating.
Wednesday, May 26, 2010
Yet another article
The blog is updated on a very irregular basis. the main reason is that I presently have 3 articles in the pipeline and this takes priority over anything else. The latest article which I need to update is to ECSA 2010:
Dear AUTHORS,
Unfortunately your paper has not been accepted 'as it is' for inclusion in the program of the 4th European Conference on Software Architecture 2010 (ECSA 2010), which will be held on August 23-26 in Copenhagen, Denmark.
However, the program committee felt that the work reported in your paper has a number of interesting ideas, hence, I would like to invite you to prepare a shortened version of your paper for inclusion as "Emerging research" category Paper in the ECSA 2010 proceedings. As noted on the conference website, the "Emerging research" papers (8 pages of Springer formating) present promising achievements from work-in-progress and are intended to stimulate discussion related to ideas and experiences. For further details about the "Emerging research" papers, plesae visit ECSA 2010 website (http://www.ecsa2010.org). To accommodate publication schedules, final papers must be submitted by June 11, 2010.
... snip ...
4. The camera ready copy of your paper is due by June 11, 2010 (This is a hard deadline!).
... snip ...
Once again, congratulations on having your paper accepted as an "Emerging research" paper. We look forward to receiving your final camera ready paper, and to seeing you in Copenhagen, Denmark.
If you have any question or comment, please email me.
Regards,
Ali
ECSA 2010 Program Chair.
Tuesday, May 4, 2010
Time to plan a trip to Korea...
The paper Architecting Automotive Product Lines: Industrial Practice by Håkan Gustavsson from Scania and myself have been accepted to the 14th Software Product Line Conference.
"Dear authors,
Thank you for your submission to SPLC 2010.
We are pleased to inform you that your paper has been accepted for inclusion in the SPLC full paper program.
Due to strong competition, we could only accept 28 full papers out of 90 submissions, giving an acceptance rate of 31%.
Congratulations on being included in this select group.
... snip ...
Once again, congratulations on having your paper accepted.
We look forward to receiving your final revised paper, and to seeing you in September in Juju Island, South Korea.
Sincerely,
Jan Bosch and Jaejoon Lee
PC Co-chairs
SPLC 2010"
Subscribe to:
Posts (Atom)