| 18 | | |
| 19 | | == Encapsulation and Abstraction == |
| 20 | | |
| 21 | | '''Encapsulation''' |
| 22 | | |
| 23 | | Roughly speaking, encapsulation means ''Hiding''. It means you hide everything you can about an object and only reveal what others need to see. The purpose of hiding unnecessary information is that it gives all members of the transaction freedom from each other. |
| 24 | | |
| 25 | | Example: A computer subroutine that converts pressure from one system of units to another. |
| 26 | | |
| 27 | | Typically, a program that calls the subroutine only passes the data value to be converted, and receives back only the converted value. The calling program does not have to know the particular algorithm you use. This gives you the freedom to alter the algorithm. Perhaps you need to include a conversion factor that has more significant digits. If the calling program can't see the algorithm, you are free to change the algorithm any time you want. In fact, in this case, it is better for the calling program ''not'' to know the algorithm. |
| 28 | | |
| 29 | | An object has many representations. For instance, when an object is stored in a database, the database is a representation of the object. If the same object is stored in a second database, the representation might be completely different, perhaps because of different scopes of work, or different assumptions about the object. If you want to be able to move information between the two databases and you use special knowledge of the two, you create bindings. Your implementation will be fragile--any change to either database runs the risk of breaking the information transfer. But if you move the information in a way that does not depend on any special knowledge of the representations, your implementation will be robust. We say that the two databases each ''encapsulate'' the object. |
| 30 | | |
| 31 | | If you have anything less than full encapsulation, your cost of ownership will go up. This runs counter to typical thinking. Usually on an interoperability project, the computer programmers want to know as much as possible about the members of the information exchange. |
| 32 | | |
| 33 | | '''Abstraction''' |
| 34 | | |
| 35 | | Abstraction is the result of generalization of an object by reducing the information to only that which is relevent to a particular purpose. |
| 36 | | |
| 37 | | Example: A pump in a refinery has many representations: (See ''Encapsulation'', above.) |
| 38 | | |
| 39 | | * A very detailed drawing from the manufactuerer showing the baseplate and nozzle dimensions in great detail. |
| 40 | | * A plastic model. |
| 41 | | * A simple symbol on a P&ID. |
| 42 | | |
| 43 | | All of these representations are abstractions of one another. |
| 44 | | |
| 45 | | Example: Five Representations of a Car: |
| 46 | | |
| 47 | | 1. Give me one of these! [[Image(2010MustangGT.JPG, 100px)]] |
| 48 | | * 2010 |
| 49 | | * Ford |
| 50 | | * Mustang GT |
| 51 | | * Color Red |
| 52 | | 2. Give me a Ford car |
| 53 | | 3. Give me a car |
| 54 | | 4. Give me a vehicle with doors, windows, 4 wheels |
| 55 | | 5. Give me a vehicle |
| 56 | | |
| 57 | | Each of these representations is an abstraction of the previous one. Each one increases the abstraction. (Note that !#5 includes covered wagons and airplanes.) As you increase the level of abstraction you include more and more and will eventually include everything within it. |
| 58 | | |
| 59 | | '''Reference Data''' |
| 60 | | |
| 61 | | It appropriate at this point to bring in another idea, Reference Data. When you have to relate abstractions between two representations, you really need a third. (You can say that one of the representations is the abstract one, but usually leads to compromises you shouldn’t make.) You need a third that truly abstracts the two representations. If you increase the number of representations, it forces you to generalize that abstraction to cover all possible representations. |
| 62 | | Having a neutral representation of information is whole point of Reference Data. |
| 63 | | |
| 64 | | Reference data is not constrained by any storage method. |
| 65 | | |
| 66 | | By mapping several representations into abstract content, you achieve integration of information. If two or more representations map to one abstract content, those two representations are said to be related to each other. And having that abstraction enables you to achieve the encapsulation you want. |
| 67 | | |
| 68 | | How far do you go? Hmmm... There is an art to finding the Goldilocks point. Not too much. Not too little. Just right. |
| 69 | | |
| 70 | | Look at all the different storages you have of the information. You need a point of encapsulation. And that point of encapsulation is just some boundary that you put on that information on that system. Where you implement that point of encapsulation could be at any point. Could be right in the database. Could be on some programming API or a webservice, or a file. |
| 71 | | |
| 72 | | There are many ways to implement that point of encapsulation. Once you represent a specific representation into an abstracted one there’s the (??? Fine line third party???). What’s in there is just the information itself, but nothing about how it is stored, or location, what’s its schema is. |
| 73 | | |
| 74 | | Here is the mental picture: There are an infinite variety of representations, and there is a representation at every storage point of information, and every storage point needs to expose an abstracted representation that is understood by everybody else, and that abstracted representation is the point of encapsulation. |
| 75 | | |
| 76 | | The point of the abstraction is the encapsulation. Where ever you finally transform your representation into that 3rd party abstracted representation, that is the point of encapsulation. |
| 77 | | |
| 78 | | What’s left is purely the information you want to make public. Private information, schema, column names, table names, storage location path, all should remain private. You want freedom. You don't want nobody depending on that level of detail. |
| 79 | | |
| 80 | | Interestingly, we have a convergence of interests. We generally want to keep proprietary information secret. But this principle of encapsulation says that no one wants the proprietary information anyway, because if we use that proprietary knowledge in the data exchange, we are forever shackled by someone else’s proprietary thoughts. |
| 81 | | |
| 82 | | Most people violate this principle because its so much easier to violate it. It’s easier to connect systems together without encapsulation. The greatest offenders are the people in IT, because they are project-oriented. “What’s the easiest right now.” |
| 83 | | |
| 84 | | Benefit: Total control of what you publish |
| 85 | | Benefit: No one really even wants your proprietary information |
| 86 | | |
| 87 | | '''Abstraction''' |
| 88 | | |
| 89 | | You need abstraction to encapsulate. If you violate encapsulation, your costs go up. You violate interoperability. Most people don’t understand this. Most computer science geeks especially don’t understand this. |
| 90 | | |
| 91 | | The big leap forward with ISO 15926 is that is provided out of the box. |
| 92 | | |
| 93 | | |
| 94 | | == Interoperation and Integration == |
| 95 | | |
