1.0 Introduction1.1 Goals and objectives1.2 Statement of scope1.3 Software context1.4 Major Constraints2.0 Data design2.1 Internal Software Data Structure2.2 Global Data StructureThe data acquired by the application will be stored within iOS Core Data. Core Data is available for use in this project because the programming is being implemented using version of Xcode that is compatible. The Core Data will allow us to save model objects to a file and then retrieve those objects when we weed to use them again. Core Data also automatically handles any changes that are made to a model, which helps with versioning and editing. Since the user has the ability to save his or her password and username, those variables will be stored within Core Data as a token. As long as the token exists, the password and username will be kept.2.3 Temporary data structure2.4 Database Description3.0 Architectural and component-level design3.1 Program Structure3.1.1 Architecture diagram3.1.2 Alternatives3.2 Description for View3.2.1 Processing narrative (PSPEC) for View3.2.2 View Interface Description3.2.3 View Processing Detail3.2.3.1 Interface descriptionThe interface for the view will be what the user will see on every screen. When the user goes to the login screen the view component will be displayed. The interface for each view will be controlled mainly by the user except for the occasional Tweet update that would bump the rest of the Tweets on a timeline down.3.2.3.2 Algorithmic model (e.g., PDL)The algorithm for the view is simple. When any action has been triggered by the user the view sends the specific action data to the controller.3.2.3.3 Restrictions/limitationsThe view cannot access model functions and data directly. The view must go through the controller. The view does not handle any data directly except for actions.3.2.3.4 Local data structuresGUI display and IBAction data.3.3 Description for Controller3.3.1 Processing Narrative (PSPEC) for Controller3.3.2 Controller interface description3.3.3 Controller Processing Detail3.3.3.1 Interface descriptionThe interface for the controller is internal only. Only the view and model can send the controller data, and the controller can only send data to the model and the view.3.3.3.2 Algorithmic model (e.g., PDL)The algorithm for the controller is also simple. When an event handler is called the function(s) in the model is called and then the returned data from the model is sent back to the view to be displayed.3.3.3.3 Design constraintsThe controller cannot call other event handlers from within itself or Twitter API functions.3.4 Description for Model3.4.1 Processing narrative (PSPEC) for Model3.4.2 Model interface description3.4.3 Model Processing Detail3.4.3.1 Interface descriptionThe interface for the model connected to the app and the Twitter API.3.4.3.2 Algorithmic model (e.g., PDL)The algorithm for the model is also fairly simple. The model waits for a function call. When a function is called the code is executed (e.g. Twitter API request) and then the data returned by the API request is in turn returned to the controller.3.4.3.3 Restrictions/limitationsThe number of calls to the API is restricted. See Section 5.0.3.4.3.4 Local Data StructuresModel stores any parameters passes to it and data returned to it via the Twitter API.3.4.3.5 Design ConstraintsThe model cannot display data directly.3.5 Software Interface Description3.5.1 External Machine Interfaces3.5.2 External System Interfaces3.5.3 Human Interface4.0 User Interface DesignThe following section provides screen shots of the user Login screen and the Timeline screen that the user will be presented with upon startup of the application.4.1 Description of the User Interface4.1.1 Screen Images4.1.1a Login Screen4.1.1b Objects and actions4.1.1c Timeline Screen4.1.1d Objects and Actions4.2 Interface Design Rules4.3 UIDS Description5.0 Restrictions, limitations, and constraints6.0 Testing Issues 6.1 Classes of tests6.1.1 Incorrect Username6.1.2 Incorrect Password6.1.3 Invalid Tweet entered6.1.4 Invalid Search Entered6.1.5 API Request Limit Reached6.2 Expected software response6.2.1 Incorrect Username/incorrect Password6.2.2 Invalid Tweet Entered6.2.3 Invalid Search Entered6.2.4 API Request Limit Reached6.3 Performance Bounds6.4 Identification of Critical Components7.0 Gantt Chart8.0 Appendices8.1 Packaging and Installation IssuesTwitter iPhone ClientCS 430 Design SpecificationMarch 15th, 2011Sean AdamRyan ColosimoNathan GladyszJames SmithiPhone Twitter Client Software Design SpecificationTable of Contents1.0 Introduction...........................................................................................................41.1 Goals and objectives........................................................................................................41.2 Statement of scope..........................................................................................................41.3 Software context..............................................................................................................41.4 Major Constraints............................................................................................................52.0 Data design.............................................................................................................52.1 Internal Software Data Structure.....................................................................................52.2 Global Data Structure.......................................................................................................52.3 Temporary data structure.................................................................................................52.4 Database Description.......................................................................................................63.0 Architectural and component-level design..............................................................63.1 Program Structure............................................................................................................63.1.1 Architecture diagram.....................................................................................................63.1.2 Alternatives...................................................................................................................73.2 Description for View........................................................................................................73.2.1 Processing