The Symbian OS (779886), страница 29
Текст из файла (страница 29)
Unlike C++ and likeSmalltalk, it is a purely class-based language, with an Object rootclass.• Native number, character and string types are defined by the language;all other types (including all user-defined types) are objects.• Every object is an instance of a class and every class is a subclass ofanother class, except for the root class.• Objects are created from classes by constructor methods and aredeleted by destructor methods, which may be defined (for complexclasses) or default to standard methods if not defined.• Objects can control access to their data and method members bydeclaring them private, shared or public.• Values can be made immutable by declaring them const, and allobjects can be passed by value, by reference or by pointer.• Separation of interface from implementation is enforced. Every classconsists of an interface definition and an implementation specificationin separate files, with only one class per file.• Unlike C++, all objects are run-time polymorphic (all methods employlate binding).• Garbage collection is automatic.
All program resources are cleanedup and recovered by the VM when a program completes (or isterminated).Java’s success has been striking and, in many ways, it is a modellanguage. However, compared with C++, it is relatively inflexible and108INTRODUCTION TO OBJECT ORIENTATIONconstrained (by design) and its deliberate isolation from the underlyingdevice makes it generally unsuitable as a system-level language.Microsoft has made its own attempt at improving Java and providing amanaged-code solution of its own (for the .NET services platform, whichcompetes with Java) in the form of C#. As a language, C# contains someinteresting features, including a reflection model. However, the historyof C#, which first emerged as a set of unilateral Java extensions, makes itsomewhat unconvincing as a genuine language advance.Other Languages: Objective-C, Eiffel and Modula-3Objective-C was written by Brad Cox in the early 1980s.
It has a visibleSmalltalk influence, for example in some of its syntax, and in its adoptionof run-time typing (in contrast to C, C++ and Java). Also unlike C++, it isa true superset of ANSI C, that is, it is a pure extension of C that leavesthe core of C unrefined.It was adopted for the NeXTStep, which employed a Mac-based flavorof Unix, and from there it was inherited by Mac OS X, in which it remainshighly visible. (For native application development, the object hierarchyremains based on Objective-C, complete with the NeXTStep, i.e. NS,class-naming convention.) Objective-C was also an explicit influence and,indeed, the inspiration and model, for the Psion in-house object-flavoredC that preceded the adoption of C++ for what became Symbian OS.Eiffel emerged at around the same time as Objective-C, that is, afterSmalltalk but before C++ had become dominant.
Eiffel was designed asa commercial, pure object-oriented language intended to compete withSmalltalk, with a more conventional syntax. It included a comprehensiveand pure object-oriented class library, including ready-to-go container,collection and iterator classes, well in advance of anything comparablein the C++ world.
(The C++ Standard Template Library emerged wellafter the C++ language.)In the Pascal lineage, Modula-3 evolved by way of Modula-2, addingobject-oriented features and garbage collection.27 Both Eiffel and Modula3 are influenced by Simula, but while Simula and C++ allow a choicebetween static and dynamic binding, with dynamic binding provided viavirtual methods, Eiffel and Modula-3 offer a pure polymorphic modelwith universal dynamic typing and run-time binding, for which run-timeefficiency is the trade-off.In other respects, both languages share similarities with C++.
Classes inthese languages are elaborations of the concept of a record, a descriptionof a list of fields together with the methods that operate on them (justas C++ classes are elaborations of the concept of a C struct; structs andrecords are, in essence, synonymous). Again like C++, both Eiffel andModula-3 allow multiple inheritance.27According to www.m3.org, the language was first defined in 1989.Part 2The Layered Architecture View5The Symbian OS Layered Model5.1 IntroductionThis book explains the architecture of Symbian OS using the systemmodel (see the fold-out and Figure 5.1), which represents the operatingsystem as a series of logical layers with the Application Services and UIFramework layers at the top, the Kernel Services and Hardware Interfacelayer at the bottom, sandwiching a ‘middleware’ layer of extended OSServices.In a finished product, for example a phone, Symbian OS providesthe software core on top of which a third-party-supplied ‘variant’ userinterface (UI) provides the custom GUI with which end-users interact andwhich directly supports applications.
Typically, the variant user interface,including the custom applications supplied by the phone manufacturer,is considerably bigger than Symbian OS itself.Beneath the operating system, a relatively small amount of custom,device-specific code (consisting of device drivers and so on), insulatesSymbian OS from the actual device hardware.5.2 Basic ConceptsThe remainder of this chapter summarizes the key concepts of the systemmodel and then describes the operating system layer by layer, starting atthe top with the UI Framework and working down to the Kernel Servicesand Hardware Interface layer.The basic approach taken by the model is to decompose the operatingsystem into layers, and to further decompose the layers as necessaryinto blocks and sub-blocks before finally arriving at collections ofindividual components.
Layers are the highest level abstraction in themodel; components are the lowest level abstraction, the fundamental112THE SYMBIAN OS LAYERED MODELSymbian OSUIFrameworkApplicationServicesOSServicesBaseServicesKernelServices &HardwareInterfaceFigure 5.1Symbian OS layered system modelunits of the model; blocks and sub-blocks decompose layers by functionality – roughly speaking, by broad technology area. The key conceptsused by the system model therefore are layers, blocks and sub-blocks,component collections and components.Components provide the essential mapping from the logical model tothe concrete system.
While layers, blocks and sub-blocks are essentiallylogical concepts, components are physically realized in software, typically consisting of multiple files in the operating system delivery (e.g.source code files including test code; built executables including libraries;data and configuration files; build files; and documentation). However,from the perspective of the model, components are treated atomicallyand constitute the smallest units of architectural interest.The complete component set shown in any particular version of themodel represents the superset of all components delivered by that releaseof the operating system and intended to run on any Symbian OS device,whether a phone or some other product, a development board or othertest hardware, or an emulator build of the system running on a hostoperating system (such as Microsoft Windows).Test components and tools are considered outside the scope of theSymbian OS model, although they form an essential part of the modelof the complete delivery of the operating system as shipped by SymbianBASIC CONCEPTS113to customers.
(They are shown in a full product model as the SymbianToolkit.)Because the model reflects the concrete system, a new version ofthe model is published for each release of Symbian OS. The model hasalso evolved in its own right since the first versions were published forSymbian OS v7, in particular to bring it closer to the concrete system.LayersThe model adopts a conventional software architecture interpretation oflayers [Buschmann et al.
1996]: each layer abstracts the functionality ofthe layer beneath and provides services to the layer above.Within each layer, components are either grouped directly into collections according to functionality (and to some extent also accordingto collaborations and shared dependencies); or are grouped into collections within blocks and possibly sub-blocks, which are broadly based ontechnologies.The goal of the model is to impose manageable granularity ontothe operating-system architecture, to make it easier to understand andto navigate.
Hence, layers are useful approximations of structure, notprecise specifications of architectural relationships. There is no concretemechanism that instantiates layers in the existing system (i.e. there is nomake file or equivalent).However, the broad principles of the layering hold good: althoughthere are some exceptions, dependencies in general flow downwards fromhigher layers to lower layers; and dependencies in the reverse directionare considered to be anomalies. In general, services are abstractedthrough the layers, with higher layers abstracting the services of lowerlayers, although for reasons of efficiency there is no requirement thatlayers only access the services of the layer immediately below them; thusthe functionality of lower layers is accessible to all layers above.One reason for showing the system as layered is to show how system functionality is increasingly abstracted away from hardware (at thebottom) and towards users (at the top); successive groups of tasks areincreasingly abstracted from more basic tasks.
A widely accepted principle for creating a layered model of a system is the ‘inverted pyramid ofreuse’, characterized by the slogan ‘Keep the base layer slim’ [Buschmannet al. 1996, p. 39].1Layers in the system model are defined with the following guidelinesin mind:1‘Layers’ is a well known architectural pattern, the best known example probably beingthe OSI Seven-Layer Model. The Layers pattern is described and discussed in [Buschmannet al. 1996].114THE SYMBIAN OS LAYERED MODEL• all the services provided by a layer are at a similar level of abstraction• a layer is relatively logically cohesive and relatively self-contained(both inexact terms, used with commonsense meaning)2• a layer provides services to higher layers (‘upwards’)• a layer delegates tasks to lower layers (‘downwards’)• dependencies flow consistently from higher layers to lower layers (butdependencies are allowed sideways within layers)• requests travel downwards• notifications travel upwards• higher layers abstract the services of lower layers away from machinecentric services towards user-visible functionality• a layer provides services as far as possible via well-defined external interfaces, which can be separated from the internal interfacesavailable within the layer• a layer could be a delivery unit (although, in the current system, nolayer is delivered independently).BlocksA block or sub-block in the system model (see Figure 5.2) roughlycorresponds to a ‘technology domain’.Blocks are used as a pragmatic way of partitioning layers into meaningful divisions according to commonsense criteria, with sub-blocksproviding finer grained divisions for convenience.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
