The Symbian OS (779886), страница 30
Текст из файла (страница 30)
There is no concretemechanism that instantiates blocks or sub-blocks in the existing system(i.e. there is no make file or equivalent).Blocks in the system model are defined with the following guidelinesin mind:• a block is relatively logically cohesive and relatively self-contained• a block is relatively cohesive and relatively decoupled (measured interms of the coupling of the component collections it contains)• a block provides services to blocks in the same layer (‘sideways’) orto blocks or component collections in higher layers (‘upwards’)• a block delegates tasks downwards or sideways2Cohesion and coupling are standard concepts used to analyze software complexity.See, for example, [Henderson-Sellers 1996] and the influential papers by Lionel Briand andothers at the Fraunhofer Institute, such as [Briand et al. 1997].BASIC CONCEPTS115UIFrameworkJava MEApplicationServicesCommsFrameworkTelephonyServicesShort LinkServicesNetworkingServicesOSServicesGeneric OSServicesComms ServicesMultimediaandGraphicsServicesConnectivityServicesBaseServicesKernelServices &HardwareInterfaceKernel ArchitectureFigure 5.2 Block decomposition in the system model• a block ‘consolidates’ the sum of services provided by the componentcollections it contains into a technology domain• a block is not a delivery unit – it makes sense to partially deliver,update or remove a block.Components and Component CollectionsComponents are the basic entities of the model and the smallest unitsof architectural interest.
Importantly, components have a concrete interpretation in the source system, corresponding approximately to parts ofthe source tree controlled by a single high-level build file (an MRP filein the Symbian build and delivery idiom but, more generally speaking, ahigh-level make file).Components are also the basic units of optionality in the system,the level at which common, optional and replaceable functionality isdefined and at which it may be (respectively) included, removed orre-implemented by the respective licensees of Symbian OS.3Component collections group individual components into coherentsets of collaborating components.
In principle, a component collection3For a more detailed discussion, refer to Appendix A.116THE SYMBIAN OS LAYERED MODELdelivers a complete, discrete and identifiable subset of system functionality. In practice, component collections are derived from a ‘commonsense’analysis of existing system functionality, as well as the physical organization of the source tree.There is no concrete mechanism that instantiates component collections in the existing system (i.e. there is no make file or equivalent).Component definition follows these principles:• a component is the smallest architectural unit of the system• a component is understood as a set of implementation units that arebuilt together to provide a discrete, reusable piece of the system• in concrete terms, a component is identified with a single MRP file thatensures alignment with build and delivery mechanisms (in versionsof the model up to Symbian OS v8, a component is identified with ahigh-level bld.inf file rather than an MRP file.)Components should also obey the following guidelines and displaythese properties:• a component is relatively cohesive (in essence it has been designedas a discrete part of the system)• a component is a reusable unit of the system• a component is the smallest unit of architectural significance and thefinest grained unit of description, management and distribution of thesystem• a component is implemented by at least one and possibly manycollaborating sub-units• no part of any component is shared by other components• all interfaces defined at higher levels of the model are implementedby components.In all, the system model for Symbian OS v9.3, the latest versionof the operating system at the time of writing, defines approximately250 individual components.4 However, there is still a significant degreeof idealization in the component definitions and, in many cases, thedetailed mapping from the model to the system as built and deliveredis approximate.
In other words, the model serves as a useful logical4Appendix A documents 258 components, for example, and does not include Toolkitcomponents.LAYER-BY-LAYER SUMMARY OF THE SYMBIAN OS V9.3 MODEL117description, but cannot necessarily be unambiguously followed down tofile level. (Improving alignment is an ongoing task.)Component collections are defined with the following guidelines inmind:• a component collection is relatively cohesive and relatively decoupled(in terms of the coupling of the components it collects)• a component collection provides services to other collections withinits block or layer (‘sideways’) or to blocks or component collectionsin higher layers (‘upwards’)• a component collection delegates tasks downwards or sideways• a component collection groups logically related functionality• a component collection exposes the interfaces provided by the components it collects• no component collection is shared between blocks or layers• no component is shared between component collections• a component collection is not a delivery unit – its individual components may be delivered, updated, or removed singly.5.3 Layer-by-Layer Summary of the Symbian OS v9.3ModelA high-level view of the system model for Symbian OS v9.3 is includedin this book as a fold-out diagram.All releases of the operating system from Symbian OS v7.0 to SymbianOS v9.3 share the same layer decomposition.• UI Framework layer: The topmost layer of Symbian OS provides theframeworks and libraries for constructing a user interface, includingthe basic class hierarchies for user interface controls, and otherframeworks and utilities, including concrete widget classes used byinterface components.• Application Services layer: This layer provides support independentof the user interface for applications on Symbian OS.
These servicesdivide into three broad groupings:◦ system-level services, such as basic application frameworks, usedby all applications118THE SYMBIAN OS LAYERED MODEL◦ services providing technology-specific logic, such as messagingand multimedia protocols, that are used by multiple classes ofapplication◦ services that support specific individual applications, such aspersonal information management (PIM) and office applications.Also included are a number of application engines that are used andextended by a licensee.• Java ME: In effect, Java spans the UI Framework and ApplicationServices layers, abstracting (as well as implementing) elements ofboth for Java applications. Symbian’s Java implementation is based onJava ME MIDP 2.0 and CLDC 1.1. Java support has been included inSymbian OS from the beginning, but the early Java system was basedon Personal Java and JavaPhone.
A standard system based on Java MEfirst appeared in Symbian OS v7.0s. Since Symbian OS v8, the JavaVM has been a port of Sun’s CLDC HI.• OS Services layer: The ‘middleware’ layer of Symbian OS providesthe servers, frameworks and libraries that extend the bare systeminto a complete operating system. The services are divided into fourmajor blocks that provide all technology-specific but applicationindependent services:◦ generic operating system services◦ communications services◦ multimedia and graphics services◦ connectivity services.• Base Services layer: The foundational layer of Symbian OS providesthe lowest level of user-side services, depending only on the operatingsystem kernel (and related components), which it extends into auseable (but minimal) system. In particular, no services higher thanthose in the Base Services layer are required for a minimal base portto new hardware (in other words, a minimal base port requires onlythe two lowest layers of the system).• Kernel Services and Hardware Interface layer: The lowest layer ofSymbian OS contains the operating system kernel itself and supportingcomponents that abstract the interfaces to the underlying hardware,including logical and physical device drivers and variant supportthat implements pre-packaged support for the reference hardwareplatforms.
Releases up to Symbian OS v8 use the original SymbianOS kernel, Kernel Architecture 1 (EKA1 kernel). In Symbian OS v8.1band from Symbian OS v9, all systems are based on the new KernelArchitecture 2 (EKA2) real-time kernel.HISTORY1195.4 What the Model Does Not ShowThe System Model shows a static view of the system, in effect a sourceview based on architectural relationships and abstracted from the detailsof what code appears in which files. It is not, therefore, a source tree orrepository view.The model also reflects only static (i.e.
build-time) dependencies. Itdoes not model processes, the memory contexts that are created on adevice when the operating system runs, the threads that run within thosememory contexts, or the services that those threads provide.5.5 HistoryThe system model was first published internally in 2004 (and thereforesomewhat after the fact), as a description of Symbian OS v7.0. It wasalmost immediately updated for Symbian OS v7.0s.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
