Sample Question:

sdfsdfsf

JSR Notes:

As with 4.1.19, but even more so, this is focusing in on the "things" take on abstraction.

The real-world entity is the real-world entity. The abstraction is the representation of it. So our decomposition of ISB people into groups and sub-groups is the abstraction. Or the classes of a certain project are the abstraction of a larger real-world problem, which we needed to decompose. And the methods within certain classes are a further abstraction to group parts of the program that can be looked at and worked on via abstraction; i.e. ignoring the other details of the class/project.

 

---------------------------------

 

EXTRA - OF ALL THE EXTRAS, THIS IS THE MOST EXTRA; IT'S NOT SO IMPORTANT FOR US

From the linked video to this assessment statement, this can be looked at in a very straight-forward way; the sheep is the real-world entity, and the Sheep class, with attributes color, isForWool, and age is its ***particular*** abstraction.

But this is the one thing that it does makes sense to expand upon with this assessment statement a little: that an abstraction is a ***particular*** abstraction; an abstraction depends on the view-point. Because an abstraction is only a representation, or a model, of the real thing, and "unnecessary information" has been filtered away, there's an important question to ask: what unnecessary information has been filtered away? And the answer to that depends on the particular problem being addressed.

In the general example above of map and territory, much was seen as unnecessary; the only things seen as necessary were things like the shape of the territory, the roads, the street names of the territory, and perhaps some of the geographic features of the territory. But do a Google Maps search, and you'll come up with many, many different abstractions of the same territor. And you could argue that another abstraction of the territory might be a Wikipedia article on it. Same territory, very different abstraction of it.

Other examples besides the map example above:

• Various abstractions of a directory of a school staff
  • --> Done on the Internet to display experience and degrees earned, but not personal contact details
  • --> Intended for publication and internal distribution, with phone numbers and addresses
  • --> etc. though in this case there are only so many abstractions that make sense
• Various abstractions of a soccer league
  • --> Done in the form of souvenir collectors cards with pictures of the players on the front, and stats on the back
  • --> Done by an auditing firm to determining appropriate transfer caps
  • --> etc. etc. etc... any particular representation of certain parts of the soccer league

But the point of the examples above is that the real-world entities are the actual directory, with all details of each staff, or the whole actual soccer league; millions of pieces of information. But the abstractions were the particular filtered sets of data pulled from the overall data.

 

And getting back to the whole point of abstraction in the first place, don't worry about so much how you abstract a problem, worry, rather that you do. In other words, remember that the power of abstraction is the fact that we organized complex situations in a way that allows us to ignore much information for the time being and focus in on what we need to at the moment.