System Models
Downloads
The System Models can be downloaded in either PDF or SVG form. You need to download the Adobe SVG Viewer plug-in in order to view them in SVG form. You can download the plug-in here.
Dependencies
In the SVG models for Symbian OS v9.1 and later, dependencies are visible as lines between components, with the arrow pointing to component depended upon. The lines are visible by mousing-over a component. The black lines show the other components it uses, and the blue lines show which components use it.
The models are best viewed in Internet Explorer. Firefox and Opera provide minimal SVG support.
What's New in the System Model for Symbian OS v9.4?
(Ben Morris)This paper introduces the latest version of the System Model and looks at what's new in the model, what's new in the operating system and at how the model is being used as a tool for understanding and managing the operating system itself. Read the paper
Symbian OS v9.4 System Model
Download the PDF Download the SVG
Symbian OS v9.3 System Model
Download the PDF Download the SVG
Symbian OS v9.2 System Model
Download the PDF Download the SVG
Symbian OS v9.1 System Model
Download the PDF Download the SVG
Symbian OS v8.1 System Model
Download the PDF Download the SVG
Symbian OS v8.0 System Model
Download the PDF Download the SVG
Symbian OS v7.0s System Model
Download the PDF Download the SVG
Symbian OS v7.0 System Model
Download the PDF Download the SVG
The System Model is a high-level overview of the Symbian OS architecture. The components of the OS are grouped in hierarchical entities to show their relationships to each other.
Layers are the largest grouping, and are stacked on top of each other, with the lowest-level components on bottom and layers with the highest-level components on top. In general, each layer provides an abstraction of the functionality of the layer below it. Dependencies should only go to the same layer or downward – they should never go up. Inter-layer communication occurs downward in the form or “requests” (i.e. function calls) and upward in the form of notifications (return values or callbacks). Components can be further grouped into blocks and sub-blocks. A block generally contains a single technology, and can be further subdivided into sub-blocks to show relationships within the technology.
Collections of components appear as white boxes and group together tightly-coupled components which tend to be most useful when used together. Generally these will either need each other in order to function or be conceptually similar in usage. Collections can be stacked vertically in order to show the flow of information. The collections on top abstract the APIs of the collections beneath.
While all versions of the System Model have the same basic structure, each one is created for a specific version of the OS. The version number will always appear in the bottom-right corner.
Interface access
The colours on the System Model show the intended audience of developers using the component. Blue components are at least partly available for use for all developers. Orange components are only available to Symbian and its partners. Red components are for Symbian internal use only. These restrictions determine what documentation appears in SDKs.Note that while some components might not be directly available for use, their functionality is usually available through other components. This interface access mechanism was not formalized until Symbian OS v8.1, so all older models appear entirely in blue.
Component inclusion
The shape of the component is based on the agreement under which it is delivered to Symbian licensees (as specified in Schedule 12 of the Customisation Kit License). Essentially this indicates the requirements for a component appearing in any given phone or licensee SDK. A Common Symbian component must appear on Symbian devices. A Common Replaceable component can be replaced by a licensee with one with the same functionality.
An Optional Symbian component may or may not appear in a licensee device, but if it does, they must use the Symbian component. Licensees have no obligation to include an Optional Replaceable component in the product. Finally, a Test/Reference component (drawn as an octagon) is for testing purposes only and will not appear in the same form in a product. A Reference component is further identified by diagonal white stripes across the component. This means that the component may be used as a guide or basis for a production component.
Plug-ins
A component with a thick border is a Plug-in component. This means it exposes a standard interface that is defined outside of the component. In other words, a plug-in will always have some framework by which its functionality is exposed. For example, Web Recognisers and MMF Recognisers are both plug-ins that implement the recognisers defined in the MIME Recognition Framework.