[CSUSB]>> [CNS]>> [CSE]>> [R J Botting]>> biba.php
Quite separately, it has been observed that architecture, and patterns, should explicitly be preserved in the implementation.
My conclusion is that we should work towards the kinds of implementation infrastructure that would support multiple, superimposed, architectures, and multiple, superimposed, typing of elementary phenomen that pin these architectures together"
Answer to questions: No notation for info not in "the diagram", "There is no calculus. Different and parallel abstractions of the problem exist and in each of these abstractions you are concerned with some subset". "There is no need to put the problem frame back together in any sense at all. That is, problem frames are not hierrchical. Furthermore, the decomposition into a hierarchy of procedures is a very poor way to about solving a problem." "Decomposition into subproblems that are not solvable is pointless". "You are making the assumption that you make a chunk of software for each of the boxes, but it is not like that. Implementation as a hierarchy of procedures in *not* the right way. Procedures can't be combined with conjunctions."
Search for a specific bibliographic item by name.
To see the complete bibliography (1Mb+) select:[Bibliography]