Jump to content

Abstraction layer


Recommended Posts

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. rolleyes.gif

However, a comment stirred up a question in me:

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

Thank you. thumbup1.gif

Edited by PaulG.
Link to comment

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. rolleyes.gif

However, a comment stirred up a question in me:

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

Thank you. thumbup1.gif

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.

  • Like 1
Link to comment

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.

post-941-127423288937_thumb.png

//Mikael

  • Like 1
Link to comment

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.

post-941-127423288937_thumb.png

//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?

Link to comment

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? rolleyes.gif

Link to comment

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? rolleyes.gif

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

  • Like 1
Link to comment

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.thumbup1.gif

Link to comment

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

Link to comment

"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." laugh.gif

Going commando? laugh.gif

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.

Link to comment

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. blink.gif

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

Link to comment

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.

Link to comment

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. blink.gif

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

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

But with this explanation I fully agree. :lol:

Link to comment
  • 2 weeks later...

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.

post-7603-127542981662_thumb.png

post-7603-127542981375_thumb.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.