Architecture is defined as "the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."
The architecture is an enabler to achieve certain system qualities, or non-functional properties, and many organisation view their architecture as a strategic technology asset.
An important part in designing an architecture is to identify the organisation or structure of the software and systems parts necessary for the desired qualities. If a certain design or style is used consistent throughout the design of the system it can be considered an architectural pattern. However there are reports that quality attributes are of less importance to users or customers, and this suggest that identifying and delivering competitive features may be more critical to business competitiveness.
Many systems are built on available platforms or frameworks, such as .NET for Microsoft Windows applications, Android for mobile phones or AUTOSAR\footnote for automotive software. The choice of platform constraints the design choices, but also decreases the development effort, at least in theory, and allows software to conform to explicit or implicit domain standards. The challenge for the OEM is to tailor the applications built on top of these platforms to a competitive product. In a sense these types of platforms constitute a reference architecture for a specific product or system architecture.
In this thesis a reference architecture (RA) captures the design ideas and patterns that permeates the architecture with a focus on the design decisions that have great impact on the product family as a whole, i.e. the reference architecture is a template for a specific product or system architecture
This definition of an RA is what is categorised as a ``non-structured reference architecture'' according to Angelov et al., and thus falls outside of their five types of structured RA.
An RA and a product architecture differs, among many other aspects, in that the reference architecture dictates the patterns and principles to implement, i.e. what the design should be, while the product architecture instead captures the instance of the reference architecture with deviations meeting various constraints, i.e. what the design is. Another difference between an RA and a product architecture is that the latter gives a coherent view of the product(s) in a project, possible to track the status of.
Showing posts with label Software architecture reference material. Show all posts
Showing posts with label Software architecture reference material. Show all posts
22 December 2012
27 March 2012
Concrete vs. abstract and detail vs. overview...
There often seems to be confusion about two concepts relevant to representing design information, including models.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
25 May 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.
23 February 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.
10 November 2010
More on quality attributes
Not so long ago I wrote about quality attributes. A friend on facebook gave a tip about a blog post on Software Quality Characteristics 1.0. The bloggers claim it is "the perhaps most powerful public two-page document in the history of software testing." I don't know about that but it sure is a useful document.
28 October 2010
Quality attribute scenarios
Defining a quality attribute, a.k.a. non-functional requirement, is not easy. I know since i did that for a new platform at Volvo. When the verification and validation group comes back and says that it is not possible to verify this as a requirement I can only assume that I did not do a good enough job. But I have to agree with what George Fairbanks wrote in his blog:
Before you get too excited, you should know it’s easier to write these for quantitatively measurable qualities (e.g., throughput, latency) and harder for softer qualities (e.g., modifiability, usability).There are two recent books that have a more agile approach to architecting: Lean Software Architecture by Coplien and Bjørnvig, and George Fairbanks' Just Enough Software Architecture: A Risk-Driven Approach. Unfortunately the latter isn't available in any Swedish internet bookstore, but as soon as I get hold of them I will post a review, as I have reviewed other books on software architecture.
29 August 2010
The future of software architecture research?
There are two areas which I judge to be of great interest to the industry regarding architecture, and I see very little interest from academia
First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?
Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.
Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).
At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.
You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.
A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.
First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?
Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.
Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).
At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.
You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.
A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.
24 June 2010
Blogs
I follow two "professional" blogs:
The latter had in a recent post some links to other blogs which also deals with architecture.
- Heartbeat Development by a former colleague of mine, Johan Segertoft
- SEI Architecture Technology User Network Blog
The latter had in a recent post some links to other blogs which also deals with architecture.
28 October 2009
"The Concise Handbook of Real-Time Systems"
Very long ago (1999?) I attended a conference where I got a small booklet called "The Concise Handbook of Real-Time Systems" by TimeSys Corporation.
I found the booklet to be a very usefull distillation of the most important concepts when designing real-time software. I even ordered some more copies for interested collegues. I hope more developers will be familliar with the content, it would prevent a number of problems...
I don't think the booklet can be ordered any more from the original company, but a quick googling found a later version in PDF here.
I found the booklet to be a very usefull distillation of the most important concepts when designing real-time software. I even ordered some more copies for interested collegues. I hope more developers will be familliar with the content, it would prevent a number of problems...
I don't think the booklet can be ordered any more from the original company, but a quick googling found a later version in PDF here.
7 October 2009
Agile and Architecture
I have read and heard several "observations" on how to incorporate a guiding architecture in the current trend of having agile S/W development. There seem to be a lot of smoke but not so much substance, but I will try to summarise a few points which I have concluded through the smoke.
Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...
Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.
Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?
There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.
If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...
Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software
There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.
Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...
Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.
Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?
There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.
If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...
Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software
There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.
23 September 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.
28 May 2009
Student Presentation on Software Architecture
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
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
15 April 2009
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.
14 March 2009
Two articles on Volvo electrical architecture
There are two articles that give an introduction to the electrical system of the first Volvo S80 (really the architecture to be precise). Even if that particular car is 10 years old the architecture in present Volvo vehicles are still of the same family, but two generations later.
- Volvo S80: Electrical system of the future by Kent Melin. This is an overview of some of the more important architectural decisions for the Volvo architecture.
- Volcano - a revolution in on-board communications by Lennart Casparsson et al. This describes the mathematics for Volvo's signal scheduling on CAN to ensure that all signals are received within their designated deadlines, and a brief description on the processes and tools to administrate the signal database.
11 March 2009
Software architecture resources on the web
I found some resources on the web which I think are useful for people concerned with automotive software architecture, either as some kind of tutorial or as reference material. Some are more generally about software architecture while others are targeted to automotive software.
- Patterns & practices Application Architecture Guide 2.0
- Automotive Software Workshop, San Diego
- JASPAR (but you need to know japanese to get the technical details)
- Software Architecture Views and Perspectives from Brad Appleton's ACME Blog
- Software Architecture Quality Attributes also from Brad Appleton's ACME Blog
23 February 2009
Some websites about software engineering and programming
I found some more interesting websites. I don't expect to have time to explore all of them, but some should give a break me when I have lost inspiration on writing research papers...
Software Engineering Radio
Software Architecture, Architects and Architecting
Teach Yourself Programming in Ten Years by Peter Norvig (very short and interesting of why everything worth knowing takes time)
Next Dawn Programming Tutorials (mostly C and C++)
Software Engineering Radio
Software Architecture, Architects and Architecting
Teach Yourself Programming in Ten Years by Peter Norvig (very short and interesting of why everything worth knowing takes time)
Next Dawn Programming Tutorials (mostly C and C++)
20 February 2009
Recent relevant architectural knowledge...
I was asked by a former colleague if I could help him with some more recent relevant architectural knowledge. Coming from anther person I would have just given a standard answer (see for example this blog post), but since this request came from the person from I have learned almost everything I know about software architecture I felt I needed to give it a little more thought than that...
Some quick thoughts about the present status of software architecture (quick as in not thoroughly researched):
Software architecture is accepted as being useful in it's own right. The role of the software architect is being acknowledged as a separate role from other software practitioners having a different skill set.
The most common view is that architecture are components and their relationships (often explicitly defined interfaces), described in multiple views (like Kruchten's 4+1), just as in IEEE std 1471.
It seems to be commonly accepted that architecture design is driven by quality attributes, see the SEI web site for lots of information about this.
There are numerous architecture description languages (e.g. EAST-ADL2 or AADL) but none seem to emerge as a industry standard beyond UML 2.0. And I have not heard of too many examples of where ADLs are commercially used on a wider scale.
Nobody argues about the importance of patterns, but the reference is still Pattern-Oriented Software Architecture (POSA).
Some claim Service-Oriented-Architecture is dead, while others don't.
Standardised architectures seem to more and more common, AUTOSAR is one, Integrated Modular Avionics (IMA) is another. I'm sure there are more in other business domains I'm not aware of. Standardised architectures always seem to generate interest at workshops and meetings.
There are several on-line resources with solid material, some are directed to, or by, practitioners, like
This emphasis leads to merging the research disciplines of knowledge management with software architecture.
Mary Shaw and Paul Clements wrote a survey article The Golden Age of Software Architecture: A Comprehensive Survey about how the subject of software architecture has developed in the last 20 years, Kruchten et al. wrote a similar paper The Past, Present, and Future of Software Architecture.
Finally I like the article The Art and Science of Software Architecture by Brown and McDermid because they have a "unbiased" take on the present and future of the field.
Some quick thoughts about the present status of software architecture (quick as in not thoroughly researched):
Software architecture is accepted as being useful in it's own right. The role of the software architect is being acknowledged as a separate role from other software practitioners having a different skill set.
The most common view is that architecture are components and their relationships (often explicitly defined interfaces), described in multiple views (like Kruchten's 4+1), just as in IEEE std 1471.
It seems to be commonly accepted that architecture design is driven by quality attributes, see the SEI web site for lots of information about this.
There are numerous architecture description languages (e.g. EAST-ADL2 or AADL) but none seem to emerge as a industry standard beyond UML 2.0. And I have not heard of too many examples of where ADLs are commercially used on a wider scale.
Nobody argues about the importance of patterns, but the reference is still Pattern-Oriented Software Architecture (POSA).
Some claim Service-Oriented-Architecture is dead, while others don't.
Standardised architectures seem to more and more common, AUTOSAR is one, Integrated Modular Avionics (IMA) is another. I'm sure there are more in other business domains I'm not aware of. Standardised architectures always seem to generate interest at workshops and meetings.
There are several on-line resources with solid material, some are directed to, or by, practitioners, like
- Grady Booch's blog
- patterns & practices Application Architecture Guide 2.0
- Resources for software architects from Bredemeyer Consulting
- Software Architecture web site at the SEI
- Jan Bosch's website
This emphasis leads to merging the research disciplines of knowledge management with software architecture.
Mary Shaw and Paul Clements wrote a survey article The Golden Age of Software Architecture: A Comprehensive Survey about how the subject of software architecture has developed in the last 20 years, Kruchten et al. wrote a similar paper The Past, Present, and Future of Software Architecture.
Finally I like the article The Art and Science of Software Architecture by Brown and McDermid because they have a "unbiased" take on the present and future of the field.
28 January 2009
Architecting Systems with UML 2.0
The best (and shortest) introduction to UML 2.0 from an architect's viewpoint is an article called Architecting Systems with UML 2.0 by Morgan Björkander and Cris Kobryn.
Obviously you need to know the basics of UML 1.0...
Obviously you need to know the basics of UML 1.0...
22 December 2008
Complexity
Sooner or later the issue of complexity always comes up when discussing software architecture.
Since I firmly believe in my colleague Dennis Selin's statement that one of the main purposes of having an architecture is to manage complexity I am interested complexity as a concept. It does seem to be difficult to define complexity, more than "I know it when I see it".
However I have found a few articles on the subject I found worth reading. I welcome other suggestions.
PS. I will get back to other purposes of software architecture according to Dennis in a later post.
Since I firmly believe in my colleague Dennis Selin's statement that one of the main purposes of having an architecture is to manage complexity I am interested complexity as a concept. It does seem to be difficult to define complexity, more than "I know it when I see it".
However I have found a few articles on the subject I found worth reading. I welcome other suggestions.
- John A McDermid, Complexity: Concept, Causes and Control, in Proceedings of the 6th IEEE International Conference on Engineering of Complex Computer (ICECCS 2000), 2000.
- Murray Cantor, Understanding complexity, in The Rational Edge, 2007
- Mohsen AlSharif et al, Assessing the complexity of software architecture, in Proceedings of the 42nd annual ACM Southeast Regional Conference, 2004
PS. I will get back to other purposes of software architecture according to Dennis in a later post.
6 December 2008
Introduction to software architecture research
I got an e-mail form one of the master's student at the Software Engineering & Management program who wanted to know more about research on software architecture. Here is my reply...
Some websites of interest:
http://www.sei.cmu.edu/architecture/index.html
The homepage of the most well-known research groups on software architecture. You can for example look at their "essential bookshelf":
http://www.sei.cmu.edu/architecture/essential_collection.html
http://www.handbookofsoftwarearchitecture.com/
Grady Booch's (of UML fame) website about architecture. You need to register to access the entire website.
http://www.janbosch.com/
Jan Bosch' website, one of the foremost researchers in Europe. Check out his publication list. He has written several "overview" articles as well.
You should also be familiar with ISO/IEC-standard 42010 "Recommended Practice for Architectural Description of Software-intensive Systems" (identical to IEEE Std 1471-2000)
http://www.amazon.com/Software-Architecture-Practice-2nd-Engineering/dp/0321154959
This is the standard textbook about software architecture. If you want an undergraduate text I would recommend
http://www.amazon.com/Software-Architecture-Primer-John-Reekie/dp/0646458418/ref=pd_sim_b_6
http://www.amazon.com/Documenting-Software-Architectures-Beyond-Engineering/dp/0201703726
The best (and only?) book about documenting software architectures
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley/Professional/dp/0201633612
For an architect I would recommend the following book instead:
http://www.amazon.com/Pattern-Oriented-Software-Architecture-System-Patterns/dp/0471958697/ref=sr_1_1?ie=UTF8&s=books&qid=1228480692&sr=1-1
There are 5 volumes, but the book everybody refers to is vol. 1
For software product lines I'm most familiar with
http://www.amazon.com/Design-Use-Software-Architectures-Product-Line/dp/0201674947/ref=sr_1_1?ie=UTF8&s=books&qid=1228480867&sr=1-1
and
http://www.amazon.com/Software-Architecture-Product-Families-Principles/dp/0201699672/ref=cm_lmf_tit_8_rdssss0
But there seem to be recent texts, such as:
http://www.amazon.com/Software-Product-Lines-Practices-Engineering/dp/0201703327/ref=pd_sim_b_2
and
http://www.amazon.com/Software-Product-Lines-Action-Engineering/dp/3540714367/ref=pd_cp_b_1?pf_rd_p=413864201&pf_rd_s=center-41&pf_rd_t=201&pf_rd_i=3540243720&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1KC7RGT8ZATZCWGSE3MM
Hope this helps!
Subscribe to:
Posts (Atom)