SENG 443 - Microsoft Simulator
Upcoming SlideShare
Loading in...5
×
 

SENG 443 - Microsoft Simulator

on

  • 315 views

 

Statistics

Views

Total Views
315
Views on SlideShare
314
Embed Views
1

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SENG 443 - Microsoft Simulator SENG 443 - Microsoft Simulator Document Transcript

  • SENG 443 Project 1 Component Architecture Microsoft Flight Simulator Model-View Controller (MVC) Authors: Hanif Mohamed Aarti Punj Nitin Puri Cledelyn Santos Kamal Singh University of Calgary Department of Computer Science Faculty of Science Calgary, Alberta, Canada November 2002 Version: 1.0All rights reserved. No part of this document may be reproduced,redistributed, nor transmitted without the prior written permission of thepublisher. Copyright 2002 Nitin Puri nitin@cpsc.ucalgary.ca
  • TABLE OF CONTENTS1. EXECUTIVE SUMMARY .................................................................................................................... 42. CONCEPTUAL VIEW .......................................................................................................................... 5 2.1 Global Analysis .............................................................................................................................. 5 2.1.1 Factor Table............................................................................................................................ 5 2.2 Conceptual Configuration............................................................................................................... 8 2.2.1 Overall System Architecture................................................................................................... 8 2.3 Final Design Tasks ....................................................................................................................... 103. MODULE VIEW.................................................................................................................................. 11 3.1 Global Analysis ............................................................................................................................ 11 3.1.1 Factor Table.......................................................................................................................... 11 3.2 Module Configuration .................................................................................................................. 12 3.2.1 Observer Pattern 1 ................................................................................................................ 12 3.2.2 Observer Pattern 2 ................................................................................................................ 13 3.2.3 Command Processor Pattern................................................................................................. 14 3.2.4 Views.................................................................................................................................... 15 3.2.5 Factory Method Pattern ........................................................................................................ 16 3.2.6 Plane and Event Classes ....................................................................................................... 17 3.2.7 Composite Pattern................................................................................................................. 18 3.2.8 Chain of Responsibility Pattern ............................................................................................ 194. EXECUTION VIEW............................................................................................................................ 20 4.1 Global Analysis ............................................................................................................................ 20 4.1.1 Factor Table.......................................................................................................................... 20 4.2 Central Design Tasks.................................................................................................................... 21 4.2.1 Execution View .................................................................................................................... 21 4.2.2 Communication Paths........................................................................................................... 22 4.2.3 Resource Allocation ............................................................................................................. 225. CODE VIEW........................................................................................................................................ 23 5.1 Global Analysis ............................................................................................................................ 23 5.1.1 Factor Table.......................................................................................................................... 23 5.2 Directory Hierarchy...................................................................................................................... 25 5.2.1 Simulation Setup Folder ....................................................................................................... 25 5.2.2 Simulator Controls Folder .................................................................................................... 26 5.2.3 Flight Controls Folder .......................................................................................................... 27 5.2.4 Controller Folder .................................................................................................................. 276. CONCLUSION .................................................................................................................................... 287. GLOSSARY......................................................................................................................................... 29 2
  • TABLE OF FIGURESFigure 1: Overall System Architecture.......................................................................................................... 8Figure 2: Model-View Controller.................................................................................................................. 9Figure 3: Observer Pattern 1 - Change Propagation Mechanism of the Views ........................................... 12Figure 4: Observer Pattern 2 - Change Propagation Mechanism of an Event ............................................. 13Figure 5: Command Processor Pattern ........................................................................................................ 14Figure 6: Views ........................................................................................................................................... 15Figure 7: Factory Method Pattern................................................................................................................ 16Figure 8: Plane and Event Classes............................................................................................................... 17Figure 9: Composite Pattern........................................................................................................................ 18Figure 10: Chain of Responsibility Pattern ................................................................................................. 19Figure 11: Flight Simulator Execution Architecture View.......................................................................... 21Figure 12: Communication Path Meta-Model............................................................................................. 22Figure 13: Simulation Setup Folder ............................................................................................................ 25Figure 14: Simulator Controls Folder.......................................................................................................... 26Figure 15: Flight Controls Folder................................................................................................................ 27Figure 16: Controller Folder........................................................................................................................ 27 View slide
  • 1. EXECUTIVE SUMMARY This document provides the Component Architecture of the Model-ViewController (MVC) for the Microsoft Flight Simulator. There are four major sections in thedocument to provide a clear and detailed technical description of the ComponentArchitecture of the MVC. These four sections are the Conceptual View, Module View,Execution View, and Code View. The Conceptual View section outlines how the MVC is related to the overallsystem. Within the Global Analysis subsection, we have included a factor table, whichlists product, organizational, and technological factors. In the Conceptual Configurationsubsection, we have illustrated how the Overall System Architecture and MVC arerelated. The Module View section examines our modules and subsystems containedwithin the MVC component. Within our Global Analysis subsection, we have used afactor table, which lists the product, organizational, and technological factors. In theModule Configuration subsection, we have described the implementation of designpatterns, such as the Observer Pattern, Command Processor Pattern, Factory MethodPattern, Composite Pattern, and Chain of Responsibility Pattern, within our modules. The Execution View section examines execution of the modules and subsystemsin terms of system performance in regards to hardware/software requirements. Within ourGlobal Analysis subsection, we have used a factor table, which lists the product,organizational, and technological factors. Within our Central Design Tasks subsection,we have also examined the execution of the modules and subsystems in terms ofexecution view, communication paths, and resource allocation. The Code View section describes how the different modules and subsystems willbe hierarchically stored. Within our Global Analysis subsection, we have used a factortable, which lists the product, organizational, and technological factors. In the DirectoryHierarchy subsection, we have described how the files and folders should be setup in foroptimal hardware and software performance. Furthermore, we have described how theFlight Simulator will be setup within the root directory, along with the four major sub-directories, and how they are further broken down for modularity. In order to provide a clearer understanding of terms used in this document, aGlossary is included at the end of this document. 4 View slide
  • 2. CONCEPTUAL VIEW This section will outline how the MVC is related to the overall system. Within theGlobal Analysis subsection, we have included a factor table, which lists product,organizational, and technological factors. In the Conceptual Configuration subsection, wehave illustrated how the Overall System Architecture and MVC are related.2.1 Global Analysis The purpose of this section is to discuss the different factors that affect theConceptual View of the Flight Simulator architecture of the system and defines strategiesneeded in order to accommodate these in the design. An event driven architecture designis used.2.1.1 Factor Table The following factor table discusses the Product, Organizational andTechnological factors that make up the Global Analysis of the Conceptual View. Product Factor Flexibility and Changeability ImpactP1: Functional FeaturesP1.1: High ConcurrencyThe product must monitor many The number of user-inputted There is a moderate effect on real-concurrent events and views seen events and views are constantly time performance. The lessby the user changing. quickly events are handled, the less realistic the simulation will appear.P2: User InterfaceP2.1: Speed of InterfaceThe interface has to update There is little flexibility since all There is a moderate impact on thequickly to simulate real-time events have to appear real-time. user interface.events (i.e. flying).The mouse and keyboard eventsmustbe handled quickly so theinterface reacts seamlessly.P2.2: Interaction Model - Ease ofUseThe product must appeal to users Higher levels of play require The speed at which the interfaceof varying computer literacy. If higher difficulty. There is responds is affected by thethe product is too complex it will moderate flexibility in terms of complexity of the controls used tonot be stimulating for the average ease of use. play the game.user.P3: PerformanceP3.1: Acquisition PerformanceHigh-volume real-time events There is moderate flexibility in This affects the user interface.such as views must be shown fast terms of performance. Whenenough to appear asynchronous. there are high volumes of events generated, a slight lag is expected. 5
  • P4: DependabilityP4.1: ReliabilityFrequent freezing or crashing is It should be moderately stable. This affects the user-friendlinessnot acceptable in a game type of the product.environment. The usability willbe seriously compromised.P5: ServiceP5.1: System Support and ServicesContinued support should be System support is a priority – The satisfaction of the customer,provided to the customer, as well amount of support is negotiable and the appeal of the simulator isas constant updates, FAQ files, affected.and tips provided via web page.Organizational Factors Flexibility and Changeability ImpactO1: ManagementO1.1: Build vs. BuyThere is a preference for building Graphics components acquired The consistency of the program isas the graphics for such a program from other sources may not be affected.must be original. compatible with the system.O1.2: Schedule vs. functionalityBasic views can be released as a The additional views are The look and feel of the firstworking model of a simulator, negotiable. release vs. later releases iswith complex views added at a affected.later date.O2: Staff skills, interests, strengths, weaknessesO2.1: Application domainThe staff should have extensive To avoid inconsistency and There is a moderate impact on thegraphics and games programming inefficiency in design, staff quality of the simulator. The lossexperience. should remain with the project. of expertise could result in delays.O3: Process and Development EnvironmentO3.1: Development PlatformLanguages and platforms used to Compatible tools and classes may Software metrics such as LOCdevelop the simulator should be be implemented with Java. would be affected.graphics friendly and objectoriented. Java has built ingraphics and image controlclasses.O3.2: Testing Process and ToolsBoth black box and white box There is little flexibility in terms The quality of the program istesting is imperative in this type of functionality testing. All affected.of user intensive system. features must be tested.O4: Development ScheduleO4.1: Time-to-MarketExtensive product marketing is The minimum time-to-market The initial response of the publicrequired to create excitement should be set, but should be easily is greatly affected. Withoutsurrounding the release. extended. proper marketing, productImpressive sample views should popularity will be compromised.be demonstrated in advertisementfar before the simulator is actually 6
  • released.O4.2: Delivery of FeaturesThe features are organized in The priority of features is There is a moderate effect on theterms of priority. negotiable. meeting of the schedule.O5: BudgetO5.1: Head CountAssignments are given to Team leadership dynamics and There is an impact on meeting theinformal teams. number of team members is schedule, and the consistency of negotiable. work done.O5.2: Cost of DevelopmentTools, facilities, and personnel There should be a marginal There is an impact on the cost ofmust all be considered in the allowance for development delays sale for the product and meetingdevelopment budget. and extra costs. the schedule.Technological Factor Flexibility and Changeability ImpactT1: General – Purpose HardwareT1.1: ProcessorsIn order for the game to run at full It is possible to load the game on There is a moderate impact on thepotential, the processor should be a less than Pentium processor, quality of the simulation, andat minimum a Pentium however, this will result in less speed will be reduced than optimal performanceT1.2: MemoryMemory required for this game is This is not negotiable, as this will There will be an impact on theapproximately 80 MB. result in improper loading of the quality of graphics, and game implementation of the gameT2: Domain – Specific HardwareT2.1: Specialized HardwareThe user must own a joystick This is negotiable; a keyboard The overall cost of the productcompatible with the simulator controller may be added upon will be increased if a joystick is to request be included with the productSound cards are required for This is not negotiable The overall size of market maysound effects decrease due to the requirement of owning a sound cardHigh resolution monitors are This is negotiable; the game may There is a moderate impact on therequired for quality visual effects still be played with regular quality of the interfaces monitorsA CD ROM Drive is required for This is negotiable; the game may Loading the game will be variableloading and running the be downloaded from the internet to the user’s internet connectionapplication but this will require more memory speedT3: Software TechnologyT3.1: Operating SystemThe Operating System will need This is not negotiable since the The overall size of market mayto be Windows 95 and up product is Windows based decrease as only Windows users (not MacIntosh users) can play the gameT3.2 User InterfaceThe user interface should be This is not negotiable The size of the overall game willgraphics oriented be affected as graphics take up more memory spaceT3.3 Design Patterns 7
  • The overall architecture of the This is negotiable; more design This will affect the overall designModel-View-Controller requires patterns may be added as needed architectureat least five design patternsdiscussed in this documentT4: Architecture TechnologyT4.1: Architecture StylesThe system is of a blackboard, This is not negotiable The flow of data within thedata-centered architecture style system is affectedThe system is of an object- This is not negotiable The flow of data within theoriented, call/return architecture system is affectedstyleThe main architecture style forthis system isT5: StandardsProject-specific naming This is negotiable There is a moderate effect on theconventions of variables and meeting of the scheduleclasses should be created2.2 Conceptual Configuration2.2.1 Overall System Architecture Figure 1: Overall System Architecture 8
  • The overall architecture of the Flight Simulator system is divided into a numberof components (or subsystems) among which the Model-View-Controller is a part of.Some components of this system are shown in the above diagram. The Model-View-Controller component of the Flight Simulator system is aframework that divides an entire simulation system into three components, namelymodel, view and control. In this framework, the model component processes the data orcommands sent by the controller, while the view provides high quality real- timesimulation and supports the different kinds of views. The control receives the stateinformation from the user, and issues commands to satisfy the event requests. Figure 2: Model-View Controller As shown in the figure above, within the Model-View Controller of the FlightSimulator, the Controller component will receive data as input from joystick events.Triggered by movement from a four directional joystick, the joystick events will send theappropriate data to the Controller component. In turn, the data will be sent from thesource, the Controller component, to the destination, the Model component. The Modelcomponent will then process the data, by using the appropriate modules and subsystems,as required. Once processed, the processed data will be sent from the source, the ModelComponent, to the destination, the View component. Consequently, the View componentwill send the appropriate views as output, or views out. Concurrently, from the process of receiving data as input from joystick events,commands will also be sent between the components. The sender, the ControllerComponent, will send a command to the receiver, the Model Component. Similarly, oncedata has been processed and is being sent, the sender, The Model Component, will send acommand to the receiver, the View component. 9
  • 2.3 Final Design Tasks The budget for the resources that are shared or limited for the Microsoft FlightSimulator will focus on two primary resources: the system memory requirements and thesystem resources. According to the Flight Simulator specifications, the memoryrequirements are as follows: 1. 32 MB of RAM (preferably 64 MB of RAM) 2. 80 MB of free hard disk drive space (could be more depending on additional features that could be added (extensions, service packs, upgrades, patches), and how many saved flight simulations the user saves. This overhead to the execution environment is met by the conceptual viewbecause the amount of space needed to accomplish the model view controller is far belowthe memory requirements. The other consideration for resource budgeting is the system resources.The requirements for system requirements include the following: 1. At least a Pentium Processor 2. A sound card and graphics card 3. An SVGA monitor 4. A Joystick or keyboard 5. A 4X CD-Rom The conceptual view once again meets the overhead of the execution environmentin this case simply because the rate of technology progress has reached such a level thatat present, the above listed requirements are far less than what most home computerscurrently possess. 10
  • 3. MODULE VIEW This section examines our modules and subsystems contained within the MVCcomponent. Within our Global Analysis subsection, we have used a factor table, whichlists the product, organizational, and technological factors. In the Module Configurationsubsection, we have described the implementation of design patterns, such as theObserver Pattern, Command Processor Pattern, Factory Method Pattern, CompositePattern, and Chain of Responsibility Pattern, within our modules.3.1 Global Analysis The purpose of this section is to discuss the different factors that affect theModule View of the Flight Simulator architecture of the system and defines strategiesneeded in order to accommodate these in the design. The concepts of software reuse andmodularity, in conjunction with industry standard design patterns, are used.3.1.1 Factor Table The following factor table discusses the Product, Organizational andTechnological factors that make up the Global Analysis of the Module View. Product Factor Flexibility and Changeability ImpactP1: Functional FeaturesP1.1: Module DependenciesModule dependencies can be Some interdependencies are The speed of the interface is affected.minimized by using highly object acceptable and expected. (The more information needs to beoriented design, and adhering to passed, the slower the response).information hiding andencapsulation principles. Eachmodule should have a specializedtask independent from othermodules. Modules which are veryinterdependent should becombined.P1.2: Reuse of Models and SubsystemsReuse of models and subsystems The amount of reusability is There is a moderate affect on thecan be maximized by designing negotiable. Some specialized meeting of the schedule.highly maintainable code, as if the functionality may not be madecode cannot be easily changed to easily reusable.suit a new purpose, it is not likelyto be reused. Libraries may alsobe created to store commonlyused functions and classes.Organizational Factors Flexibility and Changeability ImpactO1: Staff SkillsThe staff should have extensive To avoid inconsistency and There is a moderate impact on thetraining or experience with inefficiency in design, staff quality of the simulator. The loss ofcomponents and connectors, and should remain with the project expertise could result in delays, andobject oriented technology increase in overall cost 11
  • O2: ManagementO2.1 Build vs. BuyThere is a preference to acquire This is flexible; it may not be There is an impact on the cost of salelibrary packages such as extended possible to implement some for the product and meeting thegraphics packages rather than functions using generic packages schedulebuilding from scratchO3: Process and Development EnvironmentO3.1: Testing Process and ToolsBottom-Up Integration is This is flexible; different testing If testing is not done properly, thispreferred to properly test modules methodologies can be will result in delays, cost increases,thoroughly implemented as required and possible defects upon releaseTechnological Factors Flexibility and Changeability ImpactT1: ChangeabilityThe module components should This is not flexible since the The longevity of the product’s lifebe easily updated to accommodate game will quickly become cycle is affectedthe need for later versions and obsolete if it cannot be easilyoperating systems adaptable to new environments3.2 Module Configuration3.2.1 Observer Pattern 1 Figure 3: Observer Pattern 1 - Change Propagation Mechanism of the Views The Change Propagation Mechanism is implemented using the Observer Patternby attaching a ViewControllerObserver to the Plane class. The joystick controller causesa change in the state of the Plane class. This will allow the different cockpit views (i.e.right, left, and forward views) to be updated accordingly. At first, the ConcreteViewController class receives the new state of the plane andthe ViewController class is informed that a change in state has occurred. The 12
  • ViewController then notifies the ViewControllerObserver of the change in state, and theViewControllerObserver will update the cockpit views accordingly. The update functionsperform mathematical calculations on the previous (x,y,z) coordinates to determine thenew coordinates of the views. The new state of the plane is then set with the updatedcockpit views in the ConcreteViewController class.3.2.2 Observer Pattern 2 Figure 4: Observer Pattern 2 - Change Propagation Mechanism of an Event The Change Propagation Mechanism is also implemented using the ObserverPattern by attaching an EventController Observer to the Event class. A random generatorcreates an event, such as a bird or another plane, which are not part of the staticpredefined game virtual world. Objects in the predefined virtual world would includeitems such as buildings, mountains, and oceans. Also, each time the game is played,random events being observed by this pattern will occur, but the static elements(identified by (x,y,z) coordinates) remain exactly where they always are. The Eventobject is tracked by the Plane object through the use of the function KnowEventLocation,(see Plane and Event Classes, section 3.2.6). At first, the ConcreteEventController class receives the new state of the event andthe EventController class is informed that a change in state has occurred. TheEventController then notifies the EventControllerObserver of the change in state, and theEventControllerObserver will update the location of the event. The new state of the eventis then set with the updated location in the ConcreteEventController class. 13
  • 3.2.3 Command Processor Pattern Figure 5: Command Processor Pattern The movement of a joystick, the control device chosen for this application,initiates a request that is transformed into an object. This will allow the system to eitherexecute the request immediately, or queue/log the requests as needed. Undoableoperations, such as attempts to move past the bounds of the application virtual world, arehandled efficiently. The invoking object in the pattern is a joystick movement, which isessentially a request to move or change the direction of the plane. This invocation resultsin the ExecuteMovement function of the ConcreteCommand class to be called, whichhandles the incoming request to move the plane. The receiver knows how to perform themovement action, which will result in setting the attributes of the LeftView, RightView,and ForwardView classes as outlined in the Factory pattern (see Factory Method Pattern,section 3.2.5). 14
  • 3.2.4 Views Figure 6: Views The SpacialView class represents the predefined elements of the virtual world.These elements are defined in terms of x,y, and z coordinates in the virtual world space.The objects, such as trees, mountains, and rivers are drawn using graphic functions. TheSpacialView class is instantiated only at the start of the game, since the static elements inthe class (part of the virtual world space) do not change. This means every time the gameis played, these views are constant and only the randomized events, such as birds, orweather sequences are different. The RightView, LeftView, and ForwardView classes contain x,y,z coordinateswhich keep track of the current views of the plane. Each time a movement occurs, eachof these classes is instantiated as can be seen in the Factory pattern (see Factory MethodPattern, section 3.2.5). These new objects (of types RightView, LeftView, andForwardView) are passed through an instance of ConcreteViewObserver (see ObserverPattern 1, section 3.2.1), to their respective Update functions. 15
  • 3.2.5 Factory Method Pattern Figure 7: Factory Method Pattern The Simulator class contains the main routine of the game. At the construction ofthe game, objects of type Plane and SpacialView are immediately instantiated to createthe virtual world (trees, cities, mountains etc.) and the plane for the simulation. Joystickmovements are received through joystick action listeners, and are handled through thefactory pattern. The joystick movements, once handled by action listeners in Simulator, arerecorded by assigning a String to each movement. The String is passed to theupdateViews function the ConcreteSimulatorViewFactory class, which creates thedifferent views, depending on the type of movement requested. If the user moves the joystick to the left, only the LeftView is instantiated. Theprevious LeftView becomes the new ForwardView, and the previous ForwardViewbecomes the new RightView. If the user moves the joystick to the right, only the RightView is instantiated. Theprevious RightView becomes the new ForwardView, and the previous ForwardViewbecomes the new LeftView. 16
  • If the user moves the joystick back, i.e. the user wants to move up, the UpView,RightView, and LeftView classes are instantiated. The new UpView will become thecurrent forward view. The RightView and LeftView will become the new right and left If the user moves the joystick forward i.e wants to move down, the DownView,RightView, and LeftView classes are instantiated. The new DownView will become thecurrent forward view. The RightView and LeftView will become the new right and leftviews. views. If the user makes no request to move and the plane is just continuing to moveforward, the observer pattern will continue to update the views to simulate forwardmovement. In summary, the inputs to the simulator, i.e. the joystick movement, are handledthrough the use of the Command-Processor Pattern (section 3.2.3). The Factory MethodPattern then processes those requests by creating the appropriate views, which are thenupdated through the use of the Observer Pattern 1 (section 3.2.1 ).3.2.6 Plane and Event Classes Figure 8: Plane and Event Classes The Plane class contains various attributes pertaining to the plane. The attributesrequired include altitude, speed, direction (left, right, and forward), spatial degreeintegers, and a Boolean isCrashed. The altitude attribute keeps track of the distance the plane is from the virtualworld ground. The speed attribute not only keeps track of the plane’s current speed, butalso provides a reference point when take-off and landing speeds are to be considered.The direction of the plane is relative to the spatial degree surrounding the plane, and is 17
  • changed by movement of the joystick controller. For example, moving the joystick backwould result in a change of altitude relative to the spatial area of the plane. The directionof the plane is identified by the left_direction, right_direction, forward_direction, or acombination of these variables (i.e. a plane is able to travel northeast, northwest, etc.).The spatial degree surrounding the plane is a 360-degree by 360-degree coordinate area.The location of the plane at any given time is determined in relation to that spatial area.Finally, the Boolean value isCrashed is set to true in the event the plane is involved in acollision with some object and a predetermined explosion sequence would occur. The Event class contains attributes pertaining to the x, y, and z coordinates of theevent. This will enable the plane to keep track of where the event object is located at anygiven time. (see Observer Pattern 2 for more details on Events, see section 3.2.2).3.2.7 Composite Pattern Figure 9: Composite Pattern This pattern implements a tree structure to represent the part-whole hierarchy ofhow the views are generated. The leaf objects in this pattern are the RightView,LeftView, and ForwardView classes. These three views compose the PlaneView, whichis an aggregate of the component Cockpit View. Instances of the PlaneView willrecursively generate new views as needed. The recursive nature of the Composite Patternis effective in implementing this application, as the views must be continually updating inthe exact same fashion in the simulation of the plane. 18
  • 3.2.8 Chain of Responsibility Pattern Figure 10: Chain of Responsibility Pattern An incoming request to move, i.e. change the view, is sent to a generic handler.The handler, CockpitView, then passes the request through the chain of objects capableof handling the requests, which are the RightView, LeftView, and ForwardView. TheFowardView is a general way of stating the UpView or DownView depending on whichmovement was requested. (For more details on the Views, see section 3.2.4). 19
  • 4. EXECUTION VIEW This section examines execution of the modules and subsystems in terms ofsystem performance in regards to hardware/software requirements. Within our GlobalAnalysis subsection, we have used a factor table, which lists the product, organizational,and technological factors. Within our Central Design Tasks subsection, we have alsoexamined the execution of the modules and subsystems in terms of execution view,communication paths, and resource allocation.4.1 Global Analysis The purpose of this section is to discuss the different factors that affect theExecution View of the Flight Simulator architecture of the system and defines strategiesneeded in order to accommodate these in the design. Real-time events andhardware/software specifications are examined within this section.4.1.1 Factor Table The following factor table discusses the Product, Organizational andTechnological factors that make up the Global Analysis of the Execution View. Product Factor Flexibility and Changeability ImpactP1: PerformanceP1.1: Start-up and Shut-down timesThe start-up and shut-down times There is some flexibility as this There is moderate impact on theshould be relatively fast is dependent on the hardware speed of execution platformP1.2: Recovery TimeIn the event of a crash, the system This is not flexible. There should The dependability of systemshould be able to recover to the never be an occurrence where performance is affectedstate prior to the crash users cannot start the game after a crashP1.3: Acquisition PerformanceHigh-volume real-time events There is moderate flexibility in This affects the user interface.such as views must be shown fast terms of performance. Whenenough to appear asynchronous. there are high volumes of events generated, a slight lag is expected.P2: Failure Detection, Reporting and DeliveryP2.1: DiagnosticsRun-time errors should be There is little flexibility in area. There is a slight impact on thehandled through exception usability of the game.handling and never result in acrash or unexpected responsefrom the game.Organizational Factors Flexibility and Changeability ImpactO1: Process and Development EnvironmentO1.1: Testing Process and Tools 20
  • Black box testing can be used to The amount of testing is The usability of the game, and thetest the executables for the game. negotiable quality are affectedThe game should be played with avariety of different approaches tocheck all possible systemresponsesTechnological Factors Flexibility and Changeability ImpactT1: StandardsT1.1: CommunicationCommunication of information This is negotiable. Slower The quality of simulation is affected,between modules, and communication means slower which is dependent on the speedcommunication of information to runtime, but small delays arethe user must both be done at expectedoptimal speedT1.2: Hardware PlatformsThe hardware platform that is This is negotiable. Hardware The quality and reliability of therequired is a Pentium processor, below minimum requirements simulation is affected. If below80 MB of available hard disk will negatively affect minimum requirements, coulddrive space, joystick, sound card, performance; versus hardware become unstable and crash. If abovean SVGA monitor, and a CD- requirements above minimum the requirements, could enhanceROM drive. requirements which could performance and run more efficiently positively enhance performance. than benchmark testsT1.3: Software PlatformsThe software platform required is This is negotiable. Older Older systems will not be able to loada Windows based O/S that is operating systems are simulation, versus newer operatingWindows 95 or above. incompatible, versus newer systems that will be able to load the operating systems, which are simulation. backwards compatible.4.2 Central Design Tasks4.2.1 Execution View The execution view of the Flight Simulator focuses mainly on real-timeperformance. Each component of the conceptual design discussed previously wasmapped to a set of execution elements. Afterwards different strategies were discussed inthe global analysis in order to aid the mapping of these elements in the module view tothe execution view. Figure 11: Flight Simulator Execution Architecture View 21
  • The figure shown above is an overview of the Flight Simulator executionarchitecture view. This is a runtime entity model. Commands from the controller areexecuted first, and then are passed on to the model, which processes these commands,and data through the various design patterns discussed into our final command (that is,which views to set and when) and maps it onto our view.4.2.2 Communication Paths The main communication mechanisms in the Model-View-Controller system arethe observers. The observers are responsible for notifying objects when to update theviews. Incoming events from the joystick (controller) are handled by the classes thatimplement the observers. The following diagram can best describe the flow ofcommunication: Figure 12: Communication Path Meta-Model4.2.3 Resource Allocation Resources that are allocated during the execution view include main memory,CPU usage, processor speed and the Windows Operating system. CPU usage is high andmore memory is required to run the program since this is a graphics simulation basedprogram. The speed of the processor is also allocated to implement real-time andasynchronous events and views. A number of strategies were identified in order achievethe best performance in resources. First of, it was suggested that module dependencies beminimized by using object-oriented design, and implementing information hiding andencapsulation principles (this was discussed in the module view global analysis). Reuseof modules and subsystems were highly emphasized to promote efficiency and reducecost and time. 22
  • 5. CODE VIEW This section describes how the different modules and subsystems will behierarchically stored. Within our Global Analysis subsection, we have used a factor table,which lists the product, organizational, and technological factors. In the DirectoryHierarchy subsection, we have described how the files and folders should be setup in foroptimal hardware and software performance. Furthermore, we have described how theFlight Simulator will be setup within the root directory, along with the four major sub-directories, and how they are further broken down for modularity.5.1 Global Analysis The purpose of this section is to discuss the different factors that affect the CodeView of the Flight Simulator architecture of the system and defines strategies needed inorder to accommodate these in the design. Concepts such as reuse of code, developmentof software platform and environment, are also examined.5.1.1 Factor Table The following factor table discusses the Product, Organizational andTechnological factors that make up the Global Analysis of the Code View. Product Factor Flexibility and Changeability ImpactP1: Functional FeaturesP1.1: Reuse of CodeReuse of code and subsystems can The amount of reusability is There is a moderate affect on thebe maximized by designing highly negotiable. Some specialized meeting of the schedule.maintainable code, as if the code functionality may not be madecannot be easily changed to suit a easily reusable.new purpose, it is not likely to bereused. Libraries may also becreated to store commonly usedfunctions and classes.Organizational Factors Flexibility and Changeability ImpactO1: Staff SkillsO1.1: Software DesignThe staff should have extensive There is some flexibility. Staff The quality of code produced, and theknowledge of the languages, with experience in similar effective use of language features.platforms, and patterns used to systems may be adequate.build the system.O2: ManagementO2.1: EnvironmentAn aesthetically pleasing This area is negotiable. There is a moderate effect on theenvironment, with adequate Employee relations are meeting of the deadline.incentives for programmers and extremely important in amanagement will produce a better successful project.quality system. 23
  • O3: Process and Development EnvironmentO3.1: Development PlatformThe development platform chosen This is negotiable. The platform There is a moderate effect on theshould support the language used can change depending on meeting of the deadline.chosen, and should be Windows- what will work best for a givenbased, such as JBuilder. task.O3.2: Development EnvironmentThe environment should be This is not negotiable. It would There is a moderate effect on theWindows, as the game is to be be difficult to convert from, for meeting of the deadline.Windows-based. example, a Unix environment to a Windows environment.O4: Development ScheduleO4.1: Delivery of FeaturesThe development platform, The delivery of the features is There is a moderate effect on theenvironment, and schedule must negotiable. meeting of the deadline.all be followed closely in order tomeet the release schedule.O4.2: Release ScheduleThe product can be released in This is flexible. The features There is a moderate effect on thestages, with the most functional important for the first release quality of the first release of thecomponents released first. I.e., a are negotiable. game. The quality of a first-releaseworking version of the game with will be obviously less than a completeminimal types of planes and views version of the game.may be released first, with add-ons released at later dates. Therecan also be multiple versions ofthe game.Technological Factors Flexibility and Changeability ImpactT1: Software TechnologyT1.1: Configuration ManagementConfiguration management This is not negotiable. This affects the overall end product.organises versions and changes tosystem items while keepingcoherency and consistency on thecomplete system. All thesefactors must be considered whencoding.T1.2: Target Environment 24
  • The target environment is This is not flexible. This affects overall quality of theWindows. Windows specific game. A game that doesn’t consideroperations, such typical key Windows-specific operations won’tcommands, must be considered do well in a Windows environment.when designing the code for thegame.5.2 Directory Hierarchy A directory hierarchy is provided below. The root directory will be: C:Program FilesFlight Simulator 98 This is assuming the user is installing the Flight Simulator on hard disk drive witha “C” designation, and is meeting minimum software requirements of running anoperating system, which is Windows 95 or above. The user would have the option ofinstalling the Flight Simulator within another root directory. However, doing so couldreduce overall efficiency and/or performance of the Flight Simulator because thedirectory “Program Files” is a local directory within the Windows operating system. Assuch, this directory cannot be deleted for the reason that it contains vital files and foldersrequired for the Windows operating system to run efficiently. Furthermore, the FlightSimulator needs to interface with the Windows operating system as efficiently aspossible. Consequently, it is highly recommended that the Flight Simulator should beinstalled within the directory called “Program Files”. Since the directory hierarchy is divided into four major folders, each folder isshown in a separate figure. The Simulation Setup folder has to be accessed first in orderto setup the simulation. The Simulation Controls folder, Flight Controls folder, andController folder; are all based upon the Simulation Setup folder and are interdependent.5.2.1 Simulation Setup Folder Figure 13: Simulation Setup Folder 25
  • The Simulation Setup Folder is the 1st folder that will be accessed, for the reasonbeing that the Flight Simulator must be setup by the user in order for the simulation tobegin. Thus, the user is responsible for loading attributes such as the type of plane,airports, and scenery. As shown, there are three sub-directories, Plane, Airports, andScenery. The Plane folder will contain the files for selection of the different planes. TheAirport folder contains two sub-directories within itself called Departure and Arrival,which will store the Departure and Arrival airports, respectively. Finally, we have theScenery folder, which contains the Complexity Levels folder. Based on the complexitylevel selected, the sub-directories of Road, Water, Buildings, and Obstacles, will returntheir respective quantity and quality of these items.5.2.2 Simulator Controls Folder Figure 14: Simulator Controls Folder The Simulator Controls folder will contain the files and folders required to controlFlight Simulator in terms of user options and user views. This folder contains the two-subdirectories, called Simulator Options and Views. The Simulator Options directorycontains subdirectories called Pause/Resume Flight, Sounds, Save Flight, Exit Flight, andRestart Flight; for their respective actions within the Flight Simulator. Similarly, theViews directory contains subdirectories Left, Right, Forward, and Cockpit; for theirrespective views within the Flight Simulator. 26
  • 5.2.3 Flight Controls Folder Figure 15: Flight Controls Folder The Flight Controls folder will contain the files and folders required for flightcontrol, such as movement, altitude, and heading. Thus, the three sub-directories of thisfolder are Movement, Altitude, and Heading. Both the Movement and Headingsubdirectories contain three sub-directories for Left, Right Forward, for their respectiveactions within the Flight Simulator, in terms of Movement and Heading; respectively.The Altitude subdirectory contains two-subdirectories, Increase and Decrease, for theirrespective actions within Flight Simulator. Since the Flight Controls folder has just been defined, an explanation for some ofour assumptions should be made here. Our system does not contain files and folders foritems such as aircraft movement in a backward direction, or freezing the aircraftmovement, altitude, nor heading. Our assumptions are that aircraft cannot movebackwards, and that it would defy the laws of physics to freeze an aircraft in flight. Assuch, we do not feel that within the Flight Simulator, the aircraft should be allowed tomove backwards, nor freeze in movement, altitude, nor heading.5.2.4 Controller Folder Figure 16: Controller Folder 27
  • The Controller Folder will contain the files and folders required for controllingthe Flight Simulator. Input devices such as a keyboard, mouse, and joystick can be usedfor control, and as such, the Controller Folder has three sub-directories for Keyboard,Mouse, and Joystick. However, in order to provide the best simulation possible, it isassumed that the user will use a joystick, and that a keyboard and/or mouse would onlybe used if a joystick was not present. Controlling the movement, along with all of theother features of the Flight Simulator, would be difficult for the user by using a keyboardand/or mouse, and would hinder the simulation experience.6. CONCLUSION As shown by this document, the Component Architecture of the Model-ViewController (MVC) for the Microsoft Flight Simulator requires detailed designs anddescriptions in order to provide a clear and concise technical description of theComponent Architecture of the MVC. We have used standard software engineeringprocedures such as Global Analysis and factor tables for each of our four major sections.Once again, these four sections are the Conceptual View, Module View, Execution View,and Code View. Furthermore, we have implemented industry standard design patterns,such as the Observer Pattern, Command Processor Pattern, Factory Method Pattern,Composite Pattern, and Chain of Responsibility Pattern, within our modules.Additionally, we have examined the execution of the modules and subsystems in terms ofsystem performance in regards to hardware/software requirements, and we have alsodescribed how the files and folders should be setup in for optimal hardware/softwareperformance We are confident that our analysis, development, and design of the ComponentArchitecture of the Model-View Controller (MVC) for the Microsoft Flight Simulator, isapplicable in the actual design and development of this software application. 28
  • 7. GLOSSARYCode View: View showing transitive relationship between runtime entities to deployment entities, and deployment entities to source code entitiesChain of Responsibility Pattern: Behavioral pattern that avoids the coupling of the sender of a request to its receiver, by allowing more than one object the opportunity to handle the request.Command Processor Pattern: Behavioral pattern that encapsulates a request as an object, allowing the parameterization of clients with different requests.Composite Pattern: Structural pattern that composes objects into tree structures to represent part- whole hierarchies.Conceptual View: View showing conceptually how the MVC component is related to the Overall System Architecture.Execution View: View showing relationship between runtime modules and target hardware/software platform.Factory Method Pattern: Creational pattern that defines an interface for creating an object, but allows subclasses to determine which class to instantiate.Factor Table: Table consisting of product factors, organizational factors, and technological factors; along with their flexibility, changeability, and impact.Flight Simulator: Reference to the Microsoft Flight Simulator 98 flight simulation program.Global Analysis: Broad overview of system input, advantages/disadvantages, and output.LOC: Lines of code.Module View: View showing modules and subsystems for the MVC component. 29
  • MB: Abbreviation for megabyte, which is a unit of memory storage.Model-View Controller: Pattern breaking down into three views, Model, View, and Controller; which deal with Processing, Output, and Input respectively.MVC: Abbreviation for Model-View Controller.Observer Pattern: Behavorial pattern that defines a one to many dependency between objects, so that upon a change in state in one object, all dependents of that object are notified and updated automatically.Overall System Architecture: The overall architecture of the Flight Simulator system is divided into a number of components (or subsystems) among which the Model-View-Controller is a part of.Program Files: Windows operating system based directory, which stories crucial files and folders for the execution of applications based on the Windows operating system platform.RAM: Abbreviation for random access memory.Virtual World: The user defined world of Flight Simulator, in terms of initial setup. 30