Abstraction levels

“Abstraction” is the action of simplifying something up to the most important traits.

I like to explain it as a sort of google maps but instead of zooming in and out of a world map you are exploring a model. Just as with google maps we have several views with different levels of detail. We call these abstraction levels. In the context of designing a system this is a useful tool. So using google maps as a metaphor I want to share a personal way to see the abstraction levels on a system.

Abstraction Level Purpose
10,000 ft view Overview of all the actions that can be done on the system
8000 ft view Overview of the way a user executes the actions on the system (UI)
6000 ft view Overview of the steps needed to carry on the action being requested
4000 ft view Overview of the objects that carry on the action being requested
Ground lvl Implementation details of the object

For the sake of this discussion i’ll leave the 8000 ft. view out.

10,000 ft. view

This level can be represented on several ways. My favorite one is using a use case diagram.

The other way I find absolutely useful is using BDD’s “feature” artifact.

 Feature: Create Loan
 In order to pay for a necessary item
 As a customer with no cash at hand
 I want to get a loan

The nice thing about this is that it also expresses the user’s objective.

The 6000 ft. view

In this view we peek inside the actions of the system (use case, feature). Typically, an action has more than one execution path: the default (expected) path and one or more alternatives. This view can be explored using an Activity Diagram.
This view can also be explored using BDD’s “scenario” artifact.

 Scenario: Apply for a loan while having an open loan with a different provider
 Given I already have an account on the site
 And I have an open loan on with a different provider
 When I try to create a new loan
 Then I'll see a message saying "Sorry you can't open a new loan if you already have one open"

Scenario: Apply for a loan with an amount exceding the maximum allowed by the state
 Given I already have an account on the site
 When I try to create a new loan
 And the amount requested exceeds the maximum allowed by the state I live in
 Then I'll see a message saying "Sorry the amount you applied for exceeds the amount allowed by the state"

Scenario: Get a loan
 Given I already have an account on the site
 And I have no open loan
 When I try to create a new loan
 Then the loan will be created

The 4000 ft. view

If the 6000 ft. view allows us to peek into the action, showing us the several execution paths, then the 4000 ft. view it’s all about peeking into the execution paths and the way they are carried along by the business objects. I usually use interactions diagrams on this level.

As you can see this diagram focus solely on the business objects, their responsibilities and the interactions amongst them in order to fulfill the action objectives. In this particular example I’m including 2 paths, as you can see from the lines that return to the Customer actor. I could have one for each scenario.
The point here is that these methods are just loosely defined, still waiting to be fleshed out. This is where TDD comes in. You can create a test declaring what you expect the behavior to be and then code out this particular method, isolating any external dependency.

TDD vs BDD

I originally depicted this while trying to explain that TDD and BDD are basically the same thing just on a different abstraction level.
So if you create tests for anything on the 4000 ft. view before any code is in place, then it’s called TDD, whereas if it’s for anything above that abstraction level, it’s called BDD.

Let me know your thoughts.