Part 3 in Lucas Moser’s Four Part Series.
At times, chemistry students have a difficult time wrapping their heads around the structure of a molecule. For help, they carry small plastic models to help them think through molecular structures. The models are comprised of multi-colored balls and sticks that can be used to represent a carbohydrate or a protein. As the student tries to understand certain reactions, he or she can move these pieces around to simulate the actual behavior of the protons, neutrons, and electrons. When the student needs to communicate the structure of a molecule to a teacher or fellow student, the plastic model can serve as the basis for those discussions.
The challenge is that, as a software development team, we can’t use plastic balls and sticks to help describe the structure and behavior of software or data. Instead of these, we rely on computational models, design patterns, and idioms to grasp how a real life system works and to explain how it can be represented in a virtual software world.
An IT professional’s role in software development is to have a thorough understanding of both the problem at hand and implemented software solution. In Christopher Alexander’s book A Pattern Language, he talks about how repeated patterns have been used in architecture to address certain problems in that domain. Within the text, Alexander asserts that:
...each pattern represents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. The empirical questions center on the problem—does it occur and is it felt in the way we have described it? — and the solution —does the arrangement we propose in fact resolve the problem? And the asterisks represent our degree of faith in these hypotheses. But of course, no matter what the asterisks say, the patterns are still hypotheses, all 253 of them—and are therefore all tentative, all free to evolve under the impact of new experience and observation. - Christopher Alexander et al., A Pattern Language, p. xv
How does this apply to software modeling?
Our patterns are ideas like three-tiered architecture, pure functions, event driven programming, and service-oriented architecture (SOA). These, and many more, are all building blocks for modern day applications. As in Alexander’s case, these ideas represent “our current best guess” as to how a software solution might look. They are a starting point described in common language that IT professionals can use to communicate with programmers and application stakeholders alike.
It is also important to note that Alexander’s patterns are not a toolbox. They are only a compilation of hypotheses. After initial assessment, requirements will evolve and so will chosen patterns to represent them. Evolution may indicate that a well-known pattern needs to be tweaked to meet a specific need. Three-tier architectures may wind up with four tiers. In other cases, evolution may mean an entire pattern needs to be swapped out for a new approach.
Understanding modeling enables IT professionals to communicate software behavior. By doing so, IT professionals position themselves to most effectively add value to the software development process.
Next, we will discuss how developers benefit from models and software modeling.