Symbian System Model
From Symbian Developer Community
This article describes the system model representation of the Symbian Foundation platform. It includes an explanation of the terminology used by architects to describe the Symbian platform and the principles and criteria underlying the structure of the system model.
You can listen to Daniel Rubio describe the system model here.
Contents |
Audience
This article is suitable for application developers and developers contributing to the Symbian platform. You will find this article useful whether you are familiar with the platform or you are completely new to the platform.
Structure of Article
This article is structured as follows:-
- Overview of the system model, entities and the principles used to create it
- The system model representation of the Symbian Foundation platform
- For each of the entities within the system model, the article provides:
- A description of the entity
- An explanation of the criteria used to define the entity
- Any other relevant information
- A link to the list of actual values for the entity for the Symbian Foundation platform
- An example of the entity for the Symbian Foundation platform, where applicable
If you have previously worked with the Symbian OS system model, please note the following:
- The Symbian Foundation platform combines the previously available Symbian OS and S60 platforms. Therefore, the platform architecture view has been modified to better reflect the consolidated platform (for example, the definition of the layers and packages).
- Although the Symbian Foundation platform system model and the earlier Symbian OS system model share many common features, there are several significant differences (for example, the entities used to describe different levels of software functionality).
Also note that all examples contain or are from a single package, the Classic UI package, (see Packages for further information).
Overview of System Model
Introduction
The Symbian system model is a representation of the Symbian platform that enables you to visualize the composition of the system from the highest-level view of the whole platform (the package view model), down to more granular levels for a more detailed picture (the collection view model). See Figure 1, the platform view.
The system model represents the Symbian platform in a way that is:
- Layered
- Hierarchical
- Shows dependencies.
There are two ways to view the system model:
The package view model offers a high-level view of the overall structure – the layers, technology domains and packages within the platform – and is particularly useful for:
- System architects, allowing them to understand how a new functionality will affect the system
- Business managers, enabling them to understand how Symbian OS compares with other operating systems (that is, to understand what is and is not included in the system).
The collection view model provides a more detailed view of the entities within the platform – and is particularly useful for:
- Developers, helping them to understand where they work on the system and what dependencies they are allowed to create. It also enables easy navigation to access files, owner, and so on.
- Integration engineers, permitting them to understand what has to be included to build the product they want.
The different views allow us to gain a clear understanding of what is included within the Symbian platform, and how the platform is architected. The system model is encoded by an XML file from which different visual representations (SVG files) of the platform, representing different views of the platform, have been made available.
Structure
The platform view (Figure 1) is the highest-level system model, and provides a view of the complete platform architecture. Figure 1 shows a simplified, generic version of the new system model, and examples of each type of entity that may be contained within it.
Key
Figure 1 Platform view - collection view model
Note that the current System Model visualisations for the Symbian Platform do not display down to the level of components within collections as shown above, ie the lowest granularity of entity displayed is a Collection. However components entities are still defined within the platform and within the package files for the System Model, and future visualisations will represent them.
The System Model uses a hierarchy of entities to represent the platform. They are listed here from the highest level of granularity to the lowest level of of granularity:-
- Context Diagram
- Layers
- Packages
- Collections
- Components
Also represented within the model is the concept of technology domains, each of which contains a set of packages from across layers.
The highest level System Model diagram is gives a view of the complete platform architecture. As the diagram shows, the platform is constructed from Layers. (The layout of the system model reflects the fact that layers and their subsets may be built independently of each other.) Each layer contains a number of functional Packages. Technology domains group packages from different layers according to their function. Within a package, Collections are aligned in levels that capture their stacking in relation to use. These are often aligned to dependencies. Collections contain one or more Components, which are the smallest unit of architectural interest.
The system model displays dependencies between entities by linking them with lines. This is done at the level of collection dependencies in the collection view model. Note that the model only shows dependencies on statically linked DLLs.
Some general principles were used to create the system model:
- The architecture is a complete decomposition of the system according to defined criteria.
- The architectural decomposition is designed to represent the entities in the system that have architectural relationships with each other. This was done by conducting an analysis of the platform according to a defined set of criteria.
- The most basic architectural relationship is a static-linkage dependency between two entities.
- Architectural entities should be relatively coherent and relatively decoupled.
- This decomposition is ‘complete’ in that every file can be traced back to a component, collection, package and layer, and every file is owned by exactly one component, collection, package and layer.
- Note that all criteria should be regarded as general rules that guide but do not completely determine the decomposition.
The Symbian Foundation Platform System Model
Overview
The scope of the Symbian Foundation platform system model encompasses all packages which are made available by the Symbian Foundation as part of a device platform release. See Device Platform Releases for more information.
Note that the Symbian Foundation also makes available a Tools platform. As its name suggests, this platform contains a comprehensive set of desktop and device-side tools for use in developing for the Symbian platform (although it should be noted that some tools are still delivered as part of the device platform). See the Tools Platform section which covers the tools model in more detail, the remainder of this article is focused only on the platform system model as defined above.
Also note, however, that the system model is unlikely to represent the architecture of an actual device ROM because different Symbian devices may include only a subset of these packages, and are also likely to include additional device-specific software packages. (See Device-Specific System Models below).
The model is built from data XML files included in the source files for packages, collections and components, allowing them to be represented by the model. The XML syntax used is described in System Definition.
Each of the device platform releases made available by the Symbian Foundation will therefore include a System Model associated with that release.
Link to System Models SVGs
The Symbian Foundation publishes SVG visualizations of the model on its website for each release of the platform. See the current Symbian Foundation platform system models:
- Package view model
- Collection view model: Unavailable at present
For full details on viewing the SVG format, see Using Scalable Vector Graphics.
In particular note that you will need the Adobe SVG Viewer plug-in, which can be downloaded from here if required.
Device-Specific System Models
It is possible for device creators using the Symbian platform to create system models that represent the Symbian Foundation packages included in their specific device.
As noted above, all packages contributed to the Symbian Foundation must include the system model package definition XML. A package that is hosted by the Symbian Foundation but not yet included in an SDPR can be included in a rebuilt system model.
Thus, device-specific system models can be created with the relevant subset of packages if required. For more information on building system models, see information on the System Definition.
System Model Entities
Layers
Description
The layers in the system model represent the fundamental structure of the system itself, and the basic layering should remain constant between releases of the platform. A significant change in the layering between releases would imply major architectural change or a significant re-interpretation of the architecture.
Layer Criteria
- A layer is relatively coherent and relatively decoupled (measured in terms of the coupling of the collections or packages it contains).
- 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 (but dependencies are allowed sideways within layers).
- All the services provided by a layer are at a similar level of abstraction.
- Requests travel downwards.
- Notifications travel upwards.
- Higher layers abstract the services of lower layers away from hardware-specific services towards user-interface functionality.
- A layer provides services, as far as possible, via well-defined external interfaces, which are separable from the internal interfaces available within the layer.
List of Layers
There are currently three layers within the main Symbian Foundation platform (the Device Platform).
- OS layer
- Middleware layer
- Application layer
OS layer The OS layer includes the hardware adaptation layer (HAL) required to support a specific hardware platform and which abstracts all higher layers from actual hardware and the Symbian kernel including physical and logical device drivers. It also includes low-level OS services such as frameworks, libraries and utilities, which turn the abstracted hardware and OS mechanisms into a programmable interface.
It also provides all higher-level OS services across a full range of technology domains such as communications, networking, graphics, multimedia and so on.
Middleware layer The middleware layer represents the functionality that is independent of UI and applications. It provides services to applications (that is, programs with which the user can interact through a user interface) and other higher-level programs. It is independent of hardware and uses the hardware-abstracted services provided by the OS layer.
Services in this layer can be specific application technology such as messaging and multimedia, or more general device services such as web services, security, device management, IP services and so on.
Application layer This layer contains all the applications available as part of the Symbian platform, such as the organizer application suite, multimedia applications, telephony and IP applications, and applications for controlling device settings and so on.
Many applications also provide programmatic interfaces to allow other applications programs to access their functionality, to support extensibility or customization.
Note that some elements of hardware adaptation, such as adaptations to device software when the underlying hardware changes, are done outside of these three Symbian Foundation platform layers.
Levels within layers
The concept of Level within layers and packages show the software stack within these entites. ‘Levels’ refers to the organisation of items within a layer or package – packages can be stacked on top of each other within a layer, and collections can be stacked on top of each other within a package. The level of an item within its parent item reflects its place in the hierarchy in terms of its distance from hardware. A package may include multiple levels according to this definition, and collections in a package could be assigned one of these levels. Similarly levels can be defined and assigned to packages within a layer.
Lower layers are not allowed to statically depend on the higher layers because they need to be buildable and releasable without them. While packages in different layers have ‘hard’ dependency rules (a package must not depend on a package in a higher layer), packages at different levels in the same layer have ‘soft’ dependency rules (a package should not depend on a package in the same layer, but a higher level).
For more details on the interface rules, see the Interface Management section in the Symbian Foundation Architecture documentation Symbian Foundation Device Software Structuring Principles.
Technology Domains
Description
The Symbian Foundation groups its platform packages into technology domains, based on the following factors:
- Packages that have technical relationships to each other and whose evolution may therefore be linked
- Domains that are relevant to the various stakeholders in the Symbian Foundation community.
Technology domains provide an overview of the range of packages relevant to the particular functional area of the platform you are working on or the types of software you are developing.
The master list of the mapping of packages to tech domains is the system model. If anything is out of line with the system model then it is wrong :-)
Each technology domain has its own roadmap, which provides information at a granularity that is in between the high-level platform plan platform roadmaps and the very detailed package roadmaps. The foundation has a team of technology managers who create the technology domain roadmaps by aggregating information from the package roadmaps.
Technology Domain Criteria
Every package is allocated to exactly one technology domain, based on the general functional area to which the package contributes and by which it may be influenced.
By grouping related packages by themes, Symbian Foundation hopes to encourage a strong community to form around them and to generate discussion and review.
Note that the technology domains may include decoupled packages within layers of the platform, and packages across multiple layers of the platform, representing ‘vertical’ functionality. The foundation system model therefore represents technology domains using specific colours for the packages comprising each of the domains. (See the Technology Domain Key at the bottom of the SVG visualization for colour mapping.)
Moving a Package Between Technology Domains
A new package is assigned a technology domain by the Architecture Council as a part of the package creation process. We have defined a simple process for moving a package between technology domains that covers the need for any subsequent changes.
List of Technology Domains
Technology domains are listed in the Technology Domain Index, and in the category: Technology Domains.
The Symbian System Model illustrates the scope of each of the technology domains across the platform packages.
Example of a Technology Domain
User interface
Key
The user interface technology domain comprises all the packages responsible for providing OS, middleware and application layer services for user interface interaction on the Symbian platform. These services may be used internally within the platform or by applications using the platform. For instance, they include graphics and text support, UI frameworks and resources, and common application utilities.
See Technology Domains for more information.
Packages
Description
Packages are the first-level decomposition of layers. Packages are logically grouped modular collections of components.
Package Criteria
- A package is relatively cohesive and relatively decoupled (measured in terms of the coupling of the collections it contains).
- A package provides services to packages in the same layer (‘sideways’) or to packages or collections in higher layers (‘upwards’).
- A package delegates tasks downwards or sideways.
- A package ‘consolidates’ the sum of services provided by the collections it contains as part of its layer.
- A package is not a delivery unit. In other words, it is reasonable to partially deliver, update, or remove a package.
Packages in the Symbian Foundation
Packages are owned and maintained by a package owner, a named individual from an organization member of the Symbian Foundation, but with contributions from the wider community of the Symbian Foundation. Packages are the overall responsibility of the package owner, and further details are published on the Symbian developer website.
The source code for packages can be retrieved from the Mercurial Source Control Management system used to store the Package Repositories. Please see this section for more details: Find Out More About Source Code and Mercurial
Package source repositories and deliveries will include the system model XML files required to include the packages (and collections and components contained within them) within the system model for the platform releases containing those packages. Note that the files include details of the licenses for the source code in a package.
It is the responsibility of Symbian Foundation contributor package owners to maintain and update the system model XML files. For more information on this, see Contributor Guidelines.
Each package has its own source tree, conforming to standard Symbian Foundation guidelines, where all source files and other package files must be contained.
For more details on the contents of packages, see the Anatomy of a Package section of Symbian Foundation Device Software Structuring Principles.
Basic Package Processes
Over the different releases of the paltform packages are subject to be created, split, moved between layers, and eventually deprecated. As such there have to be some basic rules to manage this processes.
Splitting a package
A package carries a maintenance burden in the form of inherited buglist, mercurial repository, etc. Packages are persistant within releases, so splitting a package means that the package remains in its original form in previous release/s, hence it still needs maintenance and owership. Please refer to Splitting Packages for further details.
Example of Package
The Classic UI package lies within the middleware layer and is part of the user interface technology domain.
Figure 3 The Classic UI package
The Classic UI package is responsible for the generic application interface for all Symbian applications. It uses the lower-level support within the Symbian platform, such as the graphics libraries, to provide the top-level interface for applications (for example, frameworks for drawing, handling user input from UI, applications views and data). It includes the fundamental UI and application frameworks as well as advanced features such as application interworking and personalization frameworks.
To illustrate how the system model files are defined for the examples given in this article, I give a snippet of each example’s definition files, as available from the source code repository, after the example. (For more details, see the Contributor Guidelines and XML Model).
Note that the source code for packages can be retrieved from the Mercurial Source Control Management system. The Symbian Foundation hosts each package in a separate Mercurial repository (which comprises a separate repository for each of the branches MCL, RCL and FC. For more information about this, see Package Codelines.
The Classic UI package example above is named classicui and is located at sf/mw/classicui/...
The package_definition.xml defines the package as:
<package id="classicui" levels="base support server generic specific">
Collections
Description
A collection is a set of collaborating components that together deliver a complete, discrete, and identifiable part of the system functionality.
The collections of the baseline system model are derived from an analysis of existing platform functionality to attempt to define plausible architectural groupings. More rigorous criteria may be applied in future, as the system evolves and new functionality is added.
Collections have been defined in terms of coupling between components and source tree organization (that is, common first-level directories). However, there is currently no concrete mechanism (such as build files) that instantiates collections in the platform.
Collection Criteria
- A collection is relatively cohesive and relatively decoupled (measured in terms of the coupling of the components it collects).
- A collection provides services within its package (‘upwards’) or layer (‘sideways’) or to packages or collections in higher layers (‘upwards’).
- A collection delegates tasks downwards or sideways.
- A collection ‘consolidates’ the functionality of the APIs provided by its components into a single, discrete and complete service.
- The service provided by a collection is exported through well-defined and related interfaces.
- A collection is removable from the system without impact on:
- any components in lower layers
- any components in other packages in the same layer.
- A collection is removable from the system with minimal impact on:
- other collections within the same package within the layer.
- No collection is shared between packages or layers.
- No component is shared between collections.
- A component may not be placed on its own in the model; it must be contained within a collection that generalizes the purpose of the component. This implies a collection is the smallest entity that may exist in system model independently in a package.
Collection Representation
- A completely gray box indicates the collection is fully included in the initial Symbian Foundation platform.
- A gray box with coloured shading indicates potential committed contributions:
- A yellow shade indicates that the contribution is expected in 2009.
- A blue shade indicates that the contribution is expected after 2009.
- A white box with a bold outline indicates the collection is not included in the initial Symbian Foundation platform, but is a potential future contribution.
- A white box outlined by a dotted line indicates that the collection is currently only partially included in the initial Symbian Foundation platform, but that the full collection is a potential future contribution.
List of Collections
The initial Symbian Foundation device platform release contains in the region of 560 collections.
Example of Collection
The Common UI Support collection is one collection within the Classic UI package.
Figure 4 The Common UI Support collection
The Common UI Support collection is responsible for general utility libraries and other support functionality that can be used by the UI and application frameworks that provide the interface for Symbian applications. These include general UI error resolution and adaptable look and feel support.
The Common UI Support collection is named commonuisupport and is located within the classicui directory sf/mw/classicui/commonuisupport/...
The collection is defined as:
<collection id="commonuisupport" name="Common UI Support" level="support">
Components
Description
A component is the smallest architectural unit of the system. A component is understood as an implementation unit that provides a discrete, reusable piece of the system.
In concrete terms, a component is identified as a single package of binaries, data, documentation, tests and source code. A component will be defined by a single component definition file (bld.inf), which may include one or more project-definition files (.mmp).
This allows organization of the source files to correspond to the logical notions introduced by the model and hence use the model for various practical use-cases (such as management of source).
Component Criteria
- A component is relatively cohesive and relatively decoupled (measured in terms of the coupling of the units which comprise it versus its coupling to other components).
- A component is a reusable unit of the system.
- A component is the smallest unit of architectural significance and the finest-grained unit of description, management, and distribution of the system.
- All interfaces defined at higher levels of the decomposition are implemented by components.
- No external interfaces are visible at a level lower than component level.
List of Components
The initial Symbian Foundation device platform release contains in the region of 1,982 components.
As noted in Collection Representation section, the number of components in the initial Symbian Foundation will be a proportion of this.
Example of Component
The UI Look & Feel component is one component within the Common UI Support collection.
Figure 5 The UI Look & Feel component
The UI Look & Feel component provides a standard interface for developers to update UI elements such as fonts, controls and other UI resources that contribute to the look and feel of a particular device.
The UI Look & Feel component is named uilaf and is located within the commonuisupport directory sf/mw/classicui/commonuisupport/uilaf/...
The package_definition.xml defines the component as:
<component id="uilaf" name="UI Look and Feel" …… purpose="production-device">
<unit bldFile="commonuisupport/uilaf/group" …… ></component>
Note: The build file fundamentally defines the component as described above, so to understand what software binaries the component is responsible for you can examine the build file. For example, in this case, the XML shows the build file is at the location sf/mw/classicui/commonuisupport/uilaf/group/…
Tools Platform
Overview
The Symbian Foundation Tools system model encompasses all packages which are made available by the Symbian Foundation as part of a Symbian Foundation Tools platform release. (There are several platform releases constructed from the overall platform, including the Platform Development Tools release (PDT) and the Application Development Tools release (ADT). See the Tools technology domain page and Tools Structuring Principles document for further information.
This platform contains a comprehensive set of desktop and device-side tools available for use with the Symbian platform, although it should be noted that some device-side tools are still delivered as part of the device platform (for instance, if they are dependent on Symbian internal APIs and are therefore required to closely track device platform releases).
The Tools system model uses the same generic principles, structure and entities as the Symbian platform system model described elsewhere in this article. However the Tools-model-specific definitions are described in this section.
The Tools model is also built from its constituent package XML files and each of the Tools platform releases made available by the Symbian Foundation will include a system model associated with that release.
Link to System Models SVGs
SVG visualizations of the tools model are published on the Symbian Foundation website for each release of the platform. See the current Symbian Foundation platform system models:
- Package view model
- Collection view model
See Using Scalable Vector Graphics for more details on viewing these.
Tools Model Layers
There are three layers within the tools platform:
- The development layer
- The analysis layer
- The deployment layer
Development layer
This provides tools that support the standard development use-cases of edit, build, execution and debug, and provides the fundamental frameworks and environments to support tool execution and extension by upper layers.
Analysis layer
This provides tools that support static and dynamic validation and optimization of the platform. It targets the frameworks provided by the development layer to provide the required execution environments.
Deployment layer
This provides tools that enable the creation of devices and applications. This layer also contains standard configurations defining device platform releases.
Technology Domain
All the packages within the Tools platform are part of the Symbian Foundation Tools technology domain. (As noted above, this domain additionally encompasses some packages within the device platform.)
The tools technology manager will be responsible for creating the overall tools roadmap including information from the individual tools package roadmaps as appropriate. See the Tools technology domain webpage for more details.
Architecture Domains
The Tools model includes the concept of architecture domains.
From a system model perspective, these are perhaps analogous (in some ways) to technology domains as defined for the Symbian device platform:
- Architecture domains can include decoupled packages within layers, and packages across multiple layers, of the Tools platform.
- Every Tools package is allocated to exactly one architecture domain.
- The Tools model represents architecture domains using specific colours for the packages comprising each of the three domains
For the Tools model, architectural domains specifically define the development and execution environment of the package. There are three architectural domains specified:
Eclipse tools
Eclipse-based components provide an IDE integrated UI component, a command-line interface or generic Eclipse-based middleware.
Middleware tools
Non-Eclipse-based host tools provide a programmatic or command-line interface to higher-level tools within the same or upper levels or generic non-Eclipse-based middleware.
Device Tools
Device-based tools provide a direct interface to device platform interfaces to support tools use-cases.
Using Scalable Vector Graphics
SVG
Scalable Vector Graphics (SVG) is a language for describing two-dimensional graphics and graphical applications in XML. The biggest advantage of SVG over images is that they are zoomable to any level of detail and can also be interactive and animated.
Navigating the Model
Not all SVG viewers support easy zooming and panning. Most System Model diagrams include a handy navigation control that appears when the mouse is placed in the upper-left corner of the window that can be used to zoom and pan the diagram.
The + and – buttons will zoom in and out of the centre of the screen. The arrow buttons will pan the viewport in the direction of the arrow.
Additionally, when the mouse is placed at the bottom of the window, the legend will appear at the bottom of the window, taking up the full width of the window, reagrdless of the zoom factor. Note that, depending on the legend and the size of the screen, this may be less readable than just zooming in on the legend in place/
SVG Support
In order to view an SVG document, you’ll need an SVG-aware browser or an SVG plug-in for the browser.
Adobe SVG Viewer
The Adobe SVG Viewer (version 3.03) is the only one officially supported for the Symbian system model. It’s available as a plug-in for Windows and Mac OS, and can be downloaded from <http://www.adobe.com/svg/viewer/install>. Note that the UI is not very intuitive, the most important commands for viewing SVG are:
- Hold down ALT while moving the mouse to pan the image.
- Hold down CTRL and mouse click to zoom in.
- Hold down CTRL + SHIFT and mouse click to zoom out.
Right-click for a menu of other commands. The full list of commands is described at http://www.adobe.com/svg/viewer/help/3.0/enu/win/help.html.
Note that Adobe no longer supports the viewer. It is recommended at present, however, because the latest version works for the system model, and it is the fastest viewer and supports the most functionality.
Browsers
Internet Explorer is the recommended browser for the Model and the Adobe plug-in is available for IE.
Firefox version 3 has sufficient SVG support to view and navigate the System Model, but text will show up poorly aligned in many cases. Since Firefox has no native support for zoom and pan, you will need to use the navigation control to navigate around the diagram. Note that the navigation control will always be present in the upper left corner (i.e. it will not fade out when the mouse is not over it).
Opera version 9 comes with a reasonable SVG viewer but is slow and does not support all functionality. The navigation control does not work with Opera. Instead use CTRL+ left click to zoom in, and CTRL+SHIFT + left click to zoom out.
Safari version 4 has serious problems, with text not wrapping to the bounding box at all and therefore running into other components, making the model pretty much unreadable; and the zoom functionality often seems to make the model disappear entirely. Not recommended for browsing the model.
SVG Printing
The best way to print an SVG document is to use the Adobe Viewer from IE. Note the following:
- Always do a print preview and select landscape orientation.
- Remove the browser header and footer and reduce the margins to optimize print view.
- IE will print the current screen view, so ensure everything you require is visible before printing.
- If you are using a widescreen display, set display to standard aspect ratio before printing.
- Printing A2 or larger requires the model be specified at least 600dpi when building (printing A3 and A4 works at default dpi).
Comments
Contents |
Yuanping said...
Dalarub said…
Noted and corrected... does it look better?
--Dalarub 11:05, 24 November 2009 (UTC)
Dalarub said…
Noted and corrected... does it look better?
--Dalarub 11:06, 24 November 2009 (UTC)
Martinj said…
Is the Package view model kept up to date? The latest(?) package view http://developer.symbian.org/downloads/system_models/foundationpkg_22-05-09.svg doesn't seem to show all packages from S^3.
--Martinj 15:01, 8 March 2010 (UTC)
Dalarub said…
you are absolutely right, the current view is only valid for S^2. We have been very busy with the SM for S^3 and we are now in the process of publishing it. We generate all views (Package/Collection/Component) on the daily builds but plan to publish the jpg for the Package level view. Any comments welcome.
--Dalarub 06:47, 9 March 2010 (UTC)
Martinj said…
Sorry not sure if I understand correctly... the svg is generated with daily builds? If so is it available somewhere? I'm not really interested in jpg, svg is exactly what we need...
--Martinj 10:39, 9 March 2010 (UTC)
Sign in to comment…
Currently, the section - System Model Entities - is empty and sections - Layers, Technology Domains, Packages, Collections and Components are at the same level with System Model Entities. Should they be contained in System Model Entities?
--Yuanping 12:46, 5 August 2009 (BST)