This post is the next episode in the series of "Software Architecture Basics".
I found the following presentation made by some of the students of the Software Engineering & Management at the IT University. I'm impressed that they managed to boil down almost a full course to a single presentation with a rather light touch (yes, there are some technical details that could be discussed, but nevertheless).
I wish I could take credit for being their teacher, but I only gave a single lecture in their architecture course.
Software Architecture Presentation
Thursday, May 28, 2009
Wednesday, May 6, 2009
The architecture of Lego
Some years ago I was asked to explain the concept of a product line architecture for some students that had not heard of the concept before. They were not very familiar with terminology used in the field of software architecture either so I had to do it on a basic level.
I decided to use an example outside of the software domain, namely the Danish toy system of Lego, since everybody in Sweden played with Lego as a kid. I guess the example looses it's pedagogical value if the audience has not seen Lego.
I did some revere engineering to identify architectural strategies and quality attributes. Pictures in the presentation are stolen from unknown internet sites...
I decided to use an example outside of the software domain, namely the Danish toy system of Lego, since everybody in Sweden played with Lego as a kid. I guess the example looses it's pedagogical value if the audience has not seen Lego.
I did some revere engineering to identify architectural strategies and quality attributes. Pictures in the presentation are stolen from unknown internet sites...
Wednesday, April 22, 2009
More news and press releases
Here are some interesting news and press releases:
- Download, install and drive – the future of automotive software from ICT Results
- Mentor Graphics Strengthens Its Automotive Solutions with New Integrated AUTOSAR Design Environment
- AUTOSAR marks its series production debut - in the new BMW 7 Series
- Hansen lists top ten automotive electronic trends from John Day's Auto Electronics Blog
"Warum soll man es einfach machen, wenn man es so schön komplizieren kann?"which roughly translates to
"Why should we make it simple when it can be made so beautifully complicated?"I don't know where it originally comes from though...
Wednesday, April 15, 2009
Survey of active vehicle dynamics systems
Prodrive is a company known for supplying advanced technology to a number of "special" vehicles such as the Ford Focus RS and the Subaru Impreza P1.
But the reason I mention them on this blog is that they have written a nice SAE paper surveying different electronic vehicle dynamics systems available when designing a vehicle, and therefore the electrical architecture in a premium vehicle may need to address.
It is possible to download a free copy of the paper at the Prodrive website.
But the reason I mention them on this blog is that they have written a nice SAE paper surveying different electronic vehicle dynamics systems available when designing a vehicle, and therefore the electrical architecture in a premium vehicle may need to address.
It is possible to download a free copy of the paper at the Prodrive website.
References in paper about the Architecture Business Cycle
I submitted a paper called "A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture". I cannot publish the paper in this blog (at least not until it has been accepted), but I can give the reference list. Many of the papers can be found on-line through Google Scholar if access is not available through the commercial portals.
AUTOSAR, 2009. AUTomotive Open System ARchitecture (AUTOSAR). Available at: http://www.autosar.org.
Bachmann, F. & Bass, L., 2001. Managing variability in software architectures. SIGSOFT Software Engineering Notes, 26(3), 126-132.
Bass, L., Clements, P. & Kazman, R., 2003. Software Architecture in Practice 2nd ed., Addison-Wesley.
Berg, B.L., 2006. Qualitative Research Methods for the Social Sciences 6th ed., Allyn & Bacon.
Broy, M., 2006. Challenges in automotive software engineering. In Proceedings of the 28th international conference on Software engineering. Shanghai, China: ACM, pp. 33-42. Available at: http://portal.acm.org/citation.cfm?id=1134285.1134292 [Accessed December 18, 2008].
Conway, M.E., 1968. How Do Committees Invent? Datamation. Available at: http://www.melconway.com/research/committees.html.
IEEE, 2000. Recommended Practice for Architectural Description of Software-Intensive Systems. Available at: http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html.
ISO - International Organization for Standardization, 2003. ISO standard 11898: Controller Area Network (CAN). Available at: http://www.iso.org/ [Accessed December 28, 2008].
Kazman, R. & Bass, L., 2005. Categorizing Business Goals for Software Architectures, Carnegie Mellon Software Engineering Institute. Available at: http://www.sei.cmu.edu/pub/documents/05.reports/pdf/05tr021.pdf.
Kazman, R. et al., 2005. The Architecture Business Cycle Revisited: A Business Goals Taxonomy to Support Architecture Design and Analysis. news@SEI. Available at: http://www.sei.cmu.edu/news-at-sei/columns/the_architect/2005/2/architect-2005-2.htm [Accessed December 18, 2008].
LIN Consortium, 2008. Local Interconnect Network (LIN). Available at: http://www.lin-subbus.org/ [Accessed December 28, 2008].
McDermid, J.A., 2000. Complexity: Concept, Causes and Control. In Proceedings. Sixth IEEE International Conference on Engineering of Complex Computer Systems, ICECCS. p. 2–9. Available at: ftp://ftp.cs.york.ac.uk/pub/hise/Complexity-Concept,Causes & Control.pdf.
Melin, K., 1998. Volvo S80: Electrical system of the future. Volvo Technology Report, 1, 3-7.
MOST Cooperation, 2008. Media Oriented Systems Transport (MOST). Available at: http://www.mostcooperation.com/ [Accessed December 28, 2008].
Noergaard, T., 2005. Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers, Newnes.
Pretschner, A. et al., 2007. Software Engineering for Automotive Systems: A Roadmap. In 2007 Future of Software Engineering. IEEE Computer Society, pp. 55-71. Available at: http://portal.acm.org/citation.cfm?id=1253532.1254710 [Accessed December 28, 2008].
Reichart, G. & Haneberg, M., 2004. Key Drivers for a Future System Architecture in Vehicles. In Proc. Convergence 2004. Detroit, MI, USA: SAE. Available at: http://www.sae.org/technical/papers/2004-21-0025 [Accessed March 9, 2009].
Smallbone Tizard, D., Wallmark, J. & Warrby, T., 2007. Architecture and Change: A Case Study Using the Architecture Business Cycle for Assessing an Organisation Facing a Major Architectural Change, Göteborg, Sweden: IT University of Göteborg.
Walsham, G., 1995. Interpretive case studies in IS research: nature and method. European Journal of Information Systems , 4, 74-81.
Yin, R.K., 2003. Case Study Research: Design and Methods 3rd ed., Sage Publications.
Unconscious Competence
I have in the last year or so found it difficult to immediately explain why I perceive a certain system design is flawed (at least from an architectural viewpoint), while my gut feeling strongly tells me it is. It seems I'm most sensible to conceptual integrity, or rather lack thereof.
Usually I can do a some logical reasoning to support my initial conclusion, but it seems backwards that I reach the conclusion first and find the arguments to support it afterwards.
I stumbled upon the concept of code smell, and from there upon unconscious competence, which pretty much sums my experience. I had never heard of unconscious competence before, but I'm relieved that others have recognised it as a "level of competence".
Now it could just be that I am totally delusional about architecture, and is actually unconsciously incompetent instead. It seems nobody outside programmers recognise that you could be unconsciously competent in such a highly cognitive area...
Note: I wasn't finding the definitions in wikipedia, but here, but I thought the wikipedia definitions were more understandable. A google search found these pages on the subject as well (I filtered all pages by personnel development companies and about athletic coaching):
Usually I can do a some logical reasoning to support my initial conclusion, but it seems backwards that I reach the conclusion first and find the arguments to support it afterwards.
I stumbled upon the concept of code smell, and from there upon unconscious competence, which pretty much sums my experience. I had never heard of unconscious competence before, but I'm relieved that others have recognised it as a "level of competence".
Now it could just be that I am totally delusional about architecture, and is actually unconsciously incompetent instead. It seems nobody outside programmers recognise that you could be unconsciously competent in such a highly cognitive area...
Note: I wasn't finding the definitions in wikipedia, but here, but I thought the wikipedia definitions were more understandable. A google search found these pages on the subject as well (I filtered all pages by personnel development companies and about athletic coaching):
Tuesday, April 7, 2009
The Non-Coding Architect
I read a blog post about "anti-teams", not that I found the blog highly related to my work or research, but this particular post gave some food for thought. In particular I started to wonder if I fall into the category of the "Non-coding Architect".
It is true that I don't write any code for the projects I'm involved in presently at Volvo. This mainly due to two reasons:
First; the provisional architecture is usually settled very early in the project, often before the majority of developers have started working (why this is so is almost the subject of an entire thesis and will not be covered in this blog post. For now just accept that it is not a decision of the architect).
Second; most of the code is written not by the OEM (the manufacturer for you who are not familiar automotive terminology) but by suppliers. This is also a decision made way above the head of me as architect. It is part of a general business strategy on high management level, which I don't really feel I'm involved in.
To my defence I am one of the few developers at the EESE department at Volvo Cars that actually has hand-written code in C (and just a few lines of assembler) that is included in cars delivered to customers (and not just pushed the auto-coding button in Simulink). But as I said in the beginning, it is very seldom I do any actual coding in the platforms I'm architecting. It is very seldom I do any coding at all these days. I need to ponder this more...
It is true that I don't write any code for the projects I'm involved in presently at Volvo. This mainly due to two reasons:
First; the provisional architecture is usually settled very early in the project, often before the majority of developers have started working (why this is so is almost the subject of an entire thesis and will not be covered in this blog post. For now just accept that it is not a decision of the architect).
Second; most of the code is written not by the OEM (the manufacturer for you who are not familiar automotive terminology) but by suppliers. This is also a decision made way above the head of me as architect. It is part of a general business strategy on high management level, which I don't really feel I'm involved in.
To my defence I am one of the few developers at the EESE department at Volvo Cars that actually has hand-written code in C (and just a few lines of assembler) that is included in cars delivered to customers (and not just pushed the auto-coding button in Simulink). But as I said in the beginning, it is very seldom I do any actual coding in the platforms I'm architecting. It is very seldom I do any coding at all these days. I need to ponder this more...
Subscribe to:
Posts (Atom)