Where are these principles situated in the intellectual history of software development and computer science?
What empirical support is there to encourage their adoption?
How and when do we employ these principles in constructing software?
The intellectual tool that allows us to deal with concepts apart from particular instances of those concepts.(p. 139)
An abstraction denotes the essential characteristics of an object that distinguish it from all other objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.(p. 39)
Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details.
Abstraction, as an entity, denotes a model, a view or some other focused representation for an actual item. (p. 16)
The separation of the logical properties of data or function from their implementation. (p. 24)
In summary, abstraction allows us access to the relevant information regarding a problem, and ignores the remainder.
Abstraction is a technique to manage, and cope with, the complexity of the tasks we perform. The use of abstraction, both as a noun and a verb, allows us to
and
We create levels (hierarchies) of abstraction. Where abstractions at a particular level are rely on the abstractions from the lower level.
The spreadsheet would be implemented on top of a window system, which would in turn be implemented on top of an operating system and so on down (not very far) to the machine. The horizontal lines in the figure are commonly called "abstraction barriers," "abstractions" or "interfaces." Each provides useful functionality while hiding "implementation details" from the client above.
To the degree that an abstraction provides powerful, composable functionality, and is free of implementation issues, we call it "clean" or "elegant." In the particular case of the window system, the abstraction would provide the ability to make windows, arrange them on the screen, display in them, track the mouse etc. Issues such as how the windows are represented in memory and how the mouse is tracked would be hidden as implementation details. Kiczales (1992) p. 1
Modeling data from a specific context.
Collection of data elements and a corresponding set of accessing operations.
A specific representation of the structure and its accessing operations in a programming language.
Using the name of a sequence of instructions in place of the sequence of instructions.
Parameterization allows high level of flexibility in the performance of operations.
A named collection that describes a data object. Provides a logical reference to the data object without concern for the underlying representation.
A way of indicating the desired effect without establishing the actual mechanism of control. Allows designers to model iteration, nondeterminacy, concurrency, and synchronization (e.g., semaphore).
#(9 12 6 14 35 67 18) select: [:value|value event]
A logical view of the data objects together with specifications of the operations required to create and manipulate them.
| Operation | Description | Pascal |
|---|---|---|
| Create | Defines an identifier with an undefined value | VAR identifier:Integer |
| Assign | Assigns the value of one integer identifier or value to another integer identifier | id1:=id2 |
| IsEqual | returns true if the values (or values associated with identifiers) of the two integers are the same | id1=id2 |
| LessThan | returns true if the value of the first integer is less than the value of the second integer | id1<id2 |
| Negative | returns the negative of the integer value | -id1 |
| Sum | returns the sum of two integer values | id1+id2 |
| Signature |
|---|
| Create: identifier --> Integer |
| Assign: Integer --> Identifier |
| IsEqual: (Integer,Integer) --> Boolean |
| LessThan: (Integer,Integer) --> Boolean |
| Negative: Integer --> Integer |
| Sum: (Integer,Integer) --> Integer |
| Operation | Description |
|---|---|
| CreateList | returns a new empty list capable of holding a maximum number of items as specified by constant MaxSize |
| Concat | takes two lists as input data and joins the contents of the second list on the end of the first list to produce a single list |
| Append | takes an item and a list as input data and adds the item to the end of the list |
| Prepend | takes an item and a list as input data and adds the item to the front of the list |
| Head | takes a list as input data and produces the item at the front of the list |
| Tail | takes a list as input data and produces a list with the head item removed |
| Length | takes a list as input data and returns a natural number representing the number of items in the list |
| IsEmptyList | takes a list as input data and produces a true value when the list is empty |
| IsFullList | takes a list as input data and produces a true value when the list is full |
| Operation | Description |
|---|---|
| CreateString | returns a new emtpy string capable of holding MaxSize characters. |
| AssignString | copies the contents of a string or string variable into another string variable. |
| EqualString | returns a true if the two strings are equivalent |
| Length | returns the number of characters in a string |
| Pos | returns the position in a string where the first occurence of a substring begins |
| Concat | returns a string representing the combination of a series of strings |
| Copy | returns a string substring of a particular length beginning at a given position in an original string |
| Delete | returns a string after having removed a given number of characters beginning at a given position in the original string |
| Insert | returns a string with a string inserted beginning at a specified position |
| CreateString: --> String |
| AssignString: String --> String |
| EqualString: (String,String) --> Boolean |
| Length: String --> Natural Number |
| Pos: (String,String) --> Natural Number |
| Concat: (String1,String2,String3,...) --> String |
| Copy: (String, Natural Number, Natural Number) --> String |
| Delete: (String, Natural Number, Natural Number) --> String |
| Insert: (String, String, Natural Number) --> String |
| What do you think? |
|---|
Which code fragment below does not violate the abstraction principle? Assume all variables used are declared correctly. a.s1:='123*456'; for i:=1 to length(s1) do if s1[i]='*' then s1[i]='$'; b. s1:='123*456'; t1:=''; count:=0; for i:=1 to length(s1) do if NOT (s1[i]='*') then begin t1[count]:= s1[i]; count:=count+1 end; t1[0]:=count; s1:=t1; c. s1:='123*456';
t1:='';
place:=pos('*',s1);
t1:=copy(s1,1,place-1);
s1:=copy(s1,place+1,length(s1)-place);
insert(s1,t1,lenth(t1));
d. s1:='123*456';
t1:='';
place:=pos('*',s1);
t1:=copy(s1,1,place-1);
if place<>0 then begin
for i:=1 to length(s1)-place do
t1[length(t1)+i]:=s1[place+1+i];
if place<>0 then t1[0]:=length(s1)-1
end; |
PersonRecord = Record
Name:NameRecord;
HomeAddress:AddressRecord;
BusinessAddess:AddressRecord;
HomePhone:PhoneRecord;
BusinessPhone:PhoneRecord;
MaritalStatus:Status;
end {PersonRecord}
Modules should be characterized by design decisions that each hides from all others. Modules should be specified and designed so that information within a module is inaccessible to other modules that have no need for such information.
Partitioning a program into individual components which can be compiled separately, but which have connections with other modules. Fundamental the issue of modularity is what is contained in a module and what type/kind/quantity of connections.
Strategically, modularity is based on what we understand from research on problem solving. The idea is to take a large problem and decompose it into subproblems. The hope is the subproblems are easier to deal with than the original problem.
Modules are intended to package program functionality. Modules should localize program behavior. Modules are characterized as being highly cohesive, which implies all the items in the module are there to serve a single purpose (the purpose of the module). Modules are loosely coupled to the outside world, which means there are few connections.
Let C(x) be a function that defines the perceived complexity of a problem x, and let E(x) be a function that defines the effort (in time) required to solve problem x.
For problems P1 and P2, if C(P1) > C(P2) then E(P1) > E(P2).
(more complex problems take longer to solve).
Clearly,
C(P) = C(P1+P2) > C(P1) + C(P2)
and
E(P) = E(P1+P2) > E(P1) + E(P2)
1. Content Coupling: Two modules are content coupled if one module refers to or changes the internals of another module.
2. Common Coupling: Two modules are common coupled if they share the same global data areas.
3. Control Coupling: Two modules are control coupled if data from one is used to direct the order of instruction execution in the other.
4. Stamp Coupling: Two modules are stamp coupled if they communicate via a composite data item.
5. Data Coupling: Two modules are data coupled if they communicate via a variable or array that is passed directly as a parameter between the two modules. The data is used in problem related processing, not for program control purposes.
1. Functional: Each element in a module is a necessary and essential part of one and only one function.
2. Sequential: The elements of a module are related by performing different parts of a sequence of operations where the output of one operation is the input to the next.
3. Communicational: The elements of a module all operate on the same data.
4. Procedural: The elements of a module are all part of a procedure.
5. Temporal: The elements of a module are related by time but need not occur in a certain order or operate on the same data.
6. Logical: The elements of a module are all oriented toward performing a certain class of operations.
7. Coincidental: The elements of a module are essentially unrelated by any common function, procedure, data, or anything.
Go To Lecture [Outline] [Overview]
Go To [311 Course Outline] [CIS Department Page]
Aho, A. V. ∓ J. D. Ullman (1992) Foundations of Computer Science. New York: W. H. Freeman.
Berard, E. V. (1993) Essays on Object-Oriented Software Engineering. Englewood Cliffs, NJ: Prentice-Hall.
Booch, G. (1991) Object Oriented Design with Applications. Redwood City, CA: Benjamin Cummings.
Dale, N. & S. Lily (1995) Pascal Plus Data Structures, Algorithms, and Advanced Programming. Lexington, MA: DC Heath.
Fairley, R. E. (1985) Software Engineering Concepts. New York: McGraw-Hill.
Kiczales, G. (1992) Towards a New Model of Abstraction in the Engineering of Software. IMSA'92 Proceedings -Workshop on Reflection and Meta-level Architectures.