Add a comment

 

Re: Modularity and testability

I can empathize with you general message. However when I look at the details, I doubt, it will change much. Take this for example:

"It basically says that the abstractions we consider at the architecture level (components, services, modules, layers, etc) are often not explicitly reflected in the code."

Sure, where is the component, the layer etc. in code? How to systematically translate conceptual structures into code artifacts?

But then... What is a component, a service, a module, a layer anyway? Where´s the definition of these "abstractions"? How do they relate to each other? Does a component contain modules? Or is it the other way around? What is a component or service or module relevant for? Design time or runtime? What distinguishes a module from a service from a component? What´s the category these terms belong to? Or are some of them categories and other instances? When to choose which "abstraction"? When to break code up into two components or modules, when not?

That´s all questions which mostly go unanswered. And my guess is that´s also the reason why there are no programming language equivalents for those "abstractions", nor any clear translation rules.

Generation after generation of developers hears these terms being used by older developers. They get some kind of feeling for what they could be - but they actually never exchange their views. It stays nebulous at best.

So nothing will change as long as "modularization" is not put on a more systematic foundation. "Modularize!" has been the call for the past 40 years - and where are we with that? So something must be missing. And that´s not the consciousness about the importance of "modularization". It´s... well, I can´t help but say, it´s a clue as to how to go about it. A clear and simple method to lead from requirements to not only code delivering desired functionality, but also evolvability and quality.

Definitions of ubiquitous but fuzzy terms to me seems a prerequisite for that.

-Ralf

Re: Modularity and testability


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).