Abstraction in Design

The problem.

To design better software (and software-hardware solutions) one need to properly abstract the business. Good and adequate abstraction of real life leads to good system design. And vice verse, bad design is an origin of the failure to computerize smth. Who is guilty? The one who took responsibility for design, because others follow the first guy.

What is a most important in software design?

Many bright people will fail to answer this question properly. It is a burden of bad education in computer courses. I’ve measured hundreds of people around the world, how they understand the design discipline. 98% understand it too shallow. Many will talk for hours about inheritance or encapsulation, templates and whatever imagined, but almost nobody will tell you a word abstraction.

Abstraction is most important in design. How we abstract the real life, real business. What is a proper model abstracted from the physical (hard) word. My observations suggested me that best vision for right abstraction is owned by graduates from physics, chemistry specialties, but not from computer science. Paradox, but it is a reality. If you have a physicist who design the software system – you are lucky one, your project will not fail:) Physicists has an integral vision onto the world, they apply better abstractions than others. Sorry guys, but I can confirm this with my intentional observations in the industry for ~15 years.

So, abstraction is a most important word. Abstraction is a most important skill. Everything starts from abstraction. Abstraction is not dependent on your favorite design method, because it is present in Object-Oriented Design, Design by Contract, Test-Driven Design, Model- Driven Design, Structural Design, Procedural, Functional, Entity-Relationship etc. Just take the list from Wikipedia and ensure that abstraction is a first step for design. You could abstract into structure, into function, into compilation unit, into namespace, into family of algorithms etc. This post is more high-level, I would like to switch to the dilemma, what are you dealing with during abstraction process?

Abstraction levels.

Abstraction leads to different approaches (and decisions). Hence you should be sure you are applying your abstraction at the correct level. Doing that at inappropriate level may lead to severe design flaws. Let me visualize those abstraction levels for you.

You might notice that many things could be abstracted into some kind of hierarchy, that resembles a tree. It is normal, we have tree in nature. We have tree as organizational structure. We have hierarchy of classes and so on. Below is a picture of the tree.

Image

But is a tree is always a tree? At the abstraction level as we looked at it, the answer was yes. We can confirm trees in real life, we all occupy some positions in some organizations. There is a tree. No doubt. OK, let’s look at the tree closer, zoom in and look again.

Image

It is mesh! It is not a tree structure anymore. In has changed its structure from tree to mesh or grid. We are dealing with the same wood, but at different abstraction level. At this level the different model will be designed to reflect the specifics of the thing. Mesh has its own patterns and rationales. If your task is better solved at this level, then forget the tree and design it as a mesh. All you need is to double-check you are really at this abstraction level. I just open the eyes for you that there was a different level, just FYI. It is observed in real life too. Take Enterprise 2.0. It is all about new connectivity within organization. The static tree of organizational structure remains, but new relations are established, which resemble the mesh. Even if they look as horizontal trees, overlapping with tree of positions gives you the mesh. Hence if you work on Enterprise 2.0 abstraction, then you have to consider the mesh instead of the tree. Think on other samples yourself, I just confirm there are many of them around you. Well, what about looking even more closer at the same thing? Zoom in again.

Image

Oops, it is again the tree! What is going on? You just did abstraction at one more level and got different picture than on previous level. Yes, there is a tree again. Small but tree (sounds like Sad but True by Metallica). Sample from real life? Take the same sample, about Enterprise 2.0 initiative within organization. There could be a mash between departments, or groups, but pure tree within small group. And it is common situation. OK, just for fun, to demonstrate you even more abstraction levels:) Return to the initial tree and zoom out.

Image

Wow, it looks again like a grid. We switched context from the tree to the grid one more time. We got the same metamorphose while went to the opposite direction, we zoomed out. Everything cool, no signs for panic. It is just one more abstraction level. Still dealing with the wood, but how different it is! What else? Let’s look below the ground level!

Image

It looks like a second tree below the ground. Tree if deal at this abstraction level. We all know that roots could be the mesh if analyzed closer, and again the tree and so forth. I’d like to mention here the relation to another pattern called symmetry. We are not talking about precise or non-precise symmetry today. We are playing with the trees and the meshes. There are some other combinations remained. You could play yourself. Enjoy.

Conclusion.

Remember that single abstraction level is insufficient. Always look from different abstraction levels to your real thing for which you are going to design some model. The better you dissect the views into different abstraction levels, the better design you can produce. The best design patterns you will apply at every abstraction level, then better your design will be. After understanding of this fundamental concept, your designs will definitely gets better. Happy designing! And sorry if you are not a physicist.

Advertisements
Tagged , , , , , , , , , , , , , ,

One thought on “Abstraction in Design

  1. […] magnitude in both directions, from this to bigger, and from this to smaller. It’s all about abstraction levels. If the software solution, it’s normal that multiple abstraction levels present, […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: