Abstraction layer

[PaulG.]

We are in a little bit of discussion in info-LabVIEW concerning someone's idea of wanting shift registers available in stacked sequences. Yes. You read correctly. I don't need to start that discussion here because I already know how >90% already feel about that.

However, a comment stirred up a question in me:

Define "abstraction layers" as they pertain to Global warming/"climate change" LabVIEW applications.

Thank you.

Edited May 18, 2010 by PaulG.

[ShaunR]

We are in a little bit of discussion in info-LabVIEW concerning someone's idea of wanting shift registers available in stacked sequences. Yes. You read correctly. I don't need to start that discussion here because I already know how >90% already feel about that.

However, a comment stirred up a question in me:

Define "abstraction layers" as they pertain to Global warming/"climate change" LabVIEW applications.

Thank you.

Not being aware of the info-labview discussion-heres my two penneth.

In general terms. An abstraction layer is an interface presented to higher level funtions, that hides the implementation. In terms of Labview, a good example of a HAL (hardware abstraction layer) would be VISA.

[MikaelH]

Here's an example of one of my current applications.

VIs in the Highest layer is only allowed to call VIs located in the same layer or one layer below,

i.e. not call VIs in the lowest layer.

VIs in the second layer is only allowed to call VIs located in the same layer or one layer below,

i.e. not call VIs in the top layer.

//Mikael

[PaulG.]

Here's an example of one of my current applications.

VIs in the Highest layer is only allowed to call VIs located in the same layer or one layer below,

i.e. not call VIs in the lowest layer.

VIs in the second layer is only allowed to call VIs located in the same layer or one layer below,

i.e. not call VIs in the top layer.

//Mikael

Not bad, but I think you might be making this WAY TOO COMPLICATED than it needs to be.

To me, abstraction layers are clearly defined operations from bare-bones hardware up to the user interface.

I don't see LV code having very many "layers of abstraction".

To me, layers of abstraction are logical and simple:

* Hardware. You have an electro-mechanical device that senses and provides data.

* Driver. You have software that translates this data into a form that can be used by software.

*Software. You access that data from LV code.

*User Interface. The data are displayed to a user in a way that is meaningful and useful to the user.

Four simple steps, i.e. "abstraction layers" as far as I can see. Anyone else?

[PaulG.]

Not bad, but I think you might be making this WAY TOO COMPLICATED than it needs to be.

To me, abstraction layers are clearly defined operations from bare-bones hardware up to the user interface.

I don't see LV code having very many "layers of abstraction".

To me, layers of abstraction are logical and simple:

* Hardware. You have an electro-mechanical device that senses and provides data.

* Driver. You have software that translates this data into a form that can be used by software.

*Software. You access that data from LV code.

*User Interface. The data are displayed to a user in a way that is meaningful and useful to the user.

Four simple steps, i.e. "abstraction layers" as far as I can see. Anyone else?

A developer in info-LabVIEW said that whenever I put code into a sub-VI I am creating a layer of abstraction. I don't know if I agree or disagree. I just don't want to think we are going to over-use the term ... like we do with the term "elegant". I mean, do I create another layer of abstraction when I put my pants on over my skivvies?

[Grampa_of_Oliva_n_Eden]

A developer in info-LabVIEW said that whenever I put code into a sub-VI I am creating a layer of abstraction. I don't know if I agree or disagree. I just don't want to think we are going to over-use the term ... like we do with the term "elegant". I mean, do I create another layer of abstraction when I put my pants on over my skivvies?

I would say no.

My first introduction to the term "Abstraction Layer" happened when I was introduced to the OSI seven Layer Model for network communications.

THe TCP/IP functions in LV are an Abstraction Layer for the network stack.

Underneath that layer (the only layer we can touch using the built-in functions) the TCP functions in turn use the Abstraction offered by the IP layer (note: Windows is fuzzy here, when last I paid attention) which in turn uses the hardware which is abstracted through the hardware driver.

The under lying layers are handling the dirty work of making sure the packets are broken up into parts that will travel over the wire and make sure the get reassembled in the correct order etc.

If you have evern looked at what an Ethernet Sniffer that uses the Promiscuous mode of the ethernet interface, you will see that to understand what is traveling over the wire requires you to parse the ethernet packet header (Source Destination and protocol) and then use the proper rule for THAT protocol etc.

THe TCP/IP abstraction offered with LV turns this complicated stack of protocol etc. into what is virtuallly abstracted a virtual wire.

THe same thing applies to file I/O and for that matter the INI files and TDMS are also abstractions.

If I got any of that wrong please feel free to correct me.

Ben

[PaulG.]

I would say no.

My first introduction to the term "Abstraction Layer" happened when I was introduced to the OSI seven Layer Model for network communications.

THe TCP/IP functions in LV are an Abstraction Layer for the network stack.

Underneath that layer (the only layer we can touch using the built-in functions) the TCP functions in turn use the Abstraction offered by the IP layer (note: Windows is fuzzy here, when last I paid attention) which in turn uses the hardware which is abstracted through the hardware driver.

The under lying layers are handling the dirty work of making sure the packets are broken up into parts that will travel over the wire and make sure the get reassembled in the correct order etc.

If you have evern looked at what an Ethernet Sniffer that uses the Promiscuous mode of the ethernet interface, you will see that to understand what is traveling over the wire requires you to parse the ethernet packet header (Source Destination and protocol) and then use the proper rule for THAT protocol etc.

THe TCP/IP abstraction offered with LV turns this complicated stack of protocol etc. into what is virtuallly abstracted a virtual wire.

THe same thing applies to file I/O and for that matter the INI files and TDMS are also abstractions.

If I got any of that wrong please feel free to correct me.

Ben

This is my understanding of an abstraction layer as well.

[ShaunR]

This is my understanding of an abstraction layer as well.

Indeed. Nebulus describes a "hardware abstraction layer"But you can also have "software abstraction layers" for example ADO for databases.

[Daklu]

Hrmm... well as I'm the other developer who make the abstraction layer comment I hope y'all don't mind if I offer a contrasting viewpoint. If you don't agree that's okay, no harm no foul. *shrug*

The meaning of "abstraction layer" is highly dependent on the context in which it's being discussed. From 50,000' up, Paul's four layers make sense. They're very thick layers, but typically you want to be talking about the big pieces from up there. However, when you zoom in on any one of those layers you'll find they're each made up of their own abstraction layers. Device drivers aren't written as one giant piece of monolithic code. They are built up in layers that start somewhere down in the kernel and work their way up through the OS HAL, security layers, and who knows what else. If you tell a software engineer writing kernel mode drivers that he's not using abstraction layers he'll disagree.

As software developers everything we do revolves around creating abstractions. Every public vi we write is a layer of abstraction other developers working on the project need to understand. It may not a very big layer, but it's there. Good abstraction layers are highly cohesive and clearly defined. They tend to be relatively thin, but not always. They are designed so that the public methods all offer about the same level of abstraction. It's because they are well-designed and offer about the same level of abstraction that we can zoom out and think of it as one big layer.

Bad abstraction layers (and I'm as guilty of writing them as anyone else) are not. They often have an unpredictable mix of high level and low level functions. I've run into several cases where I've had to bypass it and go to the layer below (you know, the one that was supposed to be abstracted away) to get the functionality I needed. Instead of focusing on one particular thing, they end up doing a little of this and a little of that. In my experience they often do not have clear boundaries and may offer overlapping functionality with other abstractions. They are too thick, too wide, soft around the edges, and incomplete. (Imagine trying to use VISA if you had to make Win32 api calls to fetch a Windows security token with every prim.)

I try to follow a programming model similar to what Mikael posted. I confess I don't understand why Paul thinks that is too complicated. I think it's much, much easier to understand an application when it's layered and modularized than when there's a disorganized clump of vis all making calls to each other and offering different levels of abstraction. Maybe our brains are wired differently? Maybe you really do have cohesive abstraction layers in there but don't realize it?

Anyhoo, that's my .

I mean, do I create another layer of abstraction when I put my pants on over my skivvies?

Metaphorically speaking, yes. You're telling the rest of the world, "You don't need to know if I'm wearing Superman Underoos, WalMart Tighty-Whities, or going commando. You just need to know that everything is taken care of and none of my private methods will be exposed."

[Black Pearl]

I agree with Daklu that software developement is to a very big fraction about creating abstractions. If you draw good software, you spend a lot of time on this and not on the functionality of the code: descriptive Icons, 4x2x2x4 connector pane, organizing vi's in directories, folders, libraries, placing code inside SubVIs, if you OOP, a lot more overhead is going into encapsulation...

Abstraction is beautiful, because it structures our code like nothing else.

A major advance of good abstraction design is reuse.

Here is one of my better designs. As part of the project I had a motion controller, which came with a dll driver and a bunch of ugly vi's that did implement the dll calls.

My lowest level abstraction layer did use the provided vi's, but wrapped them with a 4x2x2x4 connector pane and included error handling. This layer could be directly reused on a diffrent project that had the same motion controller but a diffrent mechanical design.

The layer above provides the functionality I did need for this project (for the specific mechanical design). It consists of very view vi's that sometimes perform complex operations, like Posisition(x,y), Home, ...

On top of these vis, there is a single Action Engine (no LVOOP available). This AE is only for encapsulation, so all VIs that deal with motion are grouped in the hierarchy window and the 'handle' for the controller card is hidden from the user.

So the complete LV code consists of 4 abstration layers:

1. dll calls

2. error handling

3. project specific functionality

4. encapsulation

My current studies of the uml architecture also teach me how to design abstraction layers. For each concept that is introduced in the uml architecture, there is a set of deticated classes in the inheritance tree (actually, it's a graph as they allow multi-inheritance). And each set of classes is placed in a package. As an example, the ownership package has the two classes namedElement and Namespace. Together, they provide the funtionality to create a tree of nested elements (namespaces are elements that may contain other elements) and to navigate through this tree using OwnedElements and Owner.

There is no mixing with other concepts. So one concept -> one layer.

Felix

[PaulG.]

"You don't need to know if I'm wearing Superman Underoos, WalMart Tighty-Whities, or going commando. You just need to know that everything is taken care of and none of my private methods will be exposed."

Going commando?

I like your explanation of abstraction. I guess it's what we do but I never thought of creating sub-VI's as creating layers of abstraction. I'll certainly be thinking a little differently about my code when I create my next sub-VI. Thanks for your opinion.

[Daklu]

I never thought of creating sub-VI's as creating layers of abstraction.

I was thinking about this more last night and I concluded that you have a very good point.

I tend to use "layer of abstraction" and "level of abstraction" interchangably, but I think they are subtly different. A layer implies a set of methods that work together to abstract away lower level functionality. Abstraction level relates to how much of the lower layer's functionality the upper layer is discarding. Higher level abstractions provide more functionality at the cost of allowing less control over what the lower level functions are actually doing. An abstraction layer may have multiple abstraction levels.

Creating a sub vi is always adding a new unit of abstraction, but isn't necessarily adding a new layer or a new level--you can only determine that in the context of the other vis in your project. My designs tend to have multiple thin layers with each layer offering a consistent abstraction level, so for me arbitrarily wrapping up some vis in another one just to save space is almost always adding a new level and may (depending on where I put that new vi in the project) add another layer. I definitely could have done a better job of explaining what I meant. I'm still not sure I've done it adequately. I have a very clear picture in my head of how I think about it but I don't know how to concisely describe it.

[And in case anyone was wondering, I'm NOT the one who was suggesting adding a shift register to the stacked sequence structure. ]

[Yair]

"You don't need to know if I'm wearing Superman Underoos...

But since those are worn on the outside, doesn't that mean your abstraction is leaking?

[Black Pearl]

I looked up what an abstraction 'is', so here comes the uml2-spec:

7.3.1 Abstraction (from Dependencies)

Generalizations

• “Dependency (from Dependencies)” on page 62

Description

An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different

levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a

mapping between the supplier and the client.

Attributes

No additional attributes

Associations

• mapping: Expression[0..1]

A composition of an Expression that states the abstraction relationship between the supplier and the client. In

some cases, such as Derivation, it is usually formal and unidirectional. In other cases, such as Trace, it is usually

informal and bidirectional. The mapping expression is optional and may be omitted if the precise relationship

between the elements is not specified.

Constraints

No additional constraints

Semantics

Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional

or bidirectional. Abstraction has predefined stereotypes (such as «derive», «refine», and «trace») that are defined in the

Standard Profiles clause. If an Abstraction element has more than one client element, the supplier element maps into the

set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The

situation is similar if there is more than one supplier element.

Notation

An abstraction relationship is shown as a dependency with an «abstraction» keyword attached to it or the specific

predefined stereotype name.

Felix

PS: I didn't yet read the dependencies package, so I can't translate this to normal-geek-speak.

[Daklu]

But since those are worn on the outside, doesn't that mean your abstraction is leaking?

ROFL!

[Rolf Kalbermatter]

I was thinking about this more last night and I concluded that you have a very good point.

I tend to use "layer of abstraction" and "level of abstraction" interchangably, but I think they are subtly different. A layer implies a set of methods that work together to abstract away lower level functionality. Abstraction level relates to how much of the lower layer's functionality the upper layer is discarding. Higher level abstractions provide more functionality at the cost of allowing less control over what the lower level functions are actually doing. An abstraction layer may have multiple abstraction levels.

Creating a sub vi is always adding a new unit of abstraction, but isn't necessarily adding a new layer or a new level--you can only determine that in the context of the other vis in your project. My designs tend to have multiple thin layers with each layer offering a consistent abstraction level, so for me arbitrarily wrapping up some vis in another one just to save space is almost always adding a new level and may (depending on where I put that new vi in the project) add another layer. I definitely could have done a better job of explaining what I meant. I'm still not sure I've done it adequately. I have a very clear picture in my head of how I think about it but I don't know how to concisely describe it.

[And in case anyone was wondering, I'm NOT the one who was suggesting adding a shift register to the stacked sequence structure. ]

Reading your first Info-LabVIEW comment I certainly was thinking, man he is really making an elephant out of each tiny VI.

But with this explanation I fully agree.

[Daklu]

In the spirit of layering, here are some diagrams of an application I'm currently working on. I like to use the MVC architecture as it does a good job of decoupling the functional code (Model) from the UI (View) and glue code (Controller.) What I'm showing here is the current design of the model. This is based largely on the document, "How to Mitigate Hardware Obsolescence in Next-Generation Test Systems" found here, though I use slightly different terminology and have added layers so I can use an MVC architecture.

The first diagram shows the classes organized as layers and the dependencies between each layer. Notice I've inverted the dependency between the Application Separation Layer and the Device Separation Layer. This makes it much easier for me to swap out different kinds of hardware as the test system changes over time. If we switch from an ADU 218 relay box to something else, I don't need to break existing code to implement it--I simply derive a new child class from ButtonActivatorInt, implement an AcmeRelayBox device driver .ogp package, and code the AcmeRelayBoxDSL class. When I have those coded up and tested I can make a simple change in the Application Separation Layer that instantiates AcmeButtonActivator instead of ButtonActivator.

The second diagram shows the model as a whole and the relationships between the different classes in the model. The ports (little squares) around the edge of the block show how the Model interacts with other components in the application. At the bottom I have classes that make calls into "drivers" (Labview classes or libraries) I've created for each hardware device and packaged as .ogp files. (Usually these are thin wrappers around the manufacturer's dlls.) At the top the controller is only aware of the TestScript, TestCase, and ConnectionMonitor objects. All the other classes and methods in the model are invisible to the controller, which makes the application level code *much* easier to write IMO.