The Symbian OS (779886), страница 13
Текст из файла (страница 13)
Manyof these principles evolved as responses to the product ethos that wasdominant when the system was first being designed.2 That ethos can besummarized in a few simple rules.• User data is sacred.• User time is precious.• All resources are scarce.And perhaps this one too, ‘while beauty is in the eye of the beholder,elegance springs from deep within a system’.In Symbian OS, that mantra is taken seriously.
What results is a handfulof key design principles:• ubiquitous use of servers: typically, resources are brokered by servers;since the kernel itself is a server, this includes kernel-owned resourcesrepresented by R classes1‘Bottom up’ and ‘informal’ typify the Unix design approach, see [Raymond 2004,p. 11].2That is, the ethos which characterized Psion in the early-to-mid 1990s. By then, thecompany was a leader in the palmtop computer market. It was a product company.46INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OS• pervasive asynchronous services: all resources are available to multiple simultaneous clients; in other words, it is a service request andcallback model rather than a blocking model• rigorous separation of user interfaces from services• rigorous separation of application user interfaces from engines• engine reuse and openness of engine APIs.Two further principles follow from specific product requirements:• pervasive support for instant availability and instant switching ofapplications• always-on systems, capable of running forever: robust managementand reclaiming of system resources.Symbian OS certainly aims at unequaled robustness, making strongguarantees about the integrity and safety (security) of user data and theability of the system to run without failure (to be crash-proof, in otherwords).
From the beginning, it has also aimed to be easy and intuitiveto use and fully driven by a graphical user interface (GUI). (The originalconception included a full set of integrated applications and an attractive,intuitive and usable GUI; ‘charming the user’ is an early Symbian OSslogan.3 )Perhaps as important as anything else, the operating system set outfrom the beginning to be extensible, providing open application programming interfaces (APIs), including native APIs as well as support for theVisual Basic-like OPL language and Java, and easy access to SoftwareDevelopment Kits (SDKs)4 and development tools.However, systems do not stand still; architectures are dynamic andevolve. Symbian OS has been in a state of continuous evolution since itfirst reached market in late 2000; and for the three years before that it hadbeen evolving from a PDA operating system to one specifically targetingthe emerging market for mobile phones equipped with PDA functions.
Inview of this, it may seem remarkable that the operating system exhibitsas much clarity and consistency in design as it does.3For example, see almost anything written by David Wood. Today, the GUI is no longersupplied by Symbian, however GUI operation remains intrinsic to the system design. Theoriginal integrated applications survive in the form of common application engines acrossmultiple GUIs, although their inclusion is a licensee option.4Symbian no longer directly supplies SDKs, since these are GUI-dependent. Symbianprovides significant ‘precursor’ content to licensees for inclusion in SDKs, including thestandard documentation set for Symbian OS APIs.DESIGN GOALS AND ARCHITECTURE47Architectures evolve partly driven by pressures from within the systemand partly they evolve under external pressures, such as pressures fromthe broad market, from customers and from competition.Recent major releases of Symbian OS have introduced some radicalchanges, in particular:• a real-time kernel, driven by evolving future market needs, in particular, phone vendors chasing new designs (for example, ‘single core’phones) and new features (for example, multimedia)• platform security, driven by broader market needs including operator,user and licensee needs for a secure software platform.While both are significant (and profound) changes, from a systemperspective they have had a relatively small impact on the overall shapeof the system.
Interestingly, in both cases the pressure to address theseparticular market needs arose internally in Symbian in anticipation of thefuture market and ahead of demand from customers.It is tempting to idealize architecture. In the real world, all software architecture is a combination of principle and expediency, purityand pragmatism. Through the system lifecycle, for anything but theshortest-lived systems, it is part genuine, forward-looking design and partretrofitting; in other words, part architecture and part re-architecture.Some of the patterns that are present in Symbian OS were also present(or, in any case, had been tried out) in its immediate precursors, theearlier Psion operating systems.
The 16-bit operating system (SIBO) hadextended the basic server-based, asynchronous, multitasking model ofprevious Psion products and re-engineered it using object-oriented techniques. SIBO also pioneered the approach to GUI design, designedcommunications services into the system at a deep level, and experimented with some idioms which have since become strongly identifiedwith Symbian OS (active objects, for example).In fact, surprisingly many features of Symbian OS have evolved fromfeatures of the earlier system:• the fully integrated application suite: even though Symbian OS nolonger includes a user interface or applications, it remains stronglyapplication-centric• ubiquitous asynchronous services• optimization for battery-based devices• optimization for a ROM-based design: unlike other common operating systems, SIBO used strategies such as ‘execute-in-place’ (XIP)(compare this with MS-DOS, which assumes it is loaded into RAM48INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSto execute) and re-entrancy5 (MS-DOS is non-re-entrant), as well as adesign for devices with only solid-state disks• sophisticated graphical design: from the beginning, SIBO supportedreactive repainting of windows and overlapping windows, in an ageof tiled interfaces (for example, Windows 2.0 and the charactermode multitasking user interfaces of the day, such as TopView andDesqView)• an event-driven programming model• cross-platform development: the developers’ mindset was more thatof embedded systems engineering than the standard micro-computeror PC model.6SIBO also introduced some of the programming constraints whichshow up in Symbian OS, for example forbidding global static variablesin DLLs (because the compilers of the day could not support re-entrantDLLs), an early example of using the language and tools to constraindeveloper choices and enforce design and implementation choices, aconsistent theme in Symbian’s approach to development.Symbian OS, or EPOC as it was then, was able to benefit from theexperience of the earlier implementation in SIBO.
The 16-bit system was,in effect, an advanced prototype for EPOC.Meanwhile, of course, Symbian OS has continued to evolve. In particular, some crucial market assumptions have changed. Symbian OSno longer includes its own GUI, for example; instead it supplies theframework from which custom, product-ready GUIs such as S60, MOAPand UIQ are built. Hardware assumptions have changed quite radicallytoo. Execute-in-place ROMs, for example, depend on byte-addressableflash silicon (so-called NOR flash); more recently, non-byte-addressableNAND flash has almost wholly superseded NOR flash, making execute-inplace a redundant strategy. Other technology areas, for example displaytechnologies, have evolved almost beyond recognition compared to the4-bit and 8-bit grayscale displays of earlier times.
Not least, the telephony standards that drive the market have evolved significantly sincethe creation of the first mobile phone networks.Despite sometimes radical re-invention and change, the original designconception of Symbian OS is remarkably intact.5In designing for re-entrant DLLs (that is, re-entrant shared libraries), SIBO was significantly in advance of the available tools. For example, C compilers were poor in this area.Geert Bollen makes the point that it is not just language features that determine whether agiven language is suitable for a particular project; the tools infrastructure that supports thelanguage is equally important.6It is interesting to note that Bill Gates has identified as one of Microsoft’s key strengths(and, indeed, a key competitive advantage), that it develops all of its systems on its ownsystems.
The advantage breaks down completely in the mobile phone context.WHY ARCHITECTURE MATTERS493.2 Basic Design Patterns of Symbian OSThe design principles of a system derive from its design goals and arerealized in the concrete design patterns of the system. The key designpatterns of Symbian OS include the following:• the microkernel pattern: kernel responsibilities are reduced to anessential minimum• the client–server pattern: resources are shared between multiple users,whether system services or applications• frameworks: design patterns are used at all levels, from applications(plug-ins to the application framework) to device drivers (plug-ins tothe kernel-side device-driver framework) and at all levels in between,but especially for hardware adaptation-level interfaces• the graphical application model: all applications are GUI and onlyservers have no user interface• an event-based application model: all user interaction is capturedas events that are made available to applications through the eventqueue• specific idioms aimed at improving robustness: for example, activeobjects manage asynchronous services (in preference, for example,to explicit multi-threading) and descriptors are used for type-safe andmemory-safe strings• streams and stores for persistent data storage: the natural ‘document’model for applications (although conventional file-based applicationidioms are supported)• the class library (the User Library) providing other user services andaccess to kernel services.3.3 Why Architecture Matters‘Doing architecture’ in a complex commercial context is not easy.Arguably all commercial contexts are complex (certainly they are alldifferent), in which case architecture will never be easy.
However, thebusiness model for Symbian OS is particularly complex. While it mustbe counted as part of Symbian’s success, it also creates a unique setof problems to overcome and work around, and to some extent thoseproblems are then manifested as problems for software architecture.Architecture serves a concrete purpose; it makes management of thesystem easier or more difficult, in particular:50INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OS• managing the functional behavior and supported technologies• managing the size and performance• retaining the ability to evolve the system.Elegance, consistency, and transparency were all early design driversin the creation of the system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
