I am at WICSA 2011 and the words “reference architecture” come up now and then in discussions. I am not sure I like the definition in Wikipedia, I think relies too much that you already have knowledge or experience of a reference architecture.
One simile (parable?) would be to a building code, a set or rules that underlie the actual architecture and construction of a house. The architect is free to build any type of house, as long as the code is adhered to.
But I like to use cooking as an example. A recipe is like an architecture, when you actually cooks the recipe and serve it is the implementation of software. You need to do certain things that are implementation specific, like tasting to see if the amount of salt suits your taste etc, and maybe you need to double all the ingredients to fit your dinner party.
Julia Child writes in her book Mastering the Art of French Cooking that there are 6 principal ways to make a sauce, one being an emulsion of melted butter with egg yolks, which is common the common method for béarnaise, hollandaise and choron sauces. The type of emulsion is similar to a pattern while the three different recipes are designs.
For a restaurant; a product line architecture would be the menu they have based on the ingredients they stock, for example chicken could be used in more than one dish.
So what is a reference architecture for a restaurant? It would be the “rules” that guides and controls what is possible or desirable. It could be for example driven by the business domain, e.g. it should focus on French or Hunan cuisine. Woking as a “development method” would not be relevant in the former, but certainly in the latter.
Or it could be driven what is technically possible, e.g if the kitchen has no deep fryer it is impossible to for example make french fries.
Or there could be other restrictions, such a desire to only use locally produced ingredients.
Maybe I went to far with this simile (parable)?
Tuesday, June 21, 2011
Wednesday, May 25, 2011
Architectural views in practice
My research is not really focused on identifying the “best” architectural views for in-vehicle software. But as a side effect to the studies I am presently doing I got to think about three views that could actually make a difference in how well large projects succeeds (or fails). I have thought about the need of addiitonal views, but cannot think of an immediate need of more.
Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.
The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.
The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.
Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.
The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.
The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.
Friday, April 8, 2011
What is a "good" architecture?
Hopefully you recognise it when you see it...
I believe every system has an architecture, documented or not, and intended or not. So I think it is reasonable to discuss if the architecture of a system is good or not, and that the question if the architecture description is good is a different, but related question.
So what criteria could you use to establish if an architecture is good? Is it suitable for it's purpose is a more precise question? But this probably differs depending on the stakeholder, a system could be very nice and intuitive for the user, but very difficult to develop and maintain for the developers. In the rest of this blog post I will writing about goodness from a developer perspective (including the architect, if one is involved).
I think there are different levels of how well the architecture suits it's purpose to guide and control the implementation.
The ideal level is where the developer understands the architecture and following the architecture is the obvious way to implement something. Doing it differently is seen as more difficult and less elegant.
The next level is where the developer understands the architecture, is able to follow it on her own and can evaluate if the implementation follows the architecture or not. The developer also understands the "debt" that would occur if she deviates from the architecture, for example in terms of compromising some quality attributes. At both this and the previous level the developer can contribute to the design of the architecture itself, and an appointed architect doing the design may not always be necessary.
The developer may need continuous support from the architect to be able to understand the architecture when working. This is very common and requires more work and puts limits on the the ratio between the number of architects and developers in large projects.
The worst level is where the developer cannot understand the architecture and the only one that can determine if the implementation follows the architecture is the architect by reviews. This is very work intensive on the part of the architect. The architect is also viewed as a police that interferes with the developers rather than supporting them.
I have worked at all this four levels in various projects, and I think that you need to be on the upper two if you talk about a good architecture from a developer perspective. I also think that if you want to be truly agile in a self-organising team it is at the two top levels you nee to be.
I believe every system has an architecture, documented or not, and intended or not. So I think it is reasonable to discuss if the architecture of a system is good or not, and that the question if the architecture description is good is a different, but related question.
So what criteria could you use to establish if an architecture is good? Is it suitable for it's purpose is a more precise question? But this probably differs depending on the stakeholder, a system could be very nice and intuitive for the user, but very difficult to develop and maintain for the developers. In the rest of this blog post I will writing about goodness from a developer perspective (including the architect, if one is involved).
I think there are different levels of how well the architecture suits it's purpose to guide and control the implementation.
The ideal level is where the developer understands the architecture and following the architecture is the obvious way to implement something. Doing it differently is seen as more difficult and less elegant.
The next level is where the developer understands the architecture, is able to follow it on her own and can evaluate if the implementation follows the architecture or not. The developer also understands the "debt" that would occur if she deviates from the architecture, for example in terms of compromising some quality attributes. At both this and the previous level the developer can contribute to the design of the architecture itself, and an appointed architect doing the design may not always be necessary.
The developer may need continuous support from the architect to be able to understand the architecture when working. This is very common and requires more work and puts limits on the the ratio between the number of architects and developers in large projects.
The worst level is where the developer cannot understand the architecture and the only one that can determine if the implementation follows the architecture is the architect by reviews. This is very work intensive on the part of the architect. The architect is also viewed as a police that interferes with the developers rather than supporting them.
I have worked at all this four levels in various projects, and I think that you need to be on the upper two if you talk about a good architecture from a developer perspective. I also think that if you want to be truly agile in a self-organising team it is at the two top levels you nee to be.
Monday, March 21, 2011
Embedding Linux for an Automotive Environment
I thought this presentation was interesting enough to share, even if i have absolutely nothing to do with it: Embedding Linux for an Automotive Environment. I guess you need to have a thorough understanding of Linux to understand how the optimisations were implemented.
You can watch a videorecording of the talk as well.
You can watch a videorecording of the talk as well.
Wednesday, February 23, 2011
Jävla skitsystem!
Pardon the Swedish!
The heading is actually the title of a Swedish book about how people can be stressed in a digital working environment. I think this is one of the most important books written about IT-systems and the problems they can bring on a personal level for the people who are forced to using them. Too bad is is not translated to English (yet?).
It is not a technical book, the primary audience are people using IT systems, secondly it is targeted at people planning and buying IT systems. It systematically lists 8 major stress factors and what can be done about them. Not all are caused by ignorant developers...
I think it is very valuable to read for people developing systems, so much I would make it mandatory reading for students in software engineering, if only it was published in English. There is some information in English, including a short slide presentation.
You can buy the book directly at the website or at major Swedish online bookstores.
The heading is actually the title of a Swedish book about how people can be stressed in a digital working environment. I think this is one of the most important books written about IT-systems and the problems they can bring on a personal level for the people who are forced to using them. Too bad is is not translated to English (yet?).
It is not a technical book, the primary audience are people using IT systems, secondly it is targeted at people planning and buying IT systems. It systematically lists 8 major stress factors and what can be done about them. Not all are caused by ignorant developers...
I think it is very valuable to read for people developing systems, so much I would make it mandatory reading for students in software engineering, if only it was published in English. There is some information in English, including a short slide presentation.
You can buy the book directly at the website or at major Swedish online bookstores.
Tuesday, February 22, 2011
You tend to favour the solutions you are familliar with...
When I talk to students about the role of the architect I always make a point of the architect must know when not to use a particular solution/pattern/style (the old "Kill your darlings"). Regardless of this I have seen examples when an entire class thinks that a 3-tier architecture is the best solution in a project because they took a course on databases the previous semester.
Likewise, when I talked about component-based architectures in a lecture and gave examples based on AUTOSAR, a lot of students thought that components was the thing, even if it complicated the solution for the developers and the benefits with components was not really relevant in the student project.
This is not surprising since I am talking about students with limited experience to various problems encountered when developing real systems. But I also think this is a problem for professional developers as well, including myself. We tend to stick to what we know and don't reflect if what we know actually makes things worse than better.
Likewise, when I talked about component-based architectures in a lecture and gave examples based on AUTOSAR, a lot of students thought that components was the thing, even if it complicated the solution for the developers and the benefits with components was not really relevant in the student project.
This is not surprising since I am talking about students with limited experience to various problems encountered when developing real systems. But I also think this is a problem for professional developers as well, including myself. We tend to stick to what we know and don't reflect if what we know actually makes things worse than better.
Monday, February 14, 2011
Infotainment systems news
I have been more involved in development of infotainment systems this year. BMW demonstrates what they call ConnectedDrive and Ford updates their Sync system to what they call myFord Touch
Compared to the amount of information at the links above there is very little about the comparable 2010 Volvo infotainment system at the official Volvo website. Note that the BMW is just a concept vehicle, while the Volvo system in in production, and still has less information about it on the web.
When the car gets connected, it also gets exposed: Telematics and security: Protecting the connected car
Therer are some interesting news about some major players as well: Nokia announce a strategic partnership with Microsoft on 11 February. I have no idea how this will affect Meego and GENIVI. Time will tell...
On the other hand there was a lot of activity around GENIVI at the Consumer Electronics Show in Las Vegas. And GENIVI is based on Meego...
Compared to the amount of information at the links above there is very little about the comparable 2010 Volvo infotainment system at the official Volvo website. Note that the BMW is just a concept vehicle, while the Volvo system in in production, and still has less information about it on the web.
When the car gets connected, it also gets exposed: Telematics and security: Protecting the connected car
Therer are some interesting news about some major players as well: Nokia announce a strategic partnership with Microsoft on 11 February. I have no idea how this will affect Meego and GENIVI. Time will tell...
On the other hand there was a lot of activity around GENIVI at the Consumer Electronics Show in Las Vegas. And GENIVI is based on Meego...
Tuesday, February 1, 2011
Research in software engineering
Researching software engineering is to study the artificial. Other engineering disciplines have "truths" that exist even if no humans are involved. The laws of physics that determine what is possible in mechanical and civil engineering are there regardless if applied when constructing a particular building.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.
A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:
A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.
A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:
- A good knowledge of real problems that practitioners have
- An interest in developing solutions to these problems
- Knowledge and experience in evaluating the solutions in practical (real) settings
A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.
Sunday, January 16, 2011
Development tools
I think you should select the tool that supports the way you are working, not the other way around. This is one of the reasons I think tool discussions usually focus on the wrong thing. They tend to get very long-winded and troublesome since the underlying process is not clear or decided.
However if you are a small team, I think the following tools are of use to you regardless of what process you are using (the version control software are useful for any project size). Many of my students seem to use them when they are doing project work.
However if you are a small team, I think the following tools are of use to you regardless of what process you are using (the version control software are useful for any project size). Many of my students seem to use them when they are doing project work.
- Version One Team edition - A free tool that supports managing agile software development.
- Trac - An enhanced wiki and issue tracking system for software development projects.
- GIT - A free & open source, distributed version control system. I think it is a major upgrade compared to SVN, even if the initial learning curve is steep.
If you run Windows I suggest you use TortoiseGIT as GIT client. - Mercurial - A modern, open source, distributed version control system (sounds very similar to GIT?). I think the learning curve is not as steep as for GIT, and a transition from SVN is probably easier. TortoieseHG is a good client for Windows users and what I use myself.
In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.
Tuesday, January 11, 2011
Confused by Simulink
The most common modelling tool in the automotive domain is Simulink. It started as a Matlab-based tool to graphically model and simulate differential equations needed in control design. Now it has expanded way beyond that to enable generation of production code for embedded controllers.
For someone like me, with a background in software and systems engineering and only the mandatory control engineering course, Simulink is confusing. Not the model elements as such, since it basically is an executable time-discrete data flow model. But the terminology used in the Simulink community is really confusing since they are using terms very common in software development, but with different meanings. I am not even sure the explanations below are valid...
Some examples:
For someone like me, with a background in software and systems engineering and only the mandatory control engineering course, Simulink is confusing. Not the model elements as such, since it basically is an executable time-discrete data flow model. But the terminology used in the Simulink community is really confusing since they are using terms very common in software development, but with different meanings. I am not even sure the explanations below are valid...
Some examples:
- A layer in Simulink is not what what one usually calls a layer in software. What is called a layer in Simulink I would personally call a view since it adresss a specific concern, see some defintion of the J-MAAB layers here. But I have also seen a layer as something found at a certain level in a functional hierarchy (boxes in boxes...). Maybe these two even are the same in the Simulink world?
A software layer would rather be called a subsystem in Simulink, but that is a generous interpretation from my side. (See Pattern-Oriented Software Architecture by Buschmann et al. for a definiton of software layer). - There are classes and objects in Simulink. Data objects are used to "specify values, data types, tunability, value ranges, and other key attributes of block outputs and parameters", where blocks are the basic entities that one build the simulink model from.
The Simulink software uses objects called data classes to define the properties of specific types of data objects." So in a sense the class is a template for the objects. On the other hand the data object does not specify a behaviour or input-output relationship. But classes seem also to be a special type of objects in thelast quote above. Ouch!
Contrast this to common OO design where the class is the template for the object, which is the main item encapsulating both a behaviour and associated data. A block in Simulink most closely resembles a function in a procedural language such as C or Pascal.
Tuesday, January 4, 2011
The importance of the team
I am reviewing and grading documentation in a student project. Or rather 12 student projects, all trying to develop similar software. The context is this: The students work in teams of 6. Each student has a separate role; project manager, architect, designer, quality/testing responsible, GUI designer and communications expert (it is an peer-to-peer application based on TCP). Alla students have to write code, and in addition to this they are supposed to turn in documentation related to their role.
What strikes me is that in the teams with good documentation all documents are good, regardless of author. How come? There could be several explanations:
What strikes me is that in the teams with good documentation all documents are good, regardless of author. How come? There could be several explanations:
- Good students want to work with each other (they could choose their teammates, they weren't assigned by us teachers).
- In good teams they cooperate on everything, inlcuding reviewing each others documents. In not-so-good teams they instead might try to split the tasks and work as independently as possible.
- In the good teams there is an exceptional student that functions as a mentor to the others.
- Excellent documementation from one role supports the others in their roles, e.g. an excellent architeture description supports testing etc.
- The good teams had not only a notion about what to deliver when they started, they also had a good notion on how to do it early on, e.g. they discussed so they had a common understanding of coding responsibility (everybody had to write code) and they choose an interative process or SCRUM already the first week.
- The good teams started with coding as quickly as possible. This is counterintuitive, but I think they felt more comfortable spending time on documentation if they already had some prototype running.
- It seems that analysis paralysis actually produces worse documentation. I think this is due to an inability to focus on the vital concerns and stop when they are sufficiently covered.
- It is hard to excel if your teammates drag you down. This could explain why there are no groups where just one role shines above the rest.
Subscribe to:
Posts (Atom)