Wikipedia - Benutzerbeiträge [de]

Public light bus

2019-10-11T09:44:52Z

Libcub: /* Possible new fleet */ ce

{{Use Hong Kong English|date=December 2018}}
{{Use dmy dates|date=December 2018}}
{{Chinese|pic=MinibusDA9137,NT47M(3).jpg|piccap=A Green Minibus ('GMB')|c=公共小型巴士|p=Gōnggòng Xiǎoxíng Bāshì|y=Gūngguhng Síuyìhng Bāsí|j=Gung1gung6 Siu2jing4 Baa1si2|c2=小巴|p2=Xiǎobā|y2=Síubā|j2=Siu2baa1|showflag=y}}
[[Image:Newmininnustop.jpg|thumb|200px|A new style of minibus stops seen on [[Robinson Road, Hong Kong|Robinson Road]] in the [[Mid-levels]] of [[Hong Kong]]]]
The '''public light bus''' or minibus is a [[Public transport|public]] [[mode of transport|transport service]] in [[Hong Kong]]. It uses [[minibus]]es to serve areas that [[Buses in Hong Kong|standard Hong Kong bus lines]] cannot reach efficiently. The vehicles are colloquially known by the [[code-switching|code-switch]] ''{{lang|zh-hk|Van仔}}'' (Van Jái) literally "van-ette".

Minibuses carry a maximum of 19 seated passengers; no [[standing passenger]]s are allowed. Minibuses typically offer a faster and more efficient transportation solution due to their small size, limited carrying capacity, frequency and diverse range of routes, although they are generally slightly more expensive than standard buses. The popularity of minibus services in Hong Kong can be attributed to its high population density.

==Overview==
Minibuses in Hong Kong are licensed either as Green Minibuses (GMBs) or Public Light Buses (PLBs), the former restricted to fixed-fare, fixed-route operation, the latter not so restricted. PLBs substitute red for green on the external roof of the car, although originally the distinction was made by the colour of the stripe around the midsection of the vehicle. Otherwise, the two versions of minibus are identical in appearance, both sporting a predominantly cream-coloured body.

Most minibuses are [[Toyota Coaster]]s, but a new and environmentally friendly [[Iveco]] Daily Green minibus has also been introduced as part of one of the many recent schemes in Hong Kong to increase the quality of the buses. Most of the buses run on [[Autogas]] ([[liquefied petroleum gas]] or LPG). This type of fuel is not only cheaper, but also reduces emissions. The transport commission is making further efforts to reduce emissions by providing incentives for bus drivers to make the switch to even more efficient electric vehicles.

As of 2014, there were 4,350 public minibuses in Hong Kong, of which 3,150 were GMBs and 1,200 were PLBs. The operations of these two types of services are regulated through conditions imposed by the Commissioner for Transport under the passenger service licences (PSLs).<ref>{{cite web|url=http://www.td.gov.hk/en/transport_in_hong_kong/public_transport/minibuses/index.html|title=Transport Department - Minibuses|author=|date=|website=www.td.gov.hk}}</ref>

In response to public concerns about minibus speeding, from 2012, all public minibuses were required to install speed alarms activated at 80 km/h. On all public minibuses, a large digital speedometer must also be installed on the interior ceiling, adjacent to the driver's seat, facing passengers, enabling them to monitor the current speed.

==History==
The beginnings of public minibus service can be traced to a local minibus system ({{zh|t=黑牌車|cy=Hāakpáai chē}}) used in the [[New Territories]] before the 1960s. When, during the [[Hong Kong 1967 Leftist riots|1967 Hong Kong riots]], workers of the two main franchised public bus services, [[China Motor Bus]] and [[Kowloon Motor Bus]], went on [[Strike action|strike]] bringing buses and [[tram]]s to a halt,<ref name="scmp1">{{cite news|newspaper=South China Morning Post|url=http://www.scmp.com/portal/site/SCMP/menuitem.2af62ecb329d3d7733492d9253a0a0a0/?vgnextoid=89815d276fbec110VgnVCM100000360a0a0aRCRD&ss=Hong+Kong&s=News|title=''Riots in 1967 sparked service by van owners''|access-date=17 October 2008}}</ref> such services stepped in. One of the routes during the [[1967 Hong Kong riots]] was from [[Jordan Road Ferry Pier]] to [[Yuen Long]], which can be considered as the first minibus route in the [[New Territories]].<ref name=":0">{{Cite book|title=搭紅VAN : 從水牌說起 : 小巴的流金歲月|last=麥錦生|publisher=非凡出版|year=2018|isbn=9789888513475|location=香港|pages=54–57}}</ref> After 1967, they were allowed to operate in the urban areas of Hong Kong to ease commuter chaos.<ref name="ReferenceA">'''Since 1967: That Was Then (由1967開始) 1968-1969''', [[TVB]]</ref>

At the time people with mini-vans provided transport to the public for a small charge. The mini-vans were mainly servicing in the [[New Territories]] areas such as [[Yuen Long]], [[Sheung Shui]] and [[Fanling]], giving a shuttle bus service to the people living in the rural areas.<ref name=":0" /> The government turned a blind eye even though it was against traffic laws to carry passengers without a passenger service licence. The 1969 legislation legalising the service making some 5,000 licences available for drivers caused some controversy. Some believed it was wrong of the government to issue licences to people who had been profiting from an illegal activity.<ref name="scmp1" />

The first generation light buses were vans carrying nine passengers. The buses had a black and white chequered stripe and were colloquially referred to as '''zebra cars''' ({{zh|t=斑馬車|cy=Bāanmáh chē}}). The chequered stripe is the pattern still used by Lee On NT Taxi Co 利安的士公司 on its fleet of taxi.<ref name="ReferenceA"/><ref>{{cite web|url=http://paper.wenweipo.com/2009/04/18/FC0904180007.htm?hc_location%3Dufi |accessdate=April 10, 2015 |url-status=dead |archiveurl=https://web.archive.org/web/20150414032735/http://paper.wenweipo.com/2009/04/18/FC0904180007.htm?hc_location=ufi |archivedate=April 14, 2015 }}</ref> This design later gave way to the red-striped vans (colloquially, "red bus" or "14 seater"). Seating increased over the years from 9 to 14, then to 16 and, finally, to 19.<ref name="ReferenceA"/> The destination signage at the top front of minibuses did not appear until 1977 and the rear bench seat disappeared altogether with the prevalence of air-conditioning equipment installation.<ref name="ReferenceA"/>

==Usage==
A passenger wishing to take a minibus simply [[hail and ride|hails the minibus from the street kerb]] like a taxi. A minibus can generally be hailed down at any point along a route, subject to traffic regulations, although sometimes particular [[bus stop|stops]] are marked out. To alight from a minibus, a passenger customarily calls out to the driver where they wish to get off, drivers generally acknowledging by simply raising their hand. Tourists have difficulty with this system, as it generally requires both intimate local street knowledge and prior training in Cantonese. Passengers often call out [[landmarks]], intersecting streets and other distinctive features (such as immediately before or after a [[clearway|no-stopping zone]]). Green minibuses may have fixed stops. Some Green minibuses are now equipped with a bell operated similarly to those found on the larger buses, and ringing it indicates that a passenger wishes to alight at the next stop. Calling out to the driver, however, remains popular.

==Green minibuses==
[[File:UY6425(19 seats) Hong Kong Island 4M 10-08-2017.jpg|thumb|200px|A 19-seat green minibus]]
[[File:VF7558 Hong Kong Island 54M in Kennedy Town Station 26-01-2018.jpg|thumb|200px|A 19-seat [[low-floor]] green minibus]]
Green minibuses operate a scheduled service, with fixed routes and fixed fares. There are currently around 280 GMB buses routes with route numbers assigned. The exact fare must be tendered, or payment can be made by [[Octopus card]]. On some routes, passengers may pay a portion of the full fare (called section fare) if they are only travelling a section of the route. Sections are usually distinctive physical landmarks, such as crossing a [[tunnel]] or a [[bridge]].

==Red minibuses==
[[Image:Rmb le9372.jpg|thumb|200px|A red Public Light Bus]]
Red minibuses (PLBs) are a kind of [[share taxi]], which run a non-scheduled service, although routes may, in effect, become fixed over time. PLBs may operate anywhere where no special prohibitions apply, without control over routes or fares. The PLB system is intended to be flexible and responsive to market demand.

On some routes PLBs may run throughout the day (24-hour service), such as [[Tai Po]]-Mong Kok, [[Tsuen Wan]]-[[Kwun Tong]], Kwun Tong-[[Mong Kok]], [[Yuen Long]]-[[Jordan Road, Hong Kong|Jordan Road]], etc. Other routes may only run as midnight services, such as from Yuen Long-[[Causeway Bay]], taking over, higher-capacity services, such as franchised bus operators or mass transit railway underground, close.

In most PLBs, passengers pay just before they alight. Though change for cash payment may be available, a small amount may be deducted by the driver for the inconvenience of handling it. Only a few of these red minibuses are equipped to accept payment by Octopus card. Fares and timetables are not regulated by the Government. Thus, at times, PLBs may be more expensive than GMBs.

Destinations displayed on PLBs are sometimes identified by landmarks long gone, such as [[Daimaru]] ({{zh|c=大丸}}) in Causeway Bay, the defunct department store. The numbers they display are a legacy of the pre-1973 route-numbering in the New Territories, being the same route numbers used by the large franchised bus operators.

==Fleet==
[[File:VL4102 at NWFB West Kowloon Depot, Hing Wah St W (20190301162413).jpg|thumb|right|250px|The newest Toyota LPG Coaster (19 seats)]]

Most early public light buses used mostly [[United Kingdom|British]] vehicles and carried few passengers as they were vans converted as buses. A few non-British European buses emerged but [[Japan]]ese minibuses appeared in 1969 and finally dominated the fleet by the 1980s.

* [[Morris Commercial J2|Morris J Type]] 12 seater - 1960s
* [[Bedford CA]] - 1960s
* [[Ford Transit|Ford Transit Mk I (1965-1978)]] 9 and 12 seaters - 1970s
* [[Toyota Coaster]] (both LPG and diesel)
* [[Iveco Daily]] (introduced in 2004 but all retired)
* [[Mercedes-Benz Sprinter]] 311 (all retired)
* [[Mitsubishi Fuso Rosa]] (Currently only Green Minibus)
* [[Nissan Civilian]] (all retired 1990s)
* [[Nissan Echo]] (all retired and replaced by Civilian in the 1980s)
* [[Optare Solo]]

==Possible new fleet==
Some Green Minibus Unions have called for the Government to provide a new fleet of buses which can hold up to 20 people, 4 more people than the current 16 people. They say it could help ease traffic congestion during rush hour and possibly push up profits which may turn away possible fare increases. There are a few of the new buses in service at the moment, but because it is only legal to have 16 passengers in a minibus, the extra area is used as a luggage rack. The Government has responded saying that it would be prudent to first study the implications of such expansion in the context of a Public Transport Strategy Study first, which should take two years ending in 2017 or 2018.<ref>{{cite web|url=http://www.info.gov.hk/gia/general/201411/25/P201411250654.htm|title=TAC welcomes Government's plan to commence Public Transport Strategy Study|author=|date=|website=www.info.gov.hk}}</ref>

==Cultural references==
In the film ''[[Lost in Time (film)|Lost In Time]]'', [[Cecilia Cheung]] playing the role as a red minibus driver, won the "Best Actress" Awards in the [[23rd Hong Kong Film Awards|2004 Hong Kong Film Awards]].

==See also==
* [[Buses in Hong Kong]]
* [[Marshrutka]]
* [[Share taxi]], for more international equivalents to public light buses
* [[Transport in Hong Kong]]
* [[Van]]

==References==
{{reflist}}

==External links==
{{commons category|Minibuses in Hong Kong}}
* [http://www.hktpa.org/ Hong Kong Taxi & PLB Association]
* [https://web.archive.org/web/20061107085147/http://gmb.681busterminal.com/ Hong Kong Green Light Bus Guide]
* [http://www.amspt.com/ AMS Public Transport Holdings Limited]
* [https://web.archive.org/web/20100113231659/http://www.td.gov.hk/en/transport_in_hong_kong/public_transport/minibuses/green/gmb_online_guide/index.html List of Green Light Bus Routes by Territory]

{{Bus companies of Hong Kong}}
{{Public transport}}
{{Hong Kong topics}}
{{Authority control}}

[[Category:Bus transport in Hong Kong]]
[[Category:Restricted areas of Hong Kong red public minibus| 01]]

Cyntoia Brown

2018-12-21T02:37:17Z

Libcub: /* Early life */ npov

{{Infobox criminal
| name = Cyntoia Brown
| image =
| caption = Brown's mugshot.
| birth_name = Cyntoia Denise Mitchell
| birth_date = {{Birth date and age|1988|1|29}}
| birth_place = [[Tennessee]], U.S.
| death_date =
| death_place =
| cause =
| alias =
| height =
| weight =
| sentence = 51 years to [[life imprisonment]]
| conviction = [[Murder]]
| victims = 1
| beginyear =
| country =
| states =
| endyear =
| apprehended =
| imprisoned = [[Tennessee Prison for Women]]
}}
'''Cyntoia Denise Brown''' ([[Name at birth|née]] '''Mitchell'''; born January 29, 1988) is a woman who, at the age of 16, was convicted of murder in a controversial case. Her story is detailed in ''[[Me Facing Life: Cyntoia's Story]]'', a 2011 documentary by filmmaker Dan Birman.

== Early life ==
Brown was born Cyntoia Denise Mitchell to Georgina Mitchell in Tennessee on January 29, 1988.<ref>{{Cite web|url=https://apps.tn.gov/foil-app/results.jsp|title=Search Results - Tennessee Felony Offender Information|website=apps.tn.gov|access-date=2018-12-10}}</ref> Her father is unknown. Mitchell [[Alcohol and pregnancy|drank alcohol during her pregnancy]], which Brown's defense attorneys would later claim to have caused her to have been born with [[fetal alcohol spectrum disorder]],<ref>{{Cite web|url=https://www.rollingstone.com/politics/politics-news/cyntoia-brown-766645/|title=Cyntoia Brown, Sentenced at 16, Must Serve 51 Years Before She Is Eligible for Release|last=Wade|first=Peter|last2=Wade|first2=Peter|date=2018-12-09|website=Rolling Stone|language=en-US|access-date=2018-12-10}}</ref> and, after Brown was born, Mitchell began to use [[crack cocaine]].<ref>{{Cite news|url=https://www.bbc.com/news/world-us-canada-42079257|title=Rihanna and Kim K back teenaged killer|last=Seales|first=Rebecca|date=2017-11-22|work=BBC News|access-date=2018-12-10|language=en-GB}}</ref> Unable to care for her infant daughter, Georgina ultimately placed the child up for [[adoption]] by Ellenette Brown, also known as Ellenette Washington.<ref>{{Cite web|url=https://www.leagle.com/decision/intnco20090420273|title=STATE v. BROWN {{!}} No. M2007-00427-CCA-R3-CD. {{!}} 20090420273 {{!}} Leagle.com|website=Leagle|language=en|access-date=2018-12-10}}</ref> Though Washington tried to provide a stable home for Cyntoia in 2004, the latter, then 16-years-old, ran away from home and began associating with a man named Garion McGlothen, also known by his street name Kut-Throat or simply Kut, who would become her pimp and force her into sex-trafficking. Homeless, the two took up residence at an [[InTown Suites]], with Brown supporting the two of them through involuntary [[prostitution]].<ref>{{Cite web|url=https://theappeal.org/not-a-cardboard-cut-out-cyntoia-brown-and-the-framing-of-a-victim-aa61f80f9cbb/|title=Not A Cardboard Cut Out: Cyntoia Brown and the Framing of a Victim|website=The Appeal|language=en|access-date=2018-12-10}}</ref> During this time, McGlothen reportedly threatened, beat, and raped Brown on multiple occasions.<ref>{{Cite web|url=https://www.yahoo.com/lifestyle/11-awful-details-cyntoia-brown-074243618.html|title=11 Awful Details About Cyntoia Brown, The 16-Year-Old Sex Trafficking Victim Serving A Life Sentence For Killing The Man Who 'Bought' Her|website=www.yahoo.com|language=en-US|access-date=2018-12-10}}</ref>

== State of Tennessee v. Cyntoia Denise Brown ==

=== Murder of Johnny Allen ===
On the night of August 6, 2004, Brown, then 16-years-old, met Johnny Mitchell Allen, a 43-year-old [[real estate broker]] and [[United States Army]] veteran, in the parking lot of a [[Sonic Drive-In]] on Murfreesboro Road in [[Nashville, Tennessee]], a known [[red-light district]].<ref>{{Cite web|url=https://www.yourtango.com/2017308682/who-cyntoia-brown-facts-details-teen-sex-trafficking-life-prison-killing-pimp|title=11 Awful Details About Cyntoia Brown, The 16-Year-Old Sex Trafficking Victim Serving A Life Sentence For Killing The Man Who 'Bought' Her|date=2017-11-23|website=YourTango|language=en|access-date=2018-12-10}}</ref> Brown agreed to have sex with Allen for the price of $150 USD; the two ordered dinner and Allen drove the two of them to his home on Mossdale Road.<ref>{{Cite web|url=https://www.leagle.com/decision/intnco20090420273|title=STATE v. BROWN {{!}} No. M2007-00427-CCA-R3-CD. {{!}} 20090420273 {{!}} Leagle.com|website=Leagle|language=en|access-date=2018-12-10}}</ref> At some point during the evening, Brown shot Allen in the back of his head while he was sleeping with a .40-caliber [[handgun]] she carried on her person and stole from Allen's residence $172 USD in cash, several firearms, and a vehicle, a [[Ford F150]].<ref>{{Cite web|url=https://www.endslaverytn.org/news/kim-k-rihanna-and-cara-delevingne-demand-justice|title=DAILY MAIL UK: Kim K, Rihanna and Cara Delevingne demand justice for teenage sex slave who has spent 13 years in jail after she shot dead her abuser and was sentenced to LIFE in prison|website=End Slavery Tennessee|language=en-US|access-date=2018-12-10}}</ref><ref>{{Cite web|url=https://www.foxnews.com/us/tennessee-parole-board-divided-over-release-in-murder-case|title=Tennessee Parole Board divided over release in murder case|date=2018-05-23|website=Associated Press|language=en-US|access-date=2018-12-10}}</ref> She then drove Allen's vehicle to InTowne Suites, to meet her pimp.

=== Arrest and trial ===
Brown was arrested and charged with one count of premeditated murder, one count of murder, and one count of aggravated robbery. Despite being under 18, she was tried as an adult. In her statements to police, Brown initially claimed she'd acted in [[self-defense]] but forensic evidence showed that Allen had been asleep and shot in the head from behind at the time of his death. Additionally, Brown admitted to stealing Allen's cash and property and expressed her intention to pawn the stolen rifles.<ref>{{Cite web|url=https://www.leagle.com/decision/intnco20090420273|title=STATE v. BROWN {{!}} No. M2007-00427-CCA-R3-CD. {{!}} 20090420273 {{!}} Leagle.com|website=Leagle|language=en|access-date=2018-12-10}}</ref> Prosecutors ultimately took the stance that Brown had not been in danger and that she'd murdered Allen in order to steal from him.<ref>{{Cite web|url=https://www.cnn.com/2017/11/23/us/cyntoia-brown-social-media-murder-case-trnd/index.html|title=Why Cyntoia Brown, who is spending life in prison for murder, is all over social media|last=Willingham|first=AJ|date=Nov 27, 2017|website=CNN|archive-url=|archive-date=|dead-url=|access-date=Dec 10, 2018}}</ref> Ultimately, she was found guilty of murder and sentenced to 51 years to life in prison.<ref>{{Cite web|url=https://www.cnn.com/2018/12/07/us/cyntoia-brown-prison-release/index.html|title=Cyntoia Brown must serve 51 years before she's eligible for release, Tennessee Supreme Court says|last=Andone|first=Dakin|date=Dec 8, 2018|website=CNN|archive-url=|archive-date=|dead-url=|access-date=Dec 10, 2018}}</ref>

=== Aftermath ===
Brown is currently serving her sentence at the [[Tennessee Prison for Women]], a maximum security detention facility in [[Nashville, Tennessee]].<ref>{{Cite web|url=https://www.tennessean.com/story/news/crime/2018/12/06/cyntoia-brown-update-release-tennessee-supreme-court/2228517002/|title=Cyntoia Brown can be released after serving 51 years in prison, Tennessee Supreme Court decides|last=Alund|first=Natalie Neysa|website=The Tennessean|language=en|access-date=2018-12-10}}</ref> She will be eligible for [[parole]] when she is 67 years old.<ref>{{Cite web|url=https://www.colorlines.com/articles/how-support-cyntoia-brown|title=How to Support Cyntoia Brown|last=Byrd|first=Ayana|date=2018-12-10|website=Colorlines|language=en|access-date=2018-12-10}}</ref>

Brown's former pimp, Garion L. McGlothen, also known as Gary McGlothen and Kutthroat, died on March 30, 2005, at the age of 24, having been shot and killed by a man named Quartez Hines.<ref>{{Cite news|url=https://www.highbeam.com/doc/1P3-1095461781.html|title=Quartez Hines Charged with 2005 Murder|date=2006-08-14|work=US Fed News Service, Including US State News|access-date=2018-12-10|language=en}}</ref><ref>{{Cite web|url=https://www.chattanoogan.com/2006/9/20/93192/Officer-Lydell-Blue-Honored-By-The.aspx|title=Officer Lydell Blue Honored By The Exchange Club|website=www.chattanoogan.com|language=en|access-date=2018-12-10}}</ref>
Brown's story was featured in the 2011 documentary, ''[[Me Facing Life: Cyntoia's Story]]''.
=== Parole and Clemency Hearings===

=== Tennessee Supreme Court ===
On December 6th, 2018 The Tennessee Supreme Court issued a ruling on Cyntoia Brown's case, stating that she would be eligible for parole after serving 51 years. <ref>{{cite news |title=TN Supreme Court Rules Cyntoia Brown Must Serve 51 Years Before Parole Eligibility |url=https://www.localmemphis.com/news/local-news/tn-supreme-court-rules-cyntoia-brown-must-serve-51-years-before-parole-eligibility/1652925717 |accessdate=11 December 2018 |work=Tennessean |date=11 December 2018}}</ref><ref>{{cite news |last1=Andone |first1=Dakin |title=Cyntoia Brown must serve 51 years before she's eligible for release, court says |url=https://www.cnn.com/2018/12/07/us/cyntoia-brown-prison-release/ |accessdate=11 December 2018 |work=Cable News Network |publisher= Turner Broadcasting System, Inc. |date=6 December 2018}}</ref>

== Renewed media attention ==
In 2018, several celebrities, notably [[Kim Kardashian]], [[Rihanna]], and [[Cara Delevingne]] took an interest in Brown's case and took to social media to raise awareness about her case.<ref>{{Cite web|url=https://www.endslaverytn.org/news/kim-k-rihanna-and-cara-delevingne-demand-justice|title=DAILY MAIL UK: Kim K, Rihanna and Cara Delevingne demand justice for teenage sex slave who has spent 13 years in jail after she shot dead her abuser and was sentenced to LIFE in prison|website=End Slavery Tennessee|language=en-US|access-date=2018-12-10}}</ref>

==References==
{{Reflist}}

[[Category:People convicted of murder by Tennessee]]
[[Category:1988 births]]

Flughafen Fernando de Noronha

2014-07-10T07:27:59Z

Libcub: /* top */ ce

{{Infobox airport
| name = Governador Carlos Wilson Airport
| nativename = ''Aeroporto Governador Carlos Wilson''
| nativename-a =
| nativename-r =
| image =
| image-width =
| caption =
| IATA = FEN
| ICAO = SBFN
| LID =
| GPS =
| WMO =
| type = Public
| owner-oper =
| owner =
| operator =
| city-served = [[Fernando de Noronha]]
| location =
| hub =
| metric-elev = yes
| elevation-f = 190
| elevation-m = 58
| website =
| latd = 03 | latm = 51 | lats = 17 | latNS = S
| longd= 032 | longm= 25 | longs= 42 | longEW= W
| coordinates_type =
| coordinates_region = BR
| coordinates_notitle =
| pushpin_map = South Atlantic
| pushpin_label_position =
| pushpin_label = FEN
| pushpin_map_alt =
| pushpin_mapsize =
| pushpin_image =
| pushpin_map_caption = Location off the Atlantic coast of Brazil
| metric-rwy = yes
| r1-number = 12/30
| r1-length-f = 6,053
| r1-length-m = 1,845
| r1-surface = [[Asphalt]]
| stat-year =
| stat1-header = Passengers
| stat1-data =
| stat2-header = Aircraft Operations
| stat2-data =
| stat3-header = Metric [[tonne]]s of cargo
| stat3-data =
| footnotes = Sources: World Aero Data,<ref>{{cite web | url=http://worldaerodata.com/wad.cgi?id=BR50076&sch=SBFN | title=Fernando de Noronha Airport Information | publisher=World Aero Data}}</ref> [[National Civil Aviation Agency of Brazil|ANAC]]<ref>{{cite web | url=http://www2.anac.gov.br/arquivos/pdf/aerodromos/AerodromosPublicos.xls | title=Lista de aeródromos públicos | publisher=ANAC | language=Portuguese}}</ref>
}}

'''Gov. Carlos Wilson Airport''' {{airport codes|FEN|SBFN}} is the airport serving the island of [[Fernando de Noronha]], [[Brazil]]. It is the easternmost airport of [[Brazil]] and the only one that is located in the [[Brazil]]ian [[Island#Oceanic islands|oceanic islands]].

==History==
Fernando de Noronha is the biggest island of the archipelago with the same name, located in Brazilian territorial waters, {{convert|545|km|0|abbr=on}} away from [[Recife]] and {{convert|360|km|0|abbr=on}} away from [[Natal, Rio Grande do Norte|Natal]].

The first runway was built in 1934. In 1942, during [[World War II]], the runway was extended and a passenger terminal was built by the [[United States Army Air Forces]] [[Air Transport Command (United States Air Force)|Air Transport Command]] under the Airport Development Program. It provided technical support for the [[Natal, Rio Grande do Norte|Natal]]-[[Dakar]] air route, which provided a transoceanic link between [[Brazil]] and [[French West Africa]] for cargo, transiting aircraft and personnel.

The airport was transferred to the jurisdiction of the [[United States Navy]] on 5 September 1944.<ref>{{Cite web | url=http://airforcehistoryindex.org/data/000/001/957.xml | title=Document Detail for IRISNUM 00001957 | publisher=Air Force History Index | date=18 May 1982 | accessdate=October 20, 2010}}</ref> After the end of the war, the administration of the airport was transferred back to the Brazilian Government.

In 1975 another extension of the runway was made, allowing the operations of aircraft up to the class of a [[Boeing 737]]. In March 1999, the present passenger terminal was opened for service.

Following the disappearance of [[Air France Flight 447]] on June 1, 2009, the airport became a base for search and rescue operations. The flight was en route from [[Rio de Janeiro-Galeão International Airport|Rio de Janeiro-Galeão]] to [[Charles de Gaulle Airport|Paris-Charles de Gaulle]] when it disappeared in the Atlantic Ocean approximately {{convert|550|km|0|abbr=on}} northeast of Fernando de Noronha.<ref>{{Cite web | url=http://oglobo.globo.com/economia/buscas-as-vitimas-do-voo-447-serao-ampliadas-em-aguas-do-senegal-3194579 | title=Buscas às vítimas do voo 447 serão ampliadas em águas do Senegal | publisher=Valor Econômico | date=June 10, 2009 | accessdate=April 11, 2013 | language=Portuguese}}</ref>

==Airlines and destinations==
{{Airport-dest-list
|[[Azul Brazilian Airlines]] operated by [[TRIP Linhas Aéreas]] | [[Santa Maria Airport (Sergipe)|Aracaju]], [[Tancredo Neves International Airport|Belo Horizonte-Confins]], [[Greater Natal International Airport|Natal-São Gonçalo]], [[Recife Airport|Recife]], [[Guarulhos International Airport|São Paulo]], [[Santos Dumont Airport|Rio de Janeiro-Santos Dumont]], [[Deputado Luís Eduardo Magalhães International Airport|Salvador da Bahia]]
|[[Gol Transportes Aéreos|Gol Airlines]] | [[Recife Airport|Recife]]
}}

==Accidents and incidents==
*14 December 1987: a [[Brazilian Air Force]] [[C-130 Hercules|Lockheed C-130H Hercules]] registration FAB-2468 flying from [[Recife Airport|Recife]] to Fernando de Noronha crashed into the sea shortly before landing. All 29 crew and passengers died.<ref>{{Cite web | url=http://aviation-safety.net/database/record.php?id=19871214-2 | title=Accident description FAB-2468 | publisher=Aviation Safety Network | accessdate=May 20, 2011}}</ref>
*20 September 1990: an [[Embraer EMB 110 Bandeirante|Embraer EMB110P1 Bandeirante]] registration PT-PAW belonging to the [[Pernambuco|Government of Pernambuco]] flying from Fernando de Noronha to [[Recife Airport|Recife]] crashed into the sea shortly after take-off. All 12 crew and passengers died.<ref>{{Cite web | url=http://aviation-safety.net/database/record.php?id=19900920-2 | title=Accident description PT-FAW | publisher=Aviation Safety Network | accessdate=May 20, 2011}}</ref>

==Access==
The airport is located {{convert|4|km|0|abbr=on}} from Vila dos Remédios, the administrative center of the island.

==See also==
{{Portal|Aviation|Brazil}}
*[[List of the busiest airports in Brazil]]

==References==
{{reflist}}

==External links==
*{{WAD|SBFN|source=[[DAFIF]]}}
*{{GCM|SBFN|source=[[DAFIF]]}}
*{{NWS-current|SBFN}}
*{{ASN|FEN}}
*[http://www.airliners.net/search/photo.search?aircraft_genericsearch=&airlinesearch=&countrysearch=&specialsearch=airport&keywords=fernando+de+noronha&sort_order=photo_id+desc&page_limit=15&daterange=&range=&thumbnails=&engine_version=6.0 Fernando de Noronha Photo Archive at airliners.net]

{{List of airports}}
{{Aviation lists}}
{{Brazil topics}}

[[Category:Airports in Pernambuco]]
[[Category:Airports established in 1934]]

Mount Baker National Recreation Area

2012-09-16T21:29:38Z

Libcub: updated link

{{Infobox protected area
| name = Mount Baker National Recreation Area
| iucn_category = V
| photo =
| photo_caption =
| map = USA relief
| map_caption =
| location = [[Whatcom County, Washington]], [[USA]]
| nearest_city = [[Concrete, Washington]]
| lat_d = 48 | lat_m = 47 | lat_s = 03 | lat_NS = N
| long_d = 121 | long_m = 45 | long_s = 53 | long_EW = W
| region = US
| coords_ref =
| area = 8,473 acres (34.29 km<sup>2</sup>)
| established = July 3, 1984
| visitation_num =
| visitation_year =
| governing_body = [[United States Forest Service]]
}}
'''Mount Baker National Recreation Area''' is a [[United States]] [[National Recreation Area]] located in northern [[Washington (U.S. state)|Washington]] about 15 miles south of the [[United States-Canada border|Canadian border]] within the [[Mount Baker-Snoqualmie National Forest]].

The recreation area was established in 1984 by an act of the [[U.S. Congress]] primarily to accommodate the use of [[snowmobiles]] during the [[winter]] months on the southern slopes of [[Mount Baker]]. There are also many hiking trails in the recreation area. Mount Baker NRA is adjacent to the [[Mount Baker Wilderness]] area where snowmobiling is not permitted.

==External links==
* [http://www.fs.usda.gov/recarea/mbs/recreation/recarea/?recid=30330&actid=51 Mount Baker National Recreation Area official site]

{{USNRAs}}
{{Protected Areas of Washington}}

[[Category:National Recreation Areas of the United States]]
[[Category:Protected areas of Washington (state)]]
[[Category:Protected areas of Whatcom County, Washington]]
[[Category:Mount Baker-Snoqualmie National Forest]]

{{Washington-protected-area-stub}}
{{WhatcomWA-geo-stub}}

[[cs:Národní rekreační oblast Mount Baker]]

Air Canada Tango

2012-05-15T20:42:19Z

Libcub: ce

{{original research|date=October 2010}}
{{refimprove|date=October 2010}}

{{Infobox Airline
| airline = Air Canada Tango
| image = Air Canada Tango logo.svg
| image_size =
| IATA = AC
| ICAO = ACA
| callsign =
| founded = 2001
| commenced =
| ceased = 2003
| hubs =
| secondary_hubs =
| focus_cities =
| frequent_flyer =
| lounge =
| alliance =
| subsidiaries =
| fleet_size =
| destinations =
| parent = [[Air Canada]]
| company_slogan =
| headquarters = [[Montreal]], [[Quebec]]
| key_people =
| website = [http://web.archive.org/web/*/http://www.flytango.com Flytango.com]
}}
'''Air Canada Tango''' was a [[Low-cost carrier|low-cost]] branch of [[Air Canada]], which was established in 2001 to offer [[no-frills]] service on some of Air Canada's routes and to reduce operating costs at the struggling main company. Based in [[Toronto]], Tango operated on the major longer-distance Canadian routes between cities such as Toronto, [[Ottawa]], [[Montreal]], [[Calgary, Alberta|Calgary]] and [[Vancouver]], as well as to some holiday destinations in the [[United States|USA]] and Mexico such as [[Fort Lauderdale, Florida|Fort Lauderdale]], [[Tampa, Florida|Tampa]] and [[Mexico City]].

The airline's name is short for "Tan and Go", which is in reference to the southern winter destinations that were initially planned to be served.

==Fleet==
[[File:Air Canada Tango A320.jpg|thumb|left|[[Airbus A320]]]]
[[File:Air Canada Tango 737-217Adv.jpg|thumb|left|[[Boeing 737-200]]]]
The fleet of Air Canada Tango consisted of up to 13 [[Airbus A320]] and (from 2002) up to 6 [[Boeing 737-200]].<ref>[http://www.planespotters.net/Airline/Air-Canada-Tango#AirlineFleetList Tango fleet list at planespotters.net]</ref>

Air Canada Tango aircraft were configured in a full [[economy class]] layout rather than with a [[business class]] section as on regular Air Canada aircraft and featured a distinctive purple colour scheme.

==References==
{{reflist}}

==External links==
{{commons category}}
* [http://web.archive.org/web/*/http://www.flytango.com Official website] at the [[Wayback Machine]]

{{Defunct airlines of Canada}}

[[Category:Defunct low-cost airlines]]
[[Category:Defunct airlines of Canada]]
[[Category:Airlines established in 2001]]
[[Category:Airlines disestablished in 2003]]
[[Category:Low-cost airlines]]

[[fr:Air Canada]]

Abstraktion (Informatik)

2011-02-11T18:30:40Z

Libcub: /* Abstraction in object oriented programming */ rv vandalism

In [[computer science]], '''abstraction''' is a concept that reduces the behavior of an object to the lowest common denominator.

The following English definition of abstraction helps to understand how this term applies to computer science, IT and objects:

: ''abstraction - a concept or idea not associated with any specific instance''<ref>[http://www.thefreedictionary.com/abstraction Thefreedictionary.com]</ref>

The concept originated by analogy with [[abstraction (mathematics)|abstraction]] in [[mathematics]]. The mathematical technique of abstraction begins with mathematical [[definition]]s; this has the fortunate effect of finessing some of the vexing philosophical issues of [[abstraction]]. For example, in both computing and in mathematics, [[number]]s are concepts in the [[programming language]]s, as founded in mathematics. Implementation details depend on the hardware and software, but this is not a restriction because the computing concept of number is still based on the mathematical concept.

In [[computer programming]], abstraction can apply to control or to data: '''Control abstraction''' is the abstraction of actions while '''data abstraction''' is that of data structures.

* Control abstraction involves the use of [[subprogram]]s and related concepts [[control flow]]s
* Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind [[datatype]].

One can regard the notion of an [[object (computer science)|object]] (from [[object-oriented programming]]) as an attempt to combine abstractions of data and code.

The recommendation that programmers use abstractions whenever suitable in order to avoid duplication (usually [[code duplication|of code]]) is known as the [[abstraction principle (programming)|abstraction principle]]. The requirement that a programming language provide suitable abstractions is also called the abstraction principle.

==Rationale==
Computing mostly operates independently of the concrete world: The hardware implements a [[model of computation]] that is interchangeable with others. The software is structured in [[software architecture|architecture]]s to enable humans to create the enormous systems by concentration on a few issues at a time. These architectures are made of specific choices of abstractions. [[Greenspun"s Tenth Rule]] is an [[aphorism]] on how such an architecture is both inevitable and complex.

A central form of abstraction in computing is language abstraction: new artificial languages are developed to express specific aspects of a system. ''[[Modeling languages]]'' help in planning. ''[[Computer language]]s'' can be processed with a computer. An example of this abstraction process is the generational development of [[programming language]]s from the [[First-generation programming language|machine language]] to the [[Second-generation programming language|assembly language]] and the [[Third-generation programming language|high-level language]]. Each stage can be used as a stepping stone for the next stage. The language abstraction continues for example in [[scripting language]]s and [[domain-specific programming language]]s.

Within a programming language, some features let the programmer create new abstractions. These include the [[subroutine]], the [[module (programming)|module]], and the [[software component]]. Some other abstractions such as [[software design pattern]]s and [[software architecture#Architecture examples|architectural styles]] remain invisible to a programming language and operate only in the design of a system.

Some abstractions try to limit the breadth of concepts a programmer needs by completely hiding the abstractions they in turn are built on. [[Joel Spolsky]] has criticised these efforts by claiming that all abstractions are ''[[leaky abstraction|leaky]]'' — that they can never completely hide the details below; however this does not negate the usefulness of abstraction. Some abstractions are designed to interoperate with others, for example a programming language may contain a [[foreign function interface]] for making calls to the lower-level language.

==Language features==
===Programming languages===
{{Main|Programming language}}

Different programming languages provide different types of abstraction, depending on the intended applications for the language. For example:

* In [[object-oriented programming language]]s such as [[C++]], [[Object Pascal]], or [[Java (programming language)|Java]], the concept of '''abstraction''' has itself become a declarative statement - using the [[keyword (computer programming)|keyword]]s ''<code>virtual</code>'' (in [[C++]]) or ''<code>abstract</code>'' (in [[Java (programming language)|Java]]). After such a declaration, it is the responsibility of the programmer to implement a [[Class (computer science)|class]] to instantiate the [[Object (computer science)|object]] of the declaration.
* [[Functional programming language]]s commonly exhibit abstractions related to functions, such as [[lambda abstraction]]s (making a term into a function of some variable), [[higher-order function]]s (parameters are functions), [[bracket abstraction]] (making a term into a function of a variable). 

===Specification methods===
{{Main|Formal specification}}

Analysts have developed various methods to formally specify software systems. Some known methods include:

* Abstract-model based method (VDM, Z);
* Algebraic techniques (Larch, CLEAR, OBJ, ACT ONE, CASL);
* Process-based techniques (LOTOS, SDL, Estelle);
* Trace-based techniques (SPECIAL, TAM);
* Knowledge-based techniques (Refine, Gist).

===Specification languages===
{{Main|Specification language}}

Specification languages generally rely on abstractions of one kind or another, since specifications are typically defined earlier in a project (and at a more abstract level) than an eventual implementation. The [[Unified Modeling Language|UML]] specification language, for example, allows the definition of ''abstract'' classes, which remain abstract during the architecture and specification phase of the project.

==Control abstraction==
{{Main|Control flow}}

Programming languages offer control abstraction as one of the main purposes of their use. Computer machines understand operations at the very low level such as moving some bits from one location of the memory to another location and producing the sum of two sequences of bits. Programming languages allow this to be done in the higher level. For example, consider this statement written in a [[Pascal (programming language)|Pascal]]-like fashion:

:<code>a := (1 + 2) * 5</code>

To a human, this seems a fairly simple and obvious calculation (''"one plus two is three, times five is fifteen"''). However, the low-level steps necessary to carry out this evaluation, and return the value "15", and then assign that value to the variable "a", are actually quite subtle and complex. The values need to be converted to binary representation (often a much more complicated task than one would think) and the calculations decomposed (by the compiler or interpreter) into assembly instructions (again, which are much less intuitive to the programmer: operations such as shifting a binary register left, or adding the binary complement of the contents of one register to another, are simply not how humans think about the abstract arithmetical operations of addition or multiplication). Finally, assigning the resulting value of "15" to the variable labeled "a", so that "a" can be used later, involves additional 'behind-the-scenes' steps of looking up a variable's label and the resultant location in physical or virtual memory, storing the binary representation of "15" to that memory location, etc.

Without control abstraction, a programmer would need to specify ''all'' the register/binary-level steps each time he simply wanted to add or multiply a couple of numbers and assign the result to a variable. Such duplication of effort has two serious negative consequences:

# it forces the programmer to constantly repeat fairly common tasks every time a similar operation is needed
# it forces the programmer to program for the particular hardware and instruction set

===Structured programming===
{{Main|Structured programming}}

Structured programming involves the splitting of complex program tasks into smaller pieces with clear flow-control and interfaces between components, with reduction of the complexity potential for side-effects.

In a simple program, this may aim to ensure that loops have single or obvious exit points and (where possible) to have single exit points from functions and procedures.

In a larger system, it may involve breaking down complex tasks into many different modules. Consider a system which handles payroll on ships and at shore offices:

* The uppermost level may feature a menu of typical end-user operations.
* Within that could be standalone executables or libraries for tasks such as signing on and off employees or printing checks.
* Within each of those standalone components there could be many different source files, each containing the program code to handle a part of the problem, with only selected interfaces available to other parts of the program. A sign on program could have source files for each data entry screen and the database interface (which may itself be a standalone third party library or a statically linked set of library routines).
*Either the database or the payroll application also has to initiate the process of exchanging data with between ship and shore, and that data transfer task will often contain many other components.

These layers produce the effect of isolating the implementation details of one component and its assorted internal methods from the others. Object-oriented programming embraced and extended this concept.

==Data abstraction==
{{Main|Abstract data type}}

Data abstraction enforces a clear separation between the ''abstract'' properties of a [[data type]] and the ''concrete'' details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the ''interface'' to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour.

For example, one could define an [[abstract data type]] called ''lookup table'' which uniquely associates ''keys'' with ''values'', and in which values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a [[hash table]], a [[binary search tree]], or even a simple linear [[List (computing)|list]] of (key:value) pairs. As far as client code is concerned, the abstract properties of the type are the same in each case.

Of course, this all relies on getting the details of the interface right in the first place, since any changes there can have major impacts on client code. As one way to look at this: the interface forms a ''contract'' on agreed behaviour between the data type and client code; anything not spelled out in the contract is subject to change without notice.


Languages that implement data abstraction include [[Ada programming language|Ada]] and [[Modula-2]]. [[Object-oriented]] languages are commonly claimed{{By whom|date=March 2009}} to offer data abstraction; however, their [[Inheritance (computer science)|inheritance]] concept tends to put information in the interface that more properly belongs in the implementation; thus, changes to such information ends up impacting client code, leading directly to the [[Fragile binary interface problem]].

==Abstraction in object oriented programming==
{{Main|Object (computer science)}}

In [[object-oriented programming]] theory, '''abstraction''' involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system. The term [[information hiding|encapsulation]] refers to the hiding of [[state (computer science)|state]] details, but extending the concept of ''data type'' from earlier programming languages to associate ''behavior'' most strongly with the data, and standardizing the way that different data types interact, is the beginning of '''abstraction'''. When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called [[polymorphism (computer science)|polymorphism]]. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called [[Delegation (programming)|delegation]] or [[Inheritance (computer science)|inheritance]].

Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of [[polymorphism (computer science)|polymorphism]] in object-oriented programming, which includes the substitution of one [[type in object-oriented programming|type]] for another in the same or similar role. Although not as generally supported, a [[configuration in object-oriented programming|configuration]] or image or package may predetermine a great many of these [[name binding|bindings]] at [[compile-time]], [[link-time]], or [[loadtime]]. This would leave only a minimum of such bindings to change at [[run-time]].

[[Common Lisp Object System]] or [[self programming language|self]], for example, feature less of a class-instance distinction and more use of delegation for [[polymorphism in object-oriented programming|polymorphism]]. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from [[Lisp programming language|Lisp]].

C++ exemplifies another extreme: it relies heavily on [[generic programming|templates]] and [[method overloading|overloading]] and other static bindings at compile-time, which in turn has certain flexibility problems.

Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.

Consider for example a sample [[Java (programming language)|Java]] fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an <code>Animal</code> class to represent both the state of the animal and its functions:

<source lang=java>
public class Animal extends LivingThing
{
private Location loc;
private double energyReserves;

boolean isHungry() {
return energyReserves < 2.5;
}
void eat(Food f) {
// Consume food
energyReserves += f.getCalories();
}
void moveTo(Location l) {
// Move to new location
loc = l;
}
}
</source>
With the above definition, one could create objects of type <tt>Animal</tt> and call their methods like this:

<source lang=java>
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
theCow.eat(grass);
}
theCow.moveTo(theBarn);
</source>
In the above example, the class ''<code>Animal</code>'' is an abstraction used in place of an actual animal, ''<code>LivingThing</code>'' is a further abstraction (in this case a generalisation) of ''<code>Animal</code>''.

If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality.

Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using [[Inheritance (computer science)|inheritance]] or stand alone, and the programmer could define varying degrees of [[polymorphism (computer science)|polymorphism]] between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.

===Object-oriented design===
{{Main|Object-oriented design}}

Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and [[domain analysis]]—actually determining the relevant relationships in the real world is the concern of [[object-oriented analysis]] or [[legacy analysis]].

In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.

==Considerations==
When discussing [[formal semantics of programming languages]], [[formal methods]] or [[abstract interpretation]], '''abstraction''' refers to the act of considering a less detailed, but safe, definition of the observed program behaviors. For instance, one may observe only the final result of program executions instead of considering all the intermediate steps of executions. Abstraction is defined to a '''concrete''' (more precise) model of execution.

Abstraction may be '''exact''' or '''faithful''' with respect to a property if one can answer a question about the property equally well on the concrete or abstract model. For instance, if we wish to know what the result of the evaluation of a mathematical expression involving only integers +, -, ×, is worth [[modular arithmetic|modulo]] ''n'', we need only perform all operations modulo ''n'' (a familiar form of this abstraction is [[casting out nines]]).

Abstractions, however, though not necessarily '''exact''', should be '''sound'''. That is, it should be possible to get sound answers from them—even though the abstraction may simply yield a result of [[undecidability]]. For instance, we may abstract the students in a class by their minimal and maximal ages; if one asks whether a certain person belongs to that class, one may simply compare that person's age with the minimal and maximal ages; if his age lies outside the range, one may safely answer that the person does not belong to the class; if it does not, one may only answer "I don't know".

The level of abstraction included in a programming language can influence its overall [[usability]]. The [[Cognitive dimensions]] framework includes the concept of ''abstraction gradient'' in a formalism. This framework allows the designer of a programming language to study the trade-offs between abstraction and other characteristics of the design, and how changes in abstraction influence the language usability.

Abstractions can prove useful when dealing with computer programs, because non-trivial properties of computer programs are essentially [[undecidable]] (see [[Rice's theorem]]). As a consequence, automatic methods for deriving information on the behavior of computer programs either have to drop termination (on some occasions, they may fail, crash or never yield out a result), soundness (they may provide false information), or precision (they may answer "I don't know" to some questions).

Abstraction is the core concept of [[abstract interpretation]]. [[Model checking]] generally takes place on abstract versions of the studied systems.

==Levels of abstraction==
{{Main|Abstraction layer}}

Computer science commonly presents ''levels'' (or, less commonly, ''layers'') of abstraction, wherein each level represents a different model of the same information and processes, but uses a system of expression involving a unique set of objects and compositions that apply only to a particular domain.
<ref>[[Luciano Floridi]], [http://www.philosophyofinformation.net/pdf/latmoa.pdf ''Levellism and the Method of Abstraction'']
IEG – Research Report 22.11.04</ref>
Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level, which tends to provide an increasingly "granular" representation. For example, gates build on electronic circuits, binary on gates, machine language on binary, programming language on machine language, applications and operating systems on programming languages. Each level is embodied, but not determined, by the level beneath it, making it a language of description that is somewhat self-contained.

===Database systems===
{{Main|Database management system}}

Since many users of database systems lack in-depth familiarity with computer data-structures, database developers often hide complexity through the following levels:

[[Image:Data abstraction levels.png|thumb|Data abstraction levels of a database system]]

'''Physical level:''' The lowest level of abstraction describes ''how'' a system actually stores data. The physical level describes complex low-level data structures in detail.

'''Logical level:''' The next higher level of abstraction describes ''what'' data the database stores, and what relationships exist among those data. The logical level thus describes an entire database in terms of a small number of relatively simple structures. Although implementation of the simple structures at the logical level may involve complex physical level structures, the user of the logical level does not need to be aware of this complexity. This referred to as [[Physical Data Independence]]. [[Database administrator]]s, who must decide what information to keep in a database, use the logical level of abstraction.

'''View level:''' The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of a database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many [[view (database)|view]]s for the same database.

===Layered architecture===
The ability to provide a [[design]] of different levels of abstraction can

* simplify the design considerably
* enable different role players to effectively work at various levels of abstraction

[[Systems design]] and [[Business process modeling|business process design]] can both use this. Some [[Software modeling|design processes]] specifically generate designs that contain various levels of abstraction.

Layered architecture partitions the concerns of the application into stacked groups (layers).
it is a technique used in designing computer software, hardware, and communications in which system or network components are isolated in layers so that changes can be made in one layer without affecting the others.

==See also==
* [[Abstraction inversion]] for an anti-pattern of one danger in abstraction
* [[Abstract data type]] for an abstract description of a set of data
* [[Algorithm]] for an abstract description of a computational procedure
* [[Bracket abstraction]] for making a term into a function of a variable
* [[Data modeling]] for structuring data independent of the processes that use it
* [[Encapsulation]] for the categorical dual (other side) of abstraction
* [[Greenspun's Tenth Rule]] for an aphorism about an (the?) optimum point in the space of abstractions
* [[Higher-order function]] for abstraction where functions produce or consume other functions
* [[Lambda abstraction]] for making a term into a function of some variable
* [[Program refinement|Refinement]] for the opposite of abstraction in computing
* [[Substitution]] for the categorical left adjoint (inverse) of abstraction

==Notes==
{{FOLDOC}}
<references/>

==Further reading==
* Abelson, Harold, Gerald Jay Sussman with Julie Sussman. (1996) ISBN 0-262-01153-0 ''[[Structure and Interpretation of Computer Programs]] (Second edition)''. The MIT Press (See [http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html MIT.edu])
* Joel Spolsky. [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Joelonsoftware.com] ''The Law of Leaky Abstractions.'' 2002-11-11.

{{DEFAULTSORT:Abstraction (Computer Science)}}
[[Category:Data management]]
[[Category:Programming paradigms]]
[[Category:Articles with example Java code]]

[[af:Abstraksie (rekenaarwetenskap)]]
[[bs:Računarska apstrakcija]]
[[da:Abstraktion (datalogi)]]
[[es:Abstracción (informática)]]
[[fa:انتزاع (رایانه)]]
[[fr:Abstraction (informatique)]]
[[ko:추상화 (전산학)]]
[[it:Astrazione (informatica)]]
[[ms:Pengabstrakan (sains komputer)]]
[[ja:抽象化 (計算機科学)]]
[[pl:Abstrakcja (programowanie)]]
[[pt:Abstração (programação)]]
[[ru:Абстракция данных]]
[[sh:Kompjuterska apstrakcija]]
[[tr:Soyutlama (bilgisayar bilimi)]]
[[uk:Абстрагування (програмування)]]

Abstraktion (Informatik)

2010-09-17T12:54:26Z

Libcub: rv

In [[computer science]], the mechanism and practice of '''abstraction''' reduces and factors out details so that one can focus on a few concepts at a time.

The following English definition of abstraction helps to understand how this term applies to computer science, IT and objects:

: ''abstraction - a concept or idea not associated with any specific instance''<ref>[http://www.thefreedictionary.com/abstraction Thefreedictionary.com]</ref>

The concept originated by analogy with [[abstraction (mathematics)|abstraction]] in [[mathematics]]. The mathematical technique of abstraction begins with mathematical [[definition]]s; this has the fortunate effect of finessing some of the vexing philosophical issues of [[abstraction]]. For example, in both computing and in mathematics, [[number]]s are concepts in the [[programming language]]s, as founded in mathematics. Implementation details depend on the hardware and software, but this is not a restriction because the computing concept of number is still based on the mathematical concept.

In [[computer programming]], abstraction can apply to control or to data: '''Control abstraction''' is the abstraction of actions while '''data abstraction''' is that of data structures.

* Control abstraction involves the use of [[subprogram]]s and related concepts [[control flow]]s
* Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind [[datatype]].

One can regard the notion of an [[object (computer science)|object]] (from [[object-oriented programming]]) as an attempt to combine abstractions of data and code.

The recommendation that programmers use abstractions whenever suitable in order to avoid duplication (usually [[code duplication|of code]]) is known as the [[abstraction principle (programming)|abstraction principle]]. The requirement that a programming language provide suitable abstractions is also called the abstraction principle.

==Rationale==
Computing mostly operates independently of the concrete world: The hardware implements a [[model of computation]] that is interchangeable with others. The software is structured in [[software architecture|architecture]]s to enable humans to create the enormous systems by concentration on a few issues at a time. These architectures are made of specific choices of abstractions. [[Greenspun's Tenth Rule]] is an [[aphorism]] on how such an architecture is both inevitable and complex.

A central form of abstraction in computing is language abstraction: new artificial languages are developed to express specific aspects of a system. ''[[Modeling languages]]'' help in planning. ''[[Computer language]]s'' can be processed with a computer. An example of this abstraction process is the generational development of [[programming language]]s from the [[First-generation programming language|machine language]] to the [[Second-generation programming language|assembly language]] and the [[Third-generation programming language|high-level language]]. Each stage can be used as a stepping stone for the next stage. The language abstraction continues for example in [[scripting language]]s and [[domain-specific programming language]]s.

Within a programming language, some features let the programmer create new abstractions. These include the [[subroutine]], the [[module (programming)|module]], and the [[software component]]. Some other abstractions such as [[software design pattern]]s and [[software architecture#Architecture examples|architectural styles]] remain invisible to a programming language and operate only in the design of a system.

Some abstractions try to limit the breadth of concepts a programmer needs by completely hiding the abstractions they in turn are built on. [[Joel Spolsky]] has criticised these efforts by claiming that all abstractions are ''[[leaky abstraction|leaky]]'' — that they can never completely hide the details below; however this does not negate the usefulness of abstraction. Some abstractions are designed to interoperate with others, for example a programming language may contain a [[foreign function interface]] for making calls to the lower-level language.

==Language features==
===Programming languages===
{{Main|Programming language}}

Different programming languages provide different types of abstraction, depending on the intended applications for the language. For example:

* In [[object-oriented programming language]]s such as [[C++]], [[Object Pascal]], or [[Java (programming language)|Java]], the concept of '''abstraction''' has itself become a declarative statement - using the [[keyword (computer programming)|keyword]]s ''<code>virtual</code>'' (in [[C++]]) or ''<code>abstract</code>'' (in [[Java (programming language)|Java]]). After such a declaration, it is the responsibility of the programmer to implement a [[Class (computer science)|class]] to instantiate the [[Object (computer science)|object]] of the declaration.
* [[Functional programming language]]s commonly exhibit abstractions related to functions, such as [[lambda abstraction]]s (making a term into a function of some variable), [[higher-order function]]s (parameters are functions), [[bracket abstraction]] (making a term into a function of a variable). 

===Specification methods===
{{Main|Formal specification}}

Analysts have developed various methods to formally specify software systems. Some known methods include:

* Abstract-model based method (VDM, Z);
* Algebraic techniques (Larch, CLEAR, OBJ, ACT ONE);
* Process-based techniques (LOTOS, SDL, Estelle);
* Trace-based techniques (SPECIAL, TAM);
* Knowledge-based techniques (Refine, Gist).

===Specification languages===
{{Main|Specification language}}

Specification languages generally rely on abstractions of one kind or another, since specifications are typically defined earlier in a project (and at a more abstract level) than an eventual implementation. The [[Unified Modeling Language|UML]] specification language, for example, allows the definition of ''abstract'' classes, which remain abstract during the architecture and specification phase of the project.

==Control abstraction==
{{Main|Control flow}}

Programming languages offer control abstraction as one of the main purposes of their use. Computer machines understand operations at the very low level such as moving some bits from one location of the memory to another location and producing the sum of two sequences of bits. Programming languages allow this to be done in the higher level. For example, consider this statement written in a [[Pascal (programming language)|Pascal]]-like fashion:

:<code>a := (1 + 2) * 5</code>

To a human, this seems a fairly simple and obvious calculation (''"one plus two is three, times five is fifteen"''). However, the low-level steps necessary to carry out this evaluation, and return the value "15", and then assign that value to the variable "a", are actually quite subtle and complex. The values need to be converted to binary representation (often a much more complicated task than one would think) and the calculations decomposed (by the compiler or interpreter) into assembly instructions (again, which are much less intuitive to the programmer: operations such as shifting a binary register left, or adding the binary complement of the contents of one register to another, are simply not how humans think about the abstract arithmetical operations of addition or multiplication). Finally, assigning the resulting value of "15" to the variable labeled "a", so that "a" can be used later, involves additional 'behind-the-scenes' steps of looking up a variable's label and the resultant location in physical or virtual memory, storing the binary representation of "15" to that memory location, etc.

Without control abstraction, a programmer would need to specify ''all'' the register/binary-level steps each time he simply wanted to add or multiply a couple of numbers and assign the result to a variable. Such duplication of effort has two serious negative consequences:

# it forces the programmer to constantly repeat fairly common tasks every time a similar operation is needed
# it forces the programmer to program for the particular hardware and instruction set

===Structured programming===
{{Main|Structured programming}}

Structured programming involves the splitting of complex program tasks into smaller pieces with clear flow-control and interfaces between components, with reduction of the complexity potential for side-effects.

In a simple program, this may aim to ensure that loops have single or obvious exit points and (where possible) to have single exit points from functions and procedures.

In a larger system, it may involve breaking down complex tasks into many different modules. Consider a system which handles payroll on ships and at shore offices:

* The uppermost level may feature a menu of typical end-user operations.
* Within that could be standalone executables or libraries for tasks such as signing on and off employees or printing checks.
* Within each of those standalone components there could be many different source files, each containing the program code to handle a part of the problem, with only selected interfaces available to other parts of the program. A sign on program could have source files for each data entry screen and the database interface (which may itself be a standalone third party library or a statically linked set of library routines).
*Either the database or the payroll application also has to initiate the process of exchanging data with between ship and shore, and that data transfer task will often contain many other components.

These layers produce the effect of isolating the implementation details of one component and its assorted internal methods from the others. Object-oriented programming embraced and extended this concept.

==Data abstraction==
{{Main|Abstract data type}}

Data abstraction enforces a clear separation between the ''abstract'' properties of a [[data type]] and the ''concrete'' details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the ''interface'' to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour.

For example, one could define an [[abstract data type]] called ''lookup table'' which uniquely associates ''keys'' with ''values'', and in which values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a [[hash table]], a [[binary search tree]], or even a simple linear [[List (computing)|list]] of (key:value) pairs. As far as client code is concerned, the abstract properties of the type are the same in each case.

Of course, this all relies on getting the details of the interface right in the first place, since any changes there can have major impacts on client code. As one way to look at this: the interface forms a ''contract'' on agreed behaviour between the data type and client code; anything not spelled out in the contract is subject to change without notice.


Languages that implement data abstraction include [[Ada programming language|Ada]] and [[Modula-2]]. [[Object-oriented]] languages are commonly claimed{{By whom|date=March 2009}} to offer data abstraction; however, their [[Inheritance (computer science)|inheritance]] concept tends to put information in the interface that more properly belongs in the implementation; thus, changes to such information ends up impacting client code, leading directly to the [[Fragile binary interface problem]].

==Abstraction in object oriented programming==
{{Main|Object (computer science)}}

In [[object-oriented programming]] theory, '''abstraction''' involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system. The term [[information hiding|encapsulation]] refers to the hiding of [[state (computer science)|state]] details, but extending the concept of ''data type'' from earlier programming languages to associate ''behavior'' most strongly with the data, and standardizing the way that different data types interact, is the beginning of '''abstraction'''. When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called [[polymorphism (computer science)|polymorphism]]. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called [[Delegation (programming)|delegation]] or [[Inheritance (computer science)|inheritance]].

Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of [[polymorphism (computer science)|polymorphism]] in object-oriented programming, which includes the substitution of one [[type in object-oriented programming|type]] for another in the same or similar role. Although not as generally supported, a [[configuration in object-oriented programming|configuration]] or image or package may predetermine a great many of these [[Binding (computer science)|binding]]s at [[compile-time]], [[link-time]], or [[loadtime]]. This would leave only a minimum of such bindings to change at [[run-time]].

[[Common Lisp Object System]] or [[self programming language|self]], for example, feature less of a class-instance distinction and more use of delegation for [[polymorphism in object-oriented programming|polymorphism]]. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from [[Lisp programming language|Lisp]].

C++ exemplifies another extreme: it relies heavily on [[generic programming|templates]] and [[method overloading|overloading]] and other static bindings at compile-time, which in turn has certain flexibility problems.

Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.

Consider for example a sample [[Java (programming language)|Java]] fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an <code>Animal</code> class to represent both the state of the animal and its functions:

<source lang=java>
public class Animal extends LivingThing
{
private Location loc;
private double energyReserves;

boolean isHungry() {
return energyReserves < 2.5;
}
void eat(Food f) {
// Consume food
energyReserves += f.getCalories();
}
void moveTo(Location l) {
// Move to new location
loc = l;
}
}
</source>
With the above definition, one could create objects of type <tt>Animal</tt> and call their methods like this:

<source lang=java>
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
theCow.eat(grass);
}
theCow.moveTo(theBarn);
</source>
In the above example, the class ''<code>Animal</code>'' is an abstraction used in place of an actual animal, ''<code>LivingThing</code>'' is a further abstraction (in this case a generalisation) of ''<code>Animal</code>''.

If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality.

Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using [[Inheritance (computer science)|inheritance]] or stand alone, and the programmer could define varying degrees of [[polymorphism (computer science)|polymorphism]] between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.

===Object-oriented design===
{{Main|Object-oriented design}}

Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and [[domain analysis]]—actually determining the relevant relationships in the real world is the concern of [[object-oriented analysis]] or [[legacy analysis]].

In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.

==Considerations==
When discussing [[formal semantics of programming languages]], [[formal methods]] or [[abstract interpretation]], '''abstraction''' refers to the act of considering a less detailed, but safe, definition of the observed program behaviors. For instance, one may observe only the final result of program executions instead of considering all the intermediate steps of executions. Abstraction is defined to a '''concrete''' (more precise) model of execution.

Abstraction may be '''exact''' or '''faithful''' with respect to a property if one can answer a question about the property equally well on the concrete or abstract model. For instance, if we wish to know what the result of the evaluation of a mathematical expression involving only integers +, -, ×, is worth [[modular arithmetic|modulo]] ''n'', we need only perform all operations modulo ''n'' (a familiar form of this abstraction is [[casting out nines]]).

Abstractions, however, though not necessarily '''exact''', should be '''sound'''. That is, it should be possible to get sound answers from them—even though the abstraction may simply yield a result of [[undecidability]]. For instance, we may abstract the students in a class by their minimal and maximal ages; if one asks whether a certain person belongs to that class, one may simply compare that person's age with the minimal and maximal ages; if his age lies outside the range, one may safely answer that the person does not belong to the class; if it does not, one may only answer "I don't know".

The level of abstraction included in a programming language can influence its overall [[usability]]. The [[Cognitive dimensions]] framework includes the concept of ''abstraction gradient'' in a formalism. This framework allows the designer of a programming language to study the trade-offs between abstraction and other characteristics of the design, and how changes in abstraction influence the language usability.

Abstractions can prove useful when dealing with computer programs, because non-trivial properties of computer programs are essentially [[undecidable]] (see [[Rice's theorem]]). As a consequence, automatic methods for deriving information on the behavior of computer programs either have to drop termination (on some occasions, they may fail, crash or never yield out a result), soundness (they may provide false information), or precision (they may answer "I don't know" to some questions).

Abstraction is the core concept of [[abstract interpretation]]. [[Model checking]] generally takes place on abstract versions of the studied systems.

==Levels of abstraction==
{{Main|Abstraction layer}}

Computer science commonly presents ''levels'' (or, less commonly, ''layers'') of abstraction, wherein each level represents a different model of the same information and processes, but uses a system of expression involving a unique set of objects and compositions that apply only to a particular domain.
<ref>[[Luciano Floridi]], [http://www.philosophyofinformation.net/pdf/latmoa.pdf ''Levellism and the Method of Abstraction'']
IEG – Research Report 22.11.04</ref>
Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level, which tends to provide an increasingly "granular" representation. For example, gates build on electronic circuits, binary on gates, machine language on binary, programming language on machine language, applications and operating systems on programming languages. Each level is embodied, but not determined, by the level beneath it, making it a language of description that is somewhat self-contained.

===Database systems===
{{Main|Database management system}}

Since many users of database systems lack in-depth familiarity with computer data-structures, database developers often hide complexity through the following levels:

[[Image:Data abstraction levels.png|thumb|Data abstraction levels of a database system]]

'''Physical level:''' The lowest level of abstraction describes ''how'' a system actually stores data. The physical level describes complex low-level data structures in detail.

'''Logical level:''' The next higher level of abstraction describes ''what'' data the database stores, and what relationships exist among those data. The logical level thus describes an entire database in terms of a small number of relatively simple structures. Although implementation of the simple structures at the logical level may involve complex physical level structures, the user of the logical level does not need to be aware of this complexity. [[Database administrator]]s, who must decide what information to keep in a database, use the logical level of abstraction.

'''View level:''' The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of a database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many [[view (database)|view]]s for the same database.

===Layered architecture===
The ability to provide a [[design]] of different levels of abstraction can

* simplify the design considerably
* enable different role players to effectively work at various levels of abstraction

[[Systems design]] and [[Business process modeling|business process design]] can both use this. Some [[Software modeling|design processes]] specifically generate designs that contain various levels of abstraction.

Layered architecture partitions the concerns of the application into stacked groups (layers).
it is a technique used in designing computer software, hardware, and communications in which system or network components are isolated in layers so that changes can be made in one layer without affecting the others.

==See also==
* [[Abstraction inversion]] for an anti-pattern of one danger in abstraction
* [[Abstract data type]] for an abstract description of a set of data
* [[Algorithm]] for an abstract description of a computational procedure
* [[Bracket abstraction]] for making a term into a function of a variable
* [[Data modeling]] for structuring data independent of the processes that use it
* [[Encapsulation]] for the categorical dual (other side) of abstraction
* [[Greenspun's Tenth Rule]] for an aphorism about an (the?) optimum point in the space of abstractions
* [[Higher-order function]] for abstraction where functions produce or consume other functions
* [[Lambda abstraction]] for making a term into a function of some variable
* [[Program refinement|Refinement]] for the opposite of abstraction in computing
* [[Substitution]] for the categorical left adjoint (inverse) of abstraction

==Notes==
{{FOLDOC}}
<references/>

==Further reading==
* Abelson, Harold, Gerald Jay Sussman with Julie Sussman. (1996) ISBN 0-262-01153-0 ''[[Structure and Interpretation of Computer Programs]] (Second edition)''. The MIT Press (See [http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html MIT.edu])
* Joel Spolsky. [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Joelonsoftware.com] ''The Law of Leaky Abstractions.'' 2002-11-11.

{{DEFAULTSORT:Abstraction (Computer Science)}}
[[Category:Data management]]
[[Category:Programming paradigms]]
[[Category:Articles with example Java code]]

[[af:Abstraksie (rekenaarwetenskap)]]
[[bs:Računarska apstrakcija]]
[[da:Abstraktion (datalogi)]]
[[es:Abstracción (informática)]]
[[fa:انتزاع (رایانه)]]
[[fr:Abstraction (informatique)]]
[[ko:추상화 (전산학)]]
[[it:Astrazione (informatica)]]
[[ms:Pengabstrakan (sains komputer)]]
[[ja:抽象化 (計算機科学)]]
[[pl:Abstrakcja (programowanie)]]
[[pt:Abstração (programação)]]
[[ru:Абстракция данных]]
[[sh:Kompjuterska apstrakcija]]
[[tr:Soyutlama (bilgisayar bilimi)]]
[[uk:Абстрагування (програмування)]]

Abstraktion (Informatik)

2010-04-26T00:51:20Z

Libcub: /* Rational */ typo

In [[computer science]], the mechanism and practice of '''abstraction''' reduces and factors out details so that one can focus on a few concepts at a time.

The following English definition of abstraction helps to understand how this term applies to computer science, IT and objects:

: ''abstraction - a concept or idea not associated with any specific instance''<ref>[http://www.thefreedictionary.com/abstraction Thefreedictionary.com]</ref>

The concept originated by analogy with [[abstraction (mathematics)|abstraction]] in [[mathematics]]. The mathematical technique of abstraction begins with mathematical [[definition]]s; this has the fortunate effect of finessing some of the vexing philosophical issues of [[abstraction]]. For example, in both computing and in mathematics, [[number]]s are concepts in the [[programming language]]s, as founded in mathematics. Implementation details depend on the hardware and software, but this is not a restriction because the computing concept of number is still based on the mathematical concept.

In [[computer programming]], abstraction can apply to control or to data: '''Control abstraction''' is the abstraction of actions while '''data abstraction''' is that of data structures.

* Control abstraction involves the use of [[subprogram]]s and related concepts [[control flow]]s
* Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind [[datatype]].

One can regard the notion of [[object (computer science)|object]] from [[object-oriented programming]] as an attempt to combine abstractions of data and code.

The recommendation that programmers use abstractions whenever suitable in order to avoid duplication (usually [[code duplication|of code]]) is known as the [[abstraction principle (programming)|abstraction principle]]. The requirement that a programming language provide suitable abstractions is also called the abstraction principle.

==Rationale==
Computing mostly operates independently of the concrete world: The hardware implements a [[model of computation]] that is interchangeable with others. The software is structured in [[software architecture|architecture]]s to enable humans to create the enormous systems by concentration on a few issues at a time. These architectures are made of specific choices of abstractions. [[Greenspun's Tenth Rule]] is an [[aphorism]] on how such an architecture is both inevitable and complex.

A central form of abstraction in computing is language abstraction: new artificial languages are developed to express specific aspects of a system. ''[[Modeling languages]]'' help in planning. ''[[Computer language]]s'' can be processed with a computer. An example of this abstraction process is the generational development of [[programming language]]s from the [[First-generation programming language|machine language]] to the [[Second-generation programming language|assembly language]] and the [[Third-generation programming language|high-level language]]. Each stage can be used as a stepping stone for the next stage. The language abstraction continues for example in [[scripting language]]s and [[domain-specific programming language]]s.

Within a programming language, some features let the programmer create new abstractions. These include the [[subroutine]], the [[module (programming)|module]], and the [[software component]]. Some other abstractions such as [[software design pattern]]s and [[software architecture#Architecture examples|architectural styles]] remain invisible to a programming language and operate only in the design of a system.

Some abstractions try to limit the breadth of concepts a programmer needs by completely hiding the abstractions they in turn are built on. [[Joel Spolsky]] has criticised these efforts by claiming that all abstractions are ''[[leaky abstraction|leaky]]'' — that they can never completely hide the details below; however this does not negate the usefulness of abstraction. Some abstractions are designed to interoperate with others, for example a programming language may contain a [[foreign function interface]] for making calls to the lower-level language.

==Language features==
===Programming languages===
{{Main|Programming language}}

Different programming languages provide different types of abstraction, depending on the intended applications for the language. For example:

* In [[object-oriented programming language]]s such as [[C++]], [[Object Pascal]], or [[Java (programming language)|Java]], the concept of '''abstraction''' has itself become a declarative statement - using the [[keyword (computer programming)|keyword]]s ''<code>virtual</code>'' (in [[C++]]) or ''<code>abstract</code>'' (in [[Java (programming language)|Java]]). After such a declaration, it is the responsibility of the programmer to implement a [[Class (computer science)|class]] to instantiate the [[Object (computer science)|object]] of the declaration.
* [[Functional programming language]]s commonly exhibit abstractions related to functions, such as [[lambda abstraction]]s (making a term into a function of some variable), [[higher-order function]]s (parameters are functions), [[bracket abstraction]] (making a term into a function of a variable). 
* The [[Linda (coordination language)|Linda]] language abstracts the concepts of ''server'' and ''shared data-space'' to facilitate distributed programming.

===Specification methods===
{{Main|Formal specification}}

Analysts have developed various methods to formally specify software systems. Some known methods include:

* Abstract-model based method (VDM, Z);
* Algebraic techniques (Larch, CLEAR, OBJ, ACT ONE);
* Process-based techniques (LOTOS, SDL, Estelle);
* Trace-based techniques (SPECIAL, TAM);
* Knowledge-based techniques (Refine, Gist).

===Specification languages===
{{Main|Specification language}}

Specification languages generally rely on abstractions of one kind or another, since specifications are typically defined earlier in a project (and at a more abstract level) than an eventual implementation. The [[Unified Modeling Language|UML]] specification language, for example, allows the definition of ''abstract'' classes, which remain abstract during the architecture and specification phase of the project.

==Control abstraction==
{{Main|Control flow}}

Programming languages offer control abstraction as one of the main purposes of their use. Computer machines understand operations at the very low level such as moving some bits from one location of the memory to another location and producing the sum of two sequences of bits. Programming languages allow this to be done in the higher level. For example, consider this statement written in a [[Pascal (programming language)|Pascal]]-like fashion:

:<code>a := (1 + 2) * 5</code>

To a human, this seems a fairly simple and obvious calculation (''"one plus two is three, times five is fifteen"''). However, the low-level steps necessary to carry out this evaluation, and return the value "15", and then assign that value to the variable "a", are actually quite subtle and complex. The values need to be converted to binary representation (often a much more complicated task than one would think) and the calculations decomposed (by the compiler or interpreter) into assembly instructions (again, which are much less intuitive to the programmer: operations such as shifting a binary register left, or adding the binary complement of the contents of one register to another, are simply not how humans think about the abstract arithmetical operations of addition or multiplication). Finally, assigning the resulting value of "15" to the variable labeled "a", so that "a" can be used later, involves additional 'behind-the-scenes' steps of looking up a variable's label and the resultant location in physical or virtual memory, storing the binary representation of "15" to that memory location, etc.

Without control abstraction, a programmer would need to specify ''all'' the register/binary-level steps each time she simply wanted to add or multiply a couple of numbers and assign the result to a variable. Such duplication of effort has two serious negative consequences:

# it forces the programmer to constantly repeat fairly common tasks every time a similar operation is needed
# it forces the programmer to program for the particular hardware and instruction set

===Structured programming===
{{Main|Structured programming}}

Structured programming involves the splitting of complex program tasks into smaller pieces with clear flow-control and interfaces between components, with reduction of the complexity potential for side-effects.

In a simple program, this may aim to ensure that loops have single or obvious exit points and (where possible) to have single exit points from functions and procedures.

In a larger system, it may involve breaking down complex tasks into many different modules. Consider a system which handles payroll on ships and at shore offices:

* The uppermost level may feature a menu of typical end-user operations.
* Within that could be standalone executables or libraries for tasks such as signing on and off employees or printing checks.
* Within each of those standalone components there could be many different source files, each containing the program code to handle a part of the problem, with only selected interfaces available to other parts of the program. A sign on program could have source files for each data entry screen and the database interface (which may itself be a standalone third party library or a statically linked set of library routines).
*Either the database or the payroll application also has to initiate the process of exchanging data with between ship and shore, and that data transfer task will often contain many other components.

These layers produce the effect of isolating the implementation details of one component and its assorted internal methods from the others. Object-oriented programming embraced and extended this concept.

==Data abstraction==
{{Main|Abstract data type}}

Data abstraction enforces a clear separation between the ''abstract'' properties of a [[data type]] and the ''concrete'' details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the ''interface'' to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour.

For example, one could define an [[abstract data type]] called ''lookup table'' which uniquely associates ''keys'' with ''values'', and in which values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a [[hash table]], a [[binary search tree]], or even a simple linear [[List (computing)|list]] of (key:value) pairs. As far as client code is concerned, the abstract properties of the type are the same in each case.

Of course, this all relies on getting the details of the interface right in the first place, since any changes there can have major impacts on client code. As one way to look at this: the interface forms a ''contract'' on agreed behaviour between the data type and client code; anything not spelled out in the contract is subject to change without notice.


Languages that implement data abstraction include [[Ada programming language|Ada]] and [[Modula-2]]. [[Object-oriented]] languages are commonly claimed{{By whom|date=March 2009}} to offer data abstraction; however, their [[Inheritance (computer science)|inheritance]] concept tends to put information in the interface that more properly belongs in the implementation; thus, changes to such information ends up impacting client code, leading directly to the [[Fragile binary interface problem]].

==Abstraction in object oriented programming==
{{Main|Object (computer science)}}

In [[object-oriented programming]] theory, '''abstraction''' involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system. The term [[information hiding|encapsulation]] refers to the hiding of [[state (computer science)|state]] details, but extending the concept of ''data type'' from earlier programming languages to associate ''behavior'' most strongly with the data, and standardizing the way that different data types interact, is the beginning of '''abstraction'''. When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called [[polymorphism (computer science)|polymorphism]]. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called [[Delegation (programming)|delegation]] or [[Inheritance (computer science)|inheritance]].

Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of [[polymorphism (computer science)|polymorphism]] in object-oriented programming, which includes the substitution of one [[type in object-oriented programming|type]] for another in the same or similar role. Although not as generally supported, a [[configuration in object-oriented programming|configuration]] or image or package may predetermine a great many of these [[Binding (computer science)|binding]]s at [[compile-time]], [[link-time]], or [[loadtime]]. This would leave only a minimum of such bindings to change at [[run-time]].

[[Common Lisp Object System]] or [[self programming language|self]], for example, feature less of a class-instance distinction and more use of delegation for [[polymorphism in object-oriented programming|polymorphism]]. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from [[Lisp programming language|Lisp]].

C++ exemplifies another extreme: it relies heavily on [[generic programming|templates]] and [[method overloading|overloading]] and other static bindings at compile-time, which in turn has certain flexibility problems.

Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.

Consider for example a sample [[Java (programming language)|Java]] fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an <code>Animal</code> class to represent both the state of the animal and its functions:

<source lang=java>
public class Animal extends LivingThing
{
private Location loc;
private double energyReserves;

boolean isHungry() {
return energyReserves < 2.5;
}
void eat(Food f) {
// Consume food
energyReserves += f.getCalories();
}
void moveTo(Location l) {
// Move to new location
loc = l;
}
}
</source>
With the above definition, one could create objects of type <tt>Animal</tt> and call their methods like this:

<source lang=java>
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
theCow.eat(grass);
}
theCow.moveTo(theBarn);
</source>
In the above example, the class ''<code>Animal</code>'' is an abstraction used in place of an actual animal, ''<code>LivingThing</code>'' is a further abstraction (in this case a generalisation) of ''<code>Animal</code>''.

If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality.

Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using [[Inheritance (computer science)|inheritance]] or stand alone, and the programmer could define varying degrees of [[polymorphism (computer science)|polymorphism]] between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.

===Object-oriented design===
{{Main|Object-oriented design}}

Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and [[domain analysis]]—actually determining the relevant relationships in the real world is the concern of [[object-oriented analysis]] or [[legacy analysis]].

In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.

==Considerations==
When discussing [[formal semantics of programming languages]], [[formal methods]] or [[abstract interpretation]], '''abstraction''' refers to the act of considering a less detailed, but safe, definition of the observed program behaviors. For instance, one may observe only the final result of program executions instead of considering all the intermediate steps of executions. Abstraction is defined to a '''concrete''' (more precise) model of execution.

Abstraction may be '''exact''' or '''faithful''' with respect to a property if one can answer a question about the property equally well on the concrete or abstract model. For instance, if we wish to know what the result of the evaluation of a mathematical expression involving only integers +, -, ×, is worth [[modular arithmetic|modulo]] ''n'', we need only perform all operations modulo ''n'' (a familiar form of this abstraction is [[casting out nines]]).

Abstractions, however, though not necessarily '''exact''', should be '''sound'''. That is, it should be possible to get sound answers from them—even though the abstraction may simply yield a result of [[undecidability]]. For instance, we may abstract the students in a class by their minimal and maximal ages; if one asks whether a certain person belongs to that class, one may simply compare that person's age with the minimal and maximal ages; if his age lies outside the range, one may safely answer that the person does not belong to the class; if it does not, one may only answer "I don't know".

The level of abstraction included in a programming language can influence its overall [[usability]]. The [[Cognitive dimensions]] framework includes the concept of ''abstraction gradient'' in a formalism. This framework allows the designer of a programming language to study the trade-offs between abstraction and other characteristics of the design, and how changes in abstraction influence the language usability.

Abstractions can prove useful when dealing with computer programs, because non-trivial properties of computer programs are essentially [[undecidable]] (see [[Rice's theorem]]). As a consequence, automatic methods for deriving information on the behavior of computer programs either have to drop termination (on some occasions, they may fail, crash or never yield out a result), soundness (they may provide false information), or precision (they may answer "I don't know" to some questions).

Abstraction is the core concept of [[abstract interpretation]]. [[Model checking]] generally takes place on abstract versions of the studied systems.

==Levels of abstraction==
{{Main|Abstraction layer}}

Computer science commonly presents ''levels'' (or, less commonly, ''layers'') of abstraction, wherein each level represents a different model of the same information and processes, but uses a system of expression involving a unique set of objects and compositions that apply only to a particular domain.
<ref>[[Luciano Floridi]], [http://www.philosophyofinformation.net/pdf/latmoa.pdf ''Levellism and the Method of Abstraction'']
IEG – Research Report 22.11.04</ref>
Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level, which tends to provide an increasingly "granular" representation. For example, gates build on electronic circuits, binary on gates, machine language on binary, programming language on machine language, applications and operating systems on programming languages. Each level is embodied, but not determined, by the level beneath it, making it a language of description that is somewhat self-contained.

===Database systems===
{{Main|Database management system}}

Since many users of database systems lack in-depth familiarity with computer data-structures, database developers often hide complexity through the following levels:

[[Image:Data abstraction levels.png|thumb|Data abstraction levels of a database system]]

'''Physical level:''' The lowest level of abstraction describes ''how'' a system actually stores data. The physical level describes complex low-level data structures in detail.

'''Logical level:''' The next higher level of abstraction describes ''what'' data the database stores, and what relationships exist among those data. The logical level thus describes an entire database in terms of a small number of relatively simple structures. Although implementation of the simple structures at the logical level may involve complex physical level structures, the user of the logical level does not need to be aware of this complexity. [[Database administrator]]s, who must decide what information to keep in a database, use the logical level of abstraction.

'''View level:''' The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of a database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many [[view (database)|view]]s for the same database.

===Layered architecture===
The ability to provide a [[design]] of different levels of abstraction can

* simplify the design considerably
* enable different role players to effectively work at various levels of abstraction

[[Systems design]] and [[Business process modeling|business process design]] can both use this. Some [[Software modeling|design processes]] specifically generate designs that contain various levels of abstraction.

Layered architecture partitions the concerns of the application into stacked groups (layers).
it is a technique used in designing computer software, hardware, and communications in which system or network components are isolated in layers so that changes can be made in one layer without affecting the others.

==See also==
* [[Abstraction inversion]] for an anti-pattern of one danger in abstraction
* [[Abstract data type]] for an abstract description of a set of data
* [[Algorithm]] for an abstract description of a computational procedure
* [[Bracket abstraction]] for making a term into a function of a variable
* [[Data modeling]] for structuring data independent of the processes that use it
* [[Encapsulation]] for the categorical dual (other side) of abstraction
* [[Greenspun's Tenth Rule]] for an aphorism about an (the?) optimum point in the space of abstractions
* [[Higher-order function]] for abstraction of functions as parameters
* [[Lambda abstraction]] for making a term into a function of some variable
* [[Program refinement|Refinement]] for the opposite of abstraction in computing
* [[Substitution]] for the categorical left adjoint (inverse) of abstraction

==Notes==
{{FOLDOC}}
<references/>

==Further reading==
* Abelson, Harold, Gerald Jay Sussman with Julie Sussman. (1996) ISBN 0-262-01153-0 ''[[Structure and Interpretation of Computer Programs]] (Second edition)''. The MIT Press (See [http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html MIT.edu])
* Joel Spolsky. [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Joelonsoftware.com] ''The Law of Leaky Abstractions.'' 2002-11-11.

{{DEFAULTSORT:Abstraction (Computer Science)}}
[[Category:Data management]]
[[Category:Programming paradigms]]
[[Category:Articles with example Java code]]

[[af:Abstraksie (rekenaarwetenskap)]]
[[bs:Računarska apstrakcija]]
[[da:Abstraktion (datalogi)]]
[[es:Abstracción (informática)]]
[[fa:انتزاع (رایانه)]]
[[fr:Abstraction (informatique)]]
[[ko:추상화 (전산학)]]
[[it:Astrazione (informatica)]]
[[ms:Pengabstrakan (sains komputer)]]
[[ja:抽象化 (計算機科学)]]
[[pl:Abstrakcja (programowanie)]]
[[pt:Abstração (programação)]]
[[ru:Абстракция данных]]
[[sh:Kompjuterska apstrakcija]]
[[tr:Soyutlama (bilgisayar bilimi)]]
[[uk:Абстрагування (програмування)]]