The Symbian OS (779886), страница 14
Текст из файла (страница 14)
Charles Davies, now Symbian CTO, wasthe early architect of the higher layers of the operating system.Charles Davies:I remember looking at Windows at that time and thinking that this is all verywell, here is this Windows API, but just look what’s happening underneath it,it was ugly.
I wanted something that you could look inside of.The early ‘ethic of robustness’, to use his phrase, came straight fromthe product vision.Managing the Bounds of the SystemIn some ways, the hardest thing of all for Symbian is managing the impactof its business model on the properties of the system and, in particular,the problem that Charles Davies calls ‘defining the skin’ – understanding,maintaining, and managing the bounds of the system under the impactof the business model. As well as originating the requirements push andfeeding the requirements pipeline, generating almost all of the externalpressure on the system to evolve and grow, licensees and partners alsocreate their own extensions to the system.
(S60, arguably, is the mostextreme example, constituting a complete system in itself, at around twicethe size of the operating system.)Being clear where to draw the boundary between the responsibilitiesof Symbian OS and the responsibilities of GUIs, in terms of who makeswhat and where the results fit into the architecture, becomes difficult.Charles Davies is eloquent on the subject.Charles Davies:One of the things I’ve done since being here is to try and identify wherethe skin of Symbian OS is, to define the skin. When I was at Psion and wewere building a PDA, I understood where the PDA ended and where thethings outside the PDA began, and so I knew the boundaries of the product.And then I came to Symbian and Symbian OS, and I thought, where are theboundaries? It’s really tough to know where the boundaries are, and I stillsometimes wonder if we really know that.
That’s debilitating from the point ofview of knowing what to do. In reality we’re trying to fit some kind of rationalWHY ARCHITECTURE MATTERS51boundary to our throughput, because you can’t do everything. We’ve got, say,750 people in software engineering working on Symbian OS, and we can’tmake that 1500 and we don’t want to make that 200.
So with 750 people,what boundary can we draw that matches a decent product?In one sense the problem is particular to the business model that Symbian has evolved, and is less a question of pure technology management,which to some extent takes care of itself (or should, with a little help tobalance the sometimes competing needs of different licensees), than ofdriving the operating system vision in the absence of a wider productvision. In that wider sense, the licensees have products; Symbian OS hastechnologies and it is harder to say what the source of the technologyvision for the operating system itself should be. To remain at the frontof the field, Symbian OS must lead, but on the whole, customers wouldprefer that the operating system simply maps the needs of their ownleading products.
The problem is that by the time the customer productneed emerges, the operating system is going to be too late if it cannotalready support it. (At least, in the case of complex technologies and,increasingly, all new mobile technologies are complex.) Customers therefore build their own extensions or license them from elsewhere, and theoperating system potentially fails under the weight of incompatibilities ormissing technologies).Product companies are easier to manage than technology companiesbecause it is clear what product needs are; either they align with themarket needs or the product fails in the market.
The Symbian modelis harder and forever raises the question of whether Symbian is simplya supplier or integrator to its customers, or an innovator. Is Symbian aproduct company, where the operating system is the product, or does itmerely provide a useful ‘bag of bits’?Architecture is at the heart of the answer. If there is an architecture todescribe, then there is more to the operating system than the sum of itsparts.Managing Competitive ThreatsThere are many external threats to Symbian OS.
Some of the threats arehousehold names. Microsoft is an obvious threat, but the likelihood is thatMicrosoft itself will always be unacceptable to some part of the market,whatever the quality of its technology offering. (It is hard to see Nokiaphones, for example, sharing branding with Microsoft Windows, and thesame issues no doubt apply to some network operators, but clearly not toall of them.) It is almost as certain that Nokia in turn is unacceptable tosome other parts of the market. S60 aims at building a stable of licensees,vendors for whom the advantages of adopting a proven, market-ready52INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSuser interface outweigh the possible disadvantages of licensing a solutionfrom a competitor, or the costs of developing an in-house solution.
Therewill always be vendors, though, for whom licensing from Nokia is likelyto be unacceptable. Interestingly, the more Microsoft resorts to brandingits own phones, in order to increase market share, the more it competeswith those it is seeking to license to. It is hard to see any scenario in whichthe phone market could become as homogeneous as the PC market.Linux is also a clear and visible threat, even though again there arenatural pockets of resistance. Linux, for example, is viral.
Linux doesnot just take out competitors, it takes out whole parts of the softwareeconomy, and it is not yet clear what it replaces them with.7 To putLinux in a phone, for example, seems to require just the same ‘old’software economy as to put any other operating system into a phone,dedicated software development divisions which do the same things thatother software development divisions do: write code, miss deadlines, fixdefects, pay salaries. Linux may be royalty-free, but that translates into‘not-free-at-all’ if you have to bring it inside your own dedicated softwaredivision.
Nonetheless, to ignore Linux would be a (possibly fatal) mistake.Architecture is part of the answer. If Symbian OS is a better solution,it is because its architecture is more fit for purpose than that of itscompetitors, not because its implementation is better. Implementationis a second-order property, easy to replace or improve. Architecture, incontrast, is a deep property.3.4 Symbian OS Layer by LayerThe simplest architectural view of Symbian OS is the layered view givenby the Symbian OS System Model.8UI Framework LayerThe topmost layer of Symbian OS, the UI Framework layer provides theframeworks and libraries for constructing a user interface, including thebasic class hierarchies for user interface controls and other frameworksand utilities used by user interface components.The UI Framework layer also includes a number of specialist, graphicsbased frameworks which are used by the user interface but which arealso available to applications, including the Animation framework, theFront End Processor (FEP) base framework and Grid.The user interface architecture in Symbian OS is based on a coreframework called Uikon and a class hierarchy for user interface controls7Where it is clear, it is not clear how to make a profit from what it replaces them with.The System Model (see Chapter 5) is relatively constant across different releases,although its details evolve to track the evolution of the architecture.8SYMBIAN OS LAYER BY LAYER53called the control environment.
Together, they provide the frameworkwhich defines basic GUI behavior, which is specialized by a concreteGUI implementation (for example, S60, UIQ or MOAP), and the internal plumbing which integrates the GUI with the underlying graphicsarchitecture.Uikon was originally created as a refactoring of the Eikon user interface library, which was part of the earliest versions of the operatingsystem. Uikon was created to support easier user interface customization,including ‘pluggable’ look-and-feel modules.The Application Services LayerThe Application Services layer provides support independent of the userinterface for applications on Symbian OS. These services divide into threebroad groupings:• system-level services used by all applications, for example the Application Architecture or Text Handling• services that support generic types of application and application-likeservices, for example personal productivity applications (vCard andvCal, Alarm Server) and data synchronization services (OMA DataSync, for example); also included are a number of key applicationengines which are used and extended by licensees (Calendar andAgenda Model), as well as legacy engines which licensees maychoose to retain (Data Engine)• services based on more generic but application-centric technologies,for example mail, messaging and browsing (Messaging Store, MIMERecognition Framework, HTTP Transport Framework).Applications in Symbian OS broadly follow the classic object-orientedModel–Viewer–Controller (MVC) pattern.
The framework level supportencapsulates the essential relationships between the main applicationclasses (representing the application data model, the views onto it, andthe document and document user interface that allow it to be manipulatedand persisted) and abstracts all of the necessary underlying system-levelbehavior. In principle, a complete application can be written without anyfurther direct dependencies (with the exception of the User Library).The Application Services layer reflects the way that the system as awhole has evolved.
On the one hand, it contains essential applicationengines that almost no device can do without (the Contacts Model forexample), as well as a small number of application engines that aremostly now considered legacy (e.g. the WYSIWYG printing services andthe office application engines, including Sheet Engine, a full spreadsheetengine more appropriate for PDA-style devices). On the other hand, itcontains (from Symbian OS v9.3) the SIP Framework, which provides thefoundation for the next generation of mobile applications and services.54INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSJava MEIn some senses, Java does not fit neatly into the layered operating systemmodel.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
