- An Introduction to Software Architecture and the Risk-Centric Model by George Fairbanks. George is a an excellent lecturer and has written one of the best books available on software architecture. If you have the oportunity to discuss with him, take it. Too bad the sound is so bad in this video clip.
- Conscious Software Development: Architecture with Jeff Mckenna. Why not look through all parts in the series while you are at it?
- Software Architecture Document by Philippe Back. I don't know who this guy is, but he manages to convey a lot of essentials in 12 minutes
- SEI has a number of webinars related to software architecture. Unfortunately I can't get them to play on my computer, maybe you can?
- Out and About: Software Architecture with Simon Brown. A short clip with a view on what a developer needs to do to be an architect.
- Considering a Software Architect Career by Marc Ferrentino. A very short clip on what skills you need if becoming an architect.
Showing posts with label My teaching. Show all posts
Showing posts with label My teaching. Show all posts
Monday, November 21, 2011
More on-line lectures on software architecture
I was discussing with one of my colleagues at the department if there were any introductory or summary presentations on-line about software architecture. I have already listed some on-line lectures about software archtiecture in the blog, but a quick search revelad some interesting ones:
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.
Friday, October 29, 2010
Architecture for small systems?
It is Friday afternoon and I'm allowed to have some wild ideas...
After a long e-mail conversation with one student of appropriate architectural styles to use in a project course I realised that his ending comment is spot on:
A lot of software systems are small, from a bittorrent client (the student project) to the software in the door control unit in a car, to a mobile app. And yet they would all benefit of having some though about what they must meet for non-functional needs that is addressed by a (simple) architecture. Should I write a book on architecting small systems? So that a team member is better prepared when he or she participates in a small project where the architecture "emerges"? You don't need to be an architect to benefit from doing thinking at an architectural "level".
After a long e-mail conversation with one student of appropriate architectural styles to use in a project course I realised that his ending comment is spot on:
I think the course and it's literature are focused on large systems and seeing that we are new to this, especially with a new language in parallel, its difficult to not apply what we learn during the course.I have been too blind when I teach, and not even my professional experience helped me to identify the problem:
In my opinion the patterns covered in the book left me half way with the idea that most architectures could fit into a pattern, within its own right.
Most (all) literature about architecture teaches solutions for big systems.Is there a niche for information on how to architect small systems? Small in the sense of not having millions lines of code, or a large development team, or a long project. I know that the agile manifesto states that that one of twelve important principles are
The best architectures, requirements, and designs emerge from self-organizing teams.But do a google search on "agile architecture emerge" and see what comes up, a lot of interesting reading that suggest that the issue is not that simple.
A lot of software systems are small, from a bittorrent client (the student project) to the software in the door control unit in a car, to a mobile app. And yet they would all benefit of having some though about what they must meet for non-functional needs that is addressed by a (simple) architecture. Should I write a book on architecting small systems? So that a team member is better prepared when he or she participates in a small project where the architecture "emerges"? You don't need to be an architect to benefit from doing thinking at an architectural "level".
Thursday, October 7, 2010
On plagiarism and referencing
In the architecture course I'm involved in several groups failed the hand-ins due to insufficient referencing when using material from other sources. In academic writing it is allowed, and even encouraged, to base your writing on data from other sources so this in itself is not wrong, but it must be done according to strict academic standards
Worst case: Incorrect or omitted references is plagiarism, which is a serious academic crime that can lead to suspension from the university.
We will arrange a workshop for all 2nd year students on Wednesday 12 October 11:00 since this is a vital skill in all courses and the thesis projects. But in the meantime I suggested they should take a look at the following introductory material:
The students don't need to use any specific style of references (Harvard, IEEE, APA, Chicago, etc) as long as they are consistent.
Worst case: Incorrect or omitted references is plagiarism, which is a serious academic crime that can lead to suspension from the university.
We will arrange a workshop for all 2nd year students on Wednesday 12 October 11:00 since this is a vital skill in all courses and the thesis projects. But in the meantime I suggested they should take a look at the following introductory material:
The students don't need to use any specific style of references (Harvard, IEEE, APA, Chicago, etc) as long as they are consistent.
Thursday, September 23, 2010
Software quality attributes
I got the following e-mail from a student after discussing definitions and frameworks of quality attributes:
Hello,I replied with this:
It seems there are 2 main groups of ISO standards dealing with software quality:I couldn't find any free copies of these standards, so we can't really use them.
- a 4 part ISO 9126 standard (QA considered are reliability, usability, efficiency, maintainability, portability AND, actually, functionality)
- second generation of ISO software quality standards referred to as SQuaRE (Software product Quality Requirements and Evaluation): ISO/IEC 25000:2005, ISO/IEC TR 25021:2007 and ISO/IEC TR 25060:2010.
Anyway, it would be interesting to get during the lectures some additional information about different quality attributes models out there (early McCall and Boehm models, FURPS, ISO models etc.).
You are correct. You can't access the ISO standards (without paying).I think it will be a little too much to go into detail about different quality frameworks in this course, above they dedicated an entire course at PhD level to the subject.
- For a very soft introduction to quality attributes, read this: http://www.stellman-greene.com/2009/10/03/using-nonfunctional-requirements/
- An in-depth analysis of a few quality attributes are available at http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm
- For a definition of terminology I suggest IEEE std 610.12, bit this covers much(!) more than just quality attributes. It is available at http://ieeexplore.ieee.org/
- You can also read what the PhD students at Blekinge Technical University wrote down in a course about software quality: http://www.bth.se/tek/besq.nsf/pages/017bd879b7c9165dc12570680047aae2!OpenDocument
- And as usual, wikipedia is a good introduction, look at "software quality" or "FURPS" for example.
Hope this helps,
Ulrik
Thursday, September 2, 2010
Tacit knowledge
At the ECSA conference there was a lot of talk about tacit knowledge and the importance of tacit knowledge when architecting systems.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.
Monday, August 2, 2010
Exploring variation mechanisms in the automotive industry: a case study
I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.
You can read about the project, and download the thesis report, at the student's web site: quandoo.
Friday, July 2, 2010
Books on programming embedded systems
I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.
A quick search on Amazon shows some which could be relevant:
I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:
A quick search on Amazon shows some which could be relevant:
- Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
- An Embedded Software Primer by David E. Simon
- Embedded C by Michael J Pont
- Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao
I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:
- Introduction to C, since embedded systems are programmed in C. Period....
I like K&R, but you can choose any book that suits the bill. - Good coding practices in C, for example MISRA C rules.
Read some example of MISRA C-rules here, here and here. - RTOS basics, since this is what is used on most embedded systems.
Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability. - Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
- Development environments, and compilers for embedded development
My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial. - Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited. - Debugging - Too much to cover for this blog post. This is the real dark arts...
- Architecture of embedded systems
Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?
Tuesday, June 15, 2010
Concurrent architecture
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...
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...
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.
Friday, April 30, 2010
More books on architecture
I previously wrote about some textbooks about software architecture. I have have since received three more books.
The first, Software Architecture: Foundations, Theory, and Practice, I disregarded fairly quickly. I think it is too verbose (712 pages!). I could not find the brevity and clarity I think a good textbook should have to should support understanding instead of overwhelming the reader with facts.
I have not had the time to read through The Art of Software Architecture: Design Methods and Techniques yet, it arrived today in the mail.
Software Architecture and Design Illuminated covers a number of different types or styles of architectures, and does so in a manner familiar to the students at SE & M (i.e. in UML models and in Java code examples). It takes a completely different approach to quality attributes compared to Software Architecture in Practice (SAiP), it is structured according to different architectural designs and explains what they are good and bad at. So rather by learning by reason about concepts if focuses on learning by examples. This means that the coverage of quality attributes and tactics is not as comprehensive as in SAiP, for example attributes and tactics related to embedded systems are lacking in comparison since there are few examples of those in the book.
However since the course presently is structured according to theory and not examples of different types of architectures it would require more update of the course compared to the other texts.
The book also has some on-line material for instructors which I have not yet been evaluated.
Summary: Good book which I think presently is the best undergraduate book out there. I like the example-based approach, but it might just be appealing to me because of the fresh approach to an already familiar subject.
The first, Software Architecture: Foundations, Theory, and Practice, I disregarded fairly quickly. I think it is too verbose (712 pages!). I could not find the brevity and clarity I think a good textbook should have to should support understanding instead of overwhelming the reader with facts.
I have not had the time to read through The Art of Software Architecture: Design Methods and Techniques yet, it arrived today in the mail.
Software Architecture and Design Illuminated covers a number of different types or styles of architectures, and does so in a manner familiar to the students at SE & M (i.e. in UML models and in Java code examples). It takes a completely different approach to quality attributes compared to Software Architecture in Practice (SAiP), it is structured according to different architectural designs and explains what they are good and bad at. So rather by learning by reason about concepts if focuses on learning by examples. This means that the coverage of quality attributes and tactics is not as comprehensive as in SAiP, for example attributes and tactics related to embedded systems are lacking in comparison since there are few examples of those in the book.
However since the course presently is structured according to theory and not examples of different types of architectures it would require more update of the course compared to the other texts.
The book also has some on-line material for instructors which I have not yet been evaluated.
Summary: Good book which I think presently is the best undergraduate book out there. I like the example-based approach, but it might just be appealing to me because of the fresh approach to an already familiar subject.
Thursday, December 17, 2009
Organisational changes
There will be some changes to my research group. I don't know how this will affect me in detail, but in general I think it will strengthen software research in Göteborg.
In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.
In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.
Friday, December 11, 2009
Concise writing
I was involved in the software archtiecture course this year, more than the last few years, not surprising since I developed the coruse in 2006. One of the things I did was to evaluate the hand-ins of several assignments, which was disappointing in more ways than one. But the thing I want to bring up in the blog is the lack of concise writing.
I think that one of the most important abilities for an architect (even more so than for other developer roles) is to present the "fundamental ideas" in clear, concise and short manner.
In the hand-ins, a lot of answers covered two pages when a paragraph with less than ten lines would have been sufficient. With a good picture maybe even less.
I don't know if this is beacuse the students were not comfortable with terminology (if you use a model-view-controller pattern, how much more do you need to say about it?). Or if they think verbosity is the same thing as showing understanding? Or if they did not have the time to strip away the "fluff"...
Next year I will propose a maximum number of pages in the hand-ins and deduct points if they write more than that. Obviously they still need to fulfill the task...
It is an art and craft, to write as short as possible, but it helps getting the message across! An architect should hone this skill.
I think that one of the most important abilities for an architect (even more so than for other developer roles) is to present the "fundamental ideas" in clear, concise and short manner.
In the hand-ins, a lot of answers covered two pages when a paragraph with less than ten lines would have been sufficient. With a good picture maybe even less.
I don't know if this is beacuse the students were not comfortable with terminology (if you use a model-view-controller pattern, how much more do you need to say about it?). Or if they think verbosity is the same thing as showing understanding? Or if they did not have the time to strip away the "fluff"...
Next year I will propose a maximum number of pages in the hand-ins and deduct points if they write more than that. Obviously they still need to fulfill the task...
It is an art and craft, to write as short as possible, but it helps getting the message across! An architect should hone this skill.
Wednesday, September 23, 2009
Software architecture book reviews
Some comments on textbooks on software architecture:
As a student text I think the main strengths is it's treatment of terminology and concepts, which also makes it useful as a reference.
A potential problem with this text is that the examples are vey high level. You need experience based in actual programming projects to see the connection between the examples in the book and actual implementations. It is also comparably weak in teaching how to design a top-level desing as part of an architecture. I would say this book is suitable for students at the end of their education.
A Software Architecture Primer is targeted directly to a student audience. I would say it is better if the knowledge in an architecture course should be used in later courses, e.g. a larger project course with co-operating teams, since it is more pragmatic and hands-on in defining a top-level design. Likewise I would guess it could suit a professinal who wants to start creating "simple architectures".
The Process of Software Architecting is the best (and may be the only one) that actually defines the process elements and tasks of architecting and how they would fit in a larger software development process. I would say this book is the best one for the professional architect that wants to more formally define or improve what they do; what inputs to use, what tasks to perform and what should be delivered. It may be suitable for students, but the process focus may make it harder to relate to, e.g. it would give very little help as a preparation for a student project course.
I like all three books and they all have their (different) purpose. Which book to get depends on who you are and what you intend to do or to learn. For a student in the first course on architecture I would suggest the Primer. As a S/W professional who wants to understand what an architect is talking about and why, go with SAiP. For a working architect who wants inspiration for improvement, go with the Process book.
Background: I got the opportunity to take a sabbatical semester from Volvo to teach an undergraduate course on software architecture and design of complex systems at the IT University in 2006. For various reasons I redesigned the entire course from scratch, with a few constraints; the teaching methodology should be a light version of problem-based learning (PBL) already established at the IT University, and the course book was already ordered by the university bookstore "Software Architecture in Practice" by Bass, Clements and Kazman.
I had no real problem with the choice of textbook, and it suited my intended course content quite well. I also thought the PBL methodology fitted very well with the topic of software archtiecture after the course.
I think the course was a success, it received praise form the students as one of the most interesting courses they had taken during their program, and I was very satisifed with the level of knowledge the students showed on the final exam.
- Software Architecture in Practice by Bass, Clements and Kazman
- A Software Architecture Primer by Reekie and McAdam
- The Process of Software Architecting by Eeles and Cripps
As a student text I think the main strengths is it's treatment of terminology and concepts, which also makes it useful as a reference.
A potential problem with this text is that the examples are vey high level. You need experience based in actual programming projects to see the connection between the examples in the book and actual implementations. It is also comparably weak in teaching how to design a top-level desing as part of an architecture. I would say this book is suitable for students at the end of their education.
A Software Architecture Primer is targeted directly to a student audience. I would say it is better if the knowledge in an architecture course should be used in later courses, e.g. a larger project course with co-operating teams, since it is more pragmatic and hands-on in defining a top-level design. Likewise I would guess it could suit a professinal who wants to start creating "simple architectures".
The Process of Software Architecting is the best (and may be the only one) that actually defines the process elements and tasks of architecting and how they would fit in a larger software development process. I would say this book is the best one for the professional architect that wants to more formally define or improve what they do; what inputs to use, what tasks to perform and what should be delivered. It may be suitable for students, but the process focus may make it harder to relate to, e.g. it would give very little help as a preparation for a student project course.
I like all three books and they all have their (different) purpose. Which book to get depends on who you are and what you intend to do or to learn. For a student in the first course on architecture I would suggest the Primer. As a S/W professional who wants to understand what an architect is talking about and why, go with SAiP. For a working architect who wants inspiration for improvement, go with the Process book.
Background: I got the opportunity to take a sabbatical semester from Volvo to teach an undergraduate course on software architecture and design of complex systems at the IT University in 2006. For various reasons I redesigned the entire course from scratch, with a few constraints; the teaching methodology should be a light version of problem-based learning (PBL) already established at the IT University, and the course book was already ordered by the university bookstore "Software Architecture in Practice" by Bass, Clements and Kazman.
I had no real problem with the choice of textbook, and it suited my intended course content quite well. I also thought the PBL methodology fitted very well with the topic of software archtiecture after the course.
I think the course was a success, it received praise form the students as one of the most interesting courses they had taken during their program, and I was very satisifed with the level of knowledge the students showed on the final exam.
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...
Monday, March 9, 2009
Industrial research in student projects
I was asked to talk about my research in the course Research Methods and Technical Writing, at the IT University, together with a number of other researchers here at ITU.
My first thought was talking about case study research in the industry, but another speaker would talk about case studies so I dropped that idea. In the end I decided just to talk about doing students project in industry in general. I have supervised 5 thesis projects so I think I have som knowledge on the subject by now...
I have just finished the lecture and I'm not very satisfied with the outcome. I got very few questions and found it very hard to find any enthusiasm among the students. The original plan was that I would give the lecture a month ago, but various problems with finding a slot in my calendar postponed the lecture several times, so when I finally held the lecture most of the students had already selected topics for their projects.
I made a test of using LaTeX for making slides. Unfortunately I haven't figured out how to share the resulting PDF in this blog. Suggestions are welcome...
My first thought was talking about case study research in the industry, but another speaker would talk about case studies so I dropped that idea. In the end I decided just to talk about doing students project in industry in general. I have supervised 5 thesis projects so I think I have som knowledge on the subject by now...
I have just finished the lecture and I'm not very satisfied with the outcome. I got very few questions and found it very hard to find any enthusiasm among the students. The original plan was that I would give the lecture a month ago, but various problems with finding a slot in my calendar postponed the lecture several times, so when I finally held the lecture most of the students had already selected topics for their projects.
I made a test of using LaTeX for making slides. Unfortunately I haven't figured out how to share the resulting PDF in this blog. Suggestions are welcome...
Thursday, February 12, 2009
AUTOSAR course
I have just come back from the first part of the AUTOSAR course at the Royal Institute of Technology. Including the invited teachers, where I was one, we were 20 people attending, with about 2/3 being from academia and 1/3 from industry.
I think the course went well, but it was obvious that AUTOSAR is a new way of thinking about how to build ECU software compared to what people are used to. I hope that I helped not only in presenting my own stuff but also could answer the questions from the other participants.
My presentation is seen below, for material from the others some can be seen on the course homepage.
Subscribe to:
Posts (Atom)