- #Modular software wrapper architecture example full#
- #Modular software wrapper architecture example free#
It’s the types introduced by dependencies that end up in the static interface of a component. However, static typing doesn’t solve the problem, it merely shifts it from run time to compile time. Some readers’ first reaction is likely to be “that’s a symptom of bad specifications” or “that’s the trouble you deserve for using a dynamically typed language”. And that trouble would not go away if I could migrate NumPy and SciPy inside my component’s namespace as suggested above. If visualizer expects a NumPy array as the input to one of its functions, I’d be in trouble again as the class definition in the two different versions of NumPy might not be the same. That would make NumPy not only a run-time dependency of the code, but also a specification dependency for the interface. My ode_solver could, for example, return some value as a NumPy array.
#Modular software wrapper architecture example full#
The second obstacle is that the full specification of a module’s interface (something that’s never ever written down in Python) in general includes classes defined by its dependencies. Another way to look at this is to consider each package’s detailed dependency list, with version requirements, as part of its interface. That component becomes impossible to combine with my ode_solver because of conflicting version requirements - the well known dependency hell. Suppose I have another component called visualizer that also uses NumPy and SciPy, but requires different versions.
The shared top-level namespace creates a strong interaction between all components at all levels.
#Modular software wrapper architecture example free#
And since developers are free to modify their packages as they like, this makes the top-level namespace an instance of shared mutable state, universally recognized as problematic in software engineering. Independently written software components in Python always live in the globally shared top-level namespace.
In real Python, they can only remain numpy and scipy, as their authors decided to call them. The packages would become ode_solver.numpy and ode_solver.scipy. In a hierarchically modular architecture, implementation details of a component, such as the names of the packages it uses, would be hidden from outside view. Suppose I want to create a software component called ode_solver that uses the popular packages NumPy and SciPy. One obstacle is that there is no way to combine independently designed modules into a larger hierarchy. Since namespaces are independent, and can contain sub-namespaces, this looks like a perfect match for a hierarchically modular architecture. Python’s module system is basically a hierarchy of namespaces, with namespaces containing mainly function and class definitions, but also variables referring to arbitrary data objects. To explain where the problem is, I will use Python as an example because it is widely known, but the arguments apply with some modifications to most other languages as well. It may seem as if many of today’s programming languages propose exactly this kind of architecture for designing software systems, but a critical inspection shows that they don’t. I won’t repeat his arguments for the ubiquity of such systems, so please read the paper - it’s definitely worth it, and it’s very clearly written. I prefer the shorter term “modular” for this feature, and thus end up with “hierarchically modular” as my label for the architecture that Simon describes in much detail. Simon describes the subsystems at each level as “nearly decomposable”, meaning that the interactions between subsystems are much less important than the interactions between the parts inside a subsystem. Systems consist of subsystems, which consist of sub-sub-systems, etc. The prime characteristic that Simon identifies in most complex systems is a hierarchical structure. But even though complexity is recognized as a major issue in software development today, the architecture described by Simon is not common in software, and in fact seems unsupported by today’s software development and deployment tools. In his 1962 classic “The Architecture of Complexity”, Herbert Simon described the hierarchical structure found in many complex systems, both natural and human-made. Wanted: a hierarchically modular software architecture
0 kommentar(er)
