Comments

• • Eric von Stackelberg@ericvo1

  

  Eric von Stackelberg December 5, 2010 - 5:50pm

  A pleasure to read, and I have some questions and comments.

  How would BSAL be more expressive than UML supported with backwards and forwards code generation? Typically I find limitations with sequence and collaboration diagrams to code, would it be appropriate here?

  The issue of bringing the architect on late is generally a result of project management effectively in a waterfall model instead of risk management in a spiral iterative model. I would argue that is because it is generally assumed that requirements on a new system can be appropriately defined which I maintain is a falsehood unless you are dealing with a very mature domain with little change.

  Also are you comfortable with software factories versus software product lines and can you comment on them?

• • Behzad Karim@behzadka

  

  Behzad Karim December 28, 2010 - 2:05am

  Thank you for your comments Eric. I always enjoy discussing these topics. I will post my comments on each topic separately (BSAL <-> UML, Project Management and Requirements, Software Factories and Software Product Lines)

   

  1 - UML and BSAL

   

  The initial assertion set forth was that while UML diagrams are great for communicating architecture and design, as layers of detail are added to these diagrams, limitations become apparent and keeping up with the diagrams becomes a task of its own. While UML diagrams are ideal for conveying the high level design of a system to a large group, there seems to be a great amount of detail that an architect needs to get across to developers through high level design and although the capability exists in UML, the experience is not living up to expectations in practice.

  Staitc diagrams are where UML excels and is very powerful. Class hierarchy, inheritence and relationships could not be expressed anywhere any better. However when it comes to defining software/system behavior, diagrams start getting messy!

  Specifically, think of the amount of diagram development that needs to be done to convey one service call including possible return values and error conditions. One might suggest that with some of the IDE tools on the market today, coding the service itself would be much faster. However, the Architect does not need and should not be doing the actual coding at the point of design simply because it requires a paradigm shift to do so (loss of efficiency) and the code will most likely be redone later by developers when more details become apparent anyway. At design stage, the Architect needs a more efficient medium to communicate this sort of design, the behavioral aspects of software. 

     

  After all, it is true that a picture is worth a thousand words, but a picture is certainly not a replacement for words.That is why we still need words to explain the design today, which is fine. However usage of natural languages in computing has always brought in ambiguity and loss of efficiency with it. So the question once again is, from this point on, can a structured architecture definition language be more useful than a natural language? 

  Can the idea of a text based architecture definition language based on specific software system models (this is important in order to narrow down the scope of the language) strengthen the architecture and design process and be worth exploration? 
• • Eric von Stackelberg@ericvo1

  

  Eric von Stackelberg February 1, 2011 - 3:42pm

  Could you add some of your BSAL links to the Software Architecture Group. At a specification level, if it is more effective to code with an IDE that is positive for product quality and delivery. I am inclined to argue that our organizational hierarchies and what constitutes as specific job task needs to change not the creation of a new language. Is there some material on the value generated by this type of structured language?