Detailed Design Document - Middle East Technical University
D-BUGDetailed DesignDocumentDUYGU ARALIOĞLUBEDİA ACARZÜLFÜ ULAŞ ŞAHİNGÜLNUR NEVAL ERDEMMIDDLE EAST TECHNICAL UNIVERSITYCOMPUTER ENGINEERING2011
Detailed Design DocumentD-BUGTable of Contents1.INTRODUCTION . 61.1.Problem Definition . 61.2.Purpose. 71.3.Scope . 71.4.Overview. 71.5.Definitions, Acronyms and Abbreviations . 91.6.References . 92.SYSTEM OVERVIEW . 103.DESIGN CONSIDERATIONS . 113.1. Design Assumptions, Dependencies and Constraints . 113.1.1. Assumptions and Dependencies . 113.1.2. Design Constraints . 123.1.2.2. Performance Constraints. 123.1.2.3. Financial Constraints . 123.2.1. Reliability . 123.2.2. Usability . 133.2.3. Portability . 133.2.4. Extensibility . 134.DATA DESIGN. 134.1.Data Description . 134.2. Data Dictionary . 165.SYSTEM ARCHITECTURE . 215.1. Architectural Design. 215.2. Description of Components . 225.2.1. InputHandler. 225.2.1.1. Processing narrative for InputHandler . 225.2.1.2. InputHandler interface description . 225.2.1.3. InputHandler processing detail. 232
Detailed Design DocumentD-BUG5.2.1.4. Dynamic behavior InputHandler . 245.2.2. Recognizer . 255.2.2.1. Processing narrative for Recognizer. 255.2.2.2. Recognizer interface description . 255.2.2.3. Recognizer processing detail . 265.2.2.4. Dynamic behavior Recognizer . 275.2.3. HMM . 275.2.3.1. Processing narrative for HMM. 295.2.3.2. HMM interface description . 295.2.3.3. HMM processing detail . 295.2.3.4. Dynamic behavior HMM . 305.2.4. InterfaceHandler . 305.2.4.1. Processing narrative for InterfaceHandler . 305.2.4.2. InterfaceHandler interface description . 315.2.4.3. InterfaceHandler processing detail . 315.2.4.4. Dynamic behavior InterfaceHandler . 325.3. Design Rationale . 335.4. Traceability of Requirements . 346.USER INTERFACE DESIGN . 356.1. Overview of User Interface . 356.2. Screen Images. 376.3. Screen Objects and Actions . 397.DETAILED DESIGN . 417.1.InputHandler Component. 417.1.1.Classification . 417.1.2.Definition . 417.1.3.Responsibilities . 417.1.4.Constraints . 417.1.5.Compositions . 427.1.6.Uses/Interactions . 427.1.7.Resources. 423
Detailed Design DocumentD-BUG7.1.8.Processing . 437.1.9.Interface/Exports . 437.2.Recognizer Component . 447.2.1.Classification . 447.2.2.Definition . 447.2.3.Responsibilities . 447.2.4.Constraints . 457.2.5.Compositions . 457.2.6.Uses/Interactions . 457.2.7.Resources. 457.2.8.Processing . 457.2.9.Interface/Exports . 477.3.HMM Component . 477.3.1.Classification . 507.3.2.Definition . 507.3.3.Responsibilities . 507.3.4.Constraints . 507.3.5.Compositions . 517.3.6.Uses/Interactions . 517.3.7.Resources. 517.3.8.Processing . 527.3.9.Interface/Exports . 537.4.InterfaceHandler Component . 547.4.1.Classification . 547.4.2.Definition . 547.4.3.Responsibilities . 547.4.4.Constraints . 547.4.6.Uses/Interactions . 557.4.7.Resources. 567.4.8.Processing . 567.4.9.Interface/Exports . 584
Detailed Design Document8.D-BUGLIBRARIES AND TOOLS . 588.1. Hardware. 588.1.1. Kinect . 588.1.1.1. Description . 588.1.1.2.Usage. 598.2. Software . 608.2.1. Kinect SDK. 608.2.2. Microsoft Visual Studio 2010 Express . 619.10.TIME PLANNING. 62CONCLUSION . 645
D-BUGDetailed Design Document1. INTRODUCTIONThis Detailed Design Document for TSL Kinect project sponsored by INNOVA providesthe complete description of the system. This document also mostly follows thefunctionalities identified in the SRS document of the project, however some changeshas been made in the structural arrangement of the system and all these changes werestated under the related subsections.1.1. Problem DefinitionIn this project our aim is to solve the communication problem between speech-impairedpeople and others. When someone with speech impairment is unable to expresshimself/herself, it can be frustrating. Since almost most of the people do not know signlanguage and cannot understand what speechless people mean by their speciallanguage, tasks such as shopping, settling affairs at a government office are so difficultthat speech-impaired people cannot handle by their own. Our team intends to helpalleviate the frustration that speech-impaired people face by using assistive technology.This project proposes a method that translates sign language in a manner that otherpeople can also understand. More precisely, the final product of the project will get thesign language gestures and give the meaning of them in text format.6
D-BUGDetailed Design Document1.2. PurposeThis SDD provides the design details of TSL Kinect in the scope of Middle East TechnicalUniversity Computer Engineering Department Graduation Project and aims to provide aguide to a design that could be easily implemented by any designer reading thisdocument. Throughout the document design architecture and procedure, constraints,interface design and implementation strategies will be explained in detail.1.3. ScopeThe scope of this SDD is to provide information about the design procedure of thesystem. The design constraints, data design, architectural design and user interfacedesign will be elucidated in the scope of this document. Also chosen helper libraries andcomplete time planning of the system will be included. The intended audience is theones who will implement the project, hence it is aimed that this document to be aguideline for those developers.1.4. OverviewThis SDD is divided into ten sections in order to provide a complete and understandableperception about the system to the target readers. First section is mostly about thescope and purpose of the document. This section also includes the definition of theproblem that is intended to be solved.In the second part, system overview, a general description of the software systemincluding its functionality and matters related to the overall system and its design isprovided. The intended goals, objectives and benefits of the project are stated in thissection, too.7
Detailed Design DocumentD-BUGThe third section states the design considerations and consists of two parts. In the firstpart, design assumptions, dependencies and constraints of the system are defined. Inthe second part, design goals and guidelines are given in terms of reliability, usability,portability and extensibility of the system.The organization of the data structures of the system is explained in section four.Subsequently, a data dictionary is provided in order to provide a detailed description ofthe system major data, including data objects, their attributes and methods.In the fifth section, the architectural design of the application and detailed descriptionof modules are elaborated. In this section, it is also provided a sequence diagram foreach module.Sixth section is all about the user interface design. In this section the functionality andexpected features of the user interface is given. In addition, some possible screenshotsshowing the interface from the user’s perspective are provided and purpose of thescreen objects is explained.In the seven part of the document, the details of each component are explained deeplyby following classification, definition, responsibilities, constraints, composition,interactions, resources, processing and exports issues.In the eighth part, information about the libraries and tools that our project dependedon is given.In section nine, time planning and scheduling issues will be demonstrated by a Ganttchart.The last part covers the summary of the whole document.8
Detailed Design DocumentD-BUG1.5. Definitions, Acronyms and AbbreviationsDefinitions, acronyms and abbreviations are listed in the below table.HMMHidden Markov ModelGUIGraphical User InterfaceWPFWindows Presentation Foundation, is graphical subsystem based onXAML to develop user interfaces in Windows-based applicationsTSLTurkish Sign LanguageSDDSoftware Design DocumentSDKSoftware Development KitXAMLExtensible Application Markup Language1.6. References*1 IEEE Std 1016‐1998: IEEE Recommended Practice for Software Design Descriptions[2] Software Requirements Specification for TSL-Kinect, it was prepared according toIEEE Std 830-1998: IEEE Recommended Practice for Software RequirementsSpecifications[3] A Revealing Introduction to Hidden Markov Modelshttp://www.cs.sjsu.edu/ stamp/RUA/HMM.pdf[4] A. B. S. Hussain, G. T. Toussaint, and R. W. Donaldson. Results obtained using asimple character recognition procedure on Munson’s handprinted data. IEEETransactions on Computers, 21:201–205, February 1972.9
D-BUGDetailed Design Document*5 J. Yang, Y. Xu, “Hidden Markov Model for Gesture Recognition”, The RoboticsInstitute, Carnegie Mellon University, pp. 10, 1994. Retrieved fromhttp://www.ri.cmu.edu/pub files/pub3/yang jie 1994 1/yang jie 1994 1.pdf[6] Getting started with Microsoft Kinect SDK, start 1[7] /08/20/10174036.aspxand (from readme of Kinect SDK)[8] http://en.wikipedia.org/wiki/Kinect[9] Coding4Fun Kinect s/Coding4Fun-Kinect-Toolkit2. SYSTEM OVERVIEWOur software needs a Kinect camera and a personal computer with Windows 7operating system to work. Kinect camera gathers real world images with depthinformation and transfers it to computer via USB. Microsoft Kinect SDK gathers theseimages, processes them and detects skeletal-position information of the user whostands in front of the camera. Software uses position information of the body parts forboth interface control and gesture recognition.10
D-BUGDetailed Design Document3. DESIGN CONSIDERATIONS3.1. Design Assumptions, Dependencies and Constraints3.1.1. Assumptions and DependenciesWhile designing this project, we needed to make some assumptions related to software,hardware and the environment. First of all, our program is intented to run on Windows7 OS. Working platform cannot be changed since the Microsoft official SDK for Kinecthas such a big restriction that it can be used only on Windows 7 platform.Related to hardware, our program will run on computer systems, so the user is expectedto have a computer with dual-core,2.66-GHZ or faster processor and minimum of 2 GBof RAM . Moreover, the graphic card support in Windows for Direct X 9.0c is alsoexpected. The most important requirement as a hardware is the user must have Kinectfor Xbox 360 sensors.Related to environment, since our program is completely about skeleton tracking, theenvironment that the user stands should be clear as possible in order to have a properlyworking SDK and maintain accuracy. We assume that Kinect is set up properly accordingto its manual and the user stands between 1.8 to 2.4 meters away from the Kinectsensors. In our environment, it is also assumed the room that the Kinect is set up is largeenough and there are no moving objects around.There are no restricted features about the user, however; since our system tracks onlyone person’s skeleton user should stand alone in front of the sensors.11
D-BUGDetailed Design Document3.1.2. Design Constraints3.1.2.1. Time ConstraintsBoth the design and implementation parts of the project should be completed withineight months. At the end of the fall semester of 2011-2012 academic year a prototypeneeds to be implemented, so in order to achieve this all group members should strictlyfollow the specified schedule. The detailed schedule can be found in the Gantt charts inthe section 8 of this detailed design report.3.1.2.2. Performance ConstraintsThe system performance strongly depends on the environment that the Kinect is set up.When the environment is so noisy or there are moving objects around the recognition ofthe skeleton cannot be done as desired by SDK. Moreover, the system should recognizethe gesture as fast as possible and return an answer to the user. In order to satisfy theseconstraints, the process running on the background of the application needs to bemodeled with the fastest algorithm as possible.3.1.2.3. Financial ConstraintsProject is financially supported by Innova Bilişim Çözümleri A.Ş in terms of Kinectsensors.3.2. Design Goals and Guidelines3.2.1. ReliabilityOur main purpose is to make the system run without any problems or bugs. In order tomaintain the reliability any performed gesture will be correctly recognized by theimplemented HMM and correct answer will be published if the gesture is in the predetermined gesture list. We will use various testing strategies while designing the12
D-BUGDetailed Design Documentproject in order to improve the performance and decrease the number of errors thatwill occur.3.2.2. UsabilitySince this project intends to simplify speech-impaired people’s lives it should be simpleand functional at the same time. The user interface is kept simple so that the purefunctionality is gathered without being bothered with lots of menus or buttons. Itshould also be stated that not only the sign language translation part but also switchingbetween menus and sub-menus are maintained by the user’s movements. In otherwords kinetic interface is implemented hence the user does not have to use any inputdevice (namely mouse and keyboard) to control the program once it is started.3.2.3. PortabilityThe system will be implemented only into the pc environments having Windows7operating systems which makes the system low-portable.3.2.4. ExtensibilityThis project is designed to be extensible in terms of the number of gestures to berecognized. For the time being the system will recognize 10 pre-defined TSL gestures,however, it will be possible to add new gestures to the programs’ memory by gatheringexperimental data of gestures and training new HMMs.4. DATA DESIGN4.1. Data DescriptionEvery major module and sub-components in the system will be implemented as classes.Our software basically performs a “function” (sign language recognition), and both main13
D-BUGDetailed Design Documentand sub-components will be created to compose a functional program. There will be nodatabase system because the numbers of the components are pre-determined, theircreation will be handled in initialization, their names and duties are restricted and therewill be no structured information transfer between classes. Information transfers will bein simple vectors of primitive types. Also, predetermined gestures will be stored asHidden Markov Model matrices in a simple text file, and transfer of this file to mainmemory will be held in a simple initialization function. So, we decided to removeDatabase module that we defined in the previous requirements specification document.There will be four main classes of our system: InputHandler, Recognizer,InterfaceHandler, and HMM. First three of them will have only one instance, andfunctional structure of the system is built by them. For every sign language gesture thatintroduced to the system, there will be one or two HMMs (this depends on gesturetype) in the Recognizer module. HMMs are also initialized at the beginning of theprogram and never be released.There will be three sub-classes of our system: InterfaceMode, SpaceZoningMatrix, andButton. Button class will contain information about buttons of InterfaceModes, so thisclasses will be elements of InterfaceModes at the beginning. InterfaceModes willcontain specific buttons of all user interface menus of the software (there are four ofthem), and they will also be created by InterfaceHandler at the beginning of theapplication. SpaceZoningMatrices will be created and deleted every time whenInputHandler repeated its functional routine.In the section 4.2, a short explanation of attributes and helper methods of each classwill be provided. The fundamental functional structures of main components, and theway of assisting attributes, helper methods and subclass objects in these structures willbe explained together with algorithmic details in section 5.14
Detailed Design DocumentD-BUGFigure 1: Class Diagram of the System15
D-BUGDetailed Design Document4.2. Data DictionaryInputHandler:Attributes: matrix (spaceZoningMatrix): This object will be created and initialized with everynew input comes to InputHandler.Methods: initialization(): voidThis method initializes all other components andcreates pre-defined class instances.Recognizer:Attributes: activationState (boolean): This variable determines whether the Recognizer isactive or not. hmm (HMM[]): This array holds all HMMs in the system. leftHandLastPosition (int): This variable contains the last position of left handthat comes from InputHandler. leftHandStack (int*): This stack holds different consequent positions of left hand. leftHandTimer (int): If left hand does not change its position, this variableincrements. leftObservationList(int *): the list that keeps observation sequence for left handwhich will be sent to HMM16
D-BUGDetailed Design Document rightObservationList(int *): the list that keeps observation sequence for righthand which will be sent to HMM rightHandLastPosition (int): This variable contains the last position of right handthat comes from InputHandler. rightHandStack (int*): This stack holds different consequent positions of righthand. rightHandTimer (int): If right hand does not change its position, this variableincrements.Methods: activate():voidThis method sets activationState true. deactivate():voidThis method sets activationState false.HMM:Attributes: alphaMatrix (double[][]): This matrix contains scaled alpha values of each statecalculated at each pass. endRange (double[]): This array contains possible end positions of the gesture asSpaceZoningMatrix indices gestureMeaning (string): Holds the corresponding meaning of the gesture. handName (string): This variable determines which hand’s movement will berecognized by HMM (left or right). howManyHands (boolean): This variable tells if related gesture is composed ofone or both hands movements.17
D-BUGDetailed Design Document initialProbabilityMatrix (double[][]): This matrix contains probabilities whichdetermine the initial state. maximumObservation (int): This variable determines the maximum number ofmatrix indices that gesture can be represented by. minimumObservation (int): This variable determines the minimum number ofmatrix indices that gesture can be represented by. observationMatrix (double[][]): This matrix matches each states and eachdiscrete observations with probability values. observationNumber (int): This variable holds the number of observations in themodel. scalingCoefficients (double[]): This array contains scalars calculated for each passof forward algorithm. startRange (int[]): This array contains possible start positions of the gesture asSpaceZoningMatrix indices stateNumber (int): This variable holds the number of states in the model
interface design and implementation strategies will be explained in detail. 1.3. Scope The scope of this SDD is to provide information about the design procedure of the system. The design constraints, data design, architectural design and user interface design will be elucidated in the scope of this document. Also chosen helper libraries and
National Geographic’s current political map of the Middle East includes Pakistan, Afghanistan, and Central Asia, and partially cuts off Egypt and Turkey. Middle East Policy Council Teaching the Middle East:
1. globalism, regionalism and the middle east ayşegül sever 16 2. the challenges to middle eastern international society: a study in disorder onur erpul 32 3. united states foreign policy in the middle east after the cold war jonathan cristol 48 4. russian foreign policy in the middle east under putin: can bears walk in the desert?
janus et cie waterworks safavieh l e xin g t on a venu e t h ir d a venu e s e c on d a v e nu e east 55th street east 5th street east 5th street east 5th street east 59th street east th street east d street east d street east s t street tutenkian artisan carpets the catholic center of an a sa tvern
Stemmers Run Middle White Oak School Windsor Mill Middle Woodlawn Middle Caroline Col Richardson Middle Carroll Crossroads Middle Cecil Elkton Middle Charles General Smallwood Middle R.D. Stethem Ed Center Dorchester All schools are enrolled in CEP! Harford Center for Ed Opportunity Alt
031901043 faulk middle: sw 96.54%: 031901044 stell middle: sw 95.70%: 031901045 oliveira middle: sw 94.80%: 031901046 perkins middle: sw 97.41%: 031901047 vela middle: . a p solis middle sw 88.35% 108902046; veteransmiddle sw 92.36% 108902047; dora m sauceda middle sw 97.34% 108902048; w a todd middle sw 93.21% 108902102;
cultures in the Middle East. There are several religions in the Middle East. Many Muslim beliefs are similar to ours. The status of Middle Eastern women is complex. Middle Eastern attitudes toward the U.S. are complicated.
The Middle East played a major role in World War I, and, conversely, the war was important in shaping the development of the modern Middle East. One might even say that World War I began and ended with Middle East-related conflicts. (The beginning, the event that formed the
to the Middle East in the decades following World War II was only a small fraction of current aid flows. However, beginning in the early 1970s, the United States dramatically increased its foreign assistance to the Middle East. After the U.S. withdrawal from South Vietnam, the Middle East as
