Software Engineering II
Software Engineering II CSCI 3350
Popular in Course
verified elite notetaker
verified elite notetaker
verified elite notetaker
10216 - BIO 105 - 04
verified elite notetaker
verified elite notetaker
verified elite notetaker
Popular in Communication Studies
This 14 page Class Notes was uploaded by Amira Von on Sunday October 11, 2015. The Class Notes belongs to CSCI 3350 at East Tennessee State University taught by Vernon Pine in Fall. Since its upload, it has received 15 views. For similar materials see /class/221376/csci-3350-east-tennessee-state-university in Communication Studies at East Tennessee State University.
Reviews for Software Engineering II
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/11/15
Modifying MVC for Web Applications Adam Ogle Fall 2008 Research Methods A Web application is a relatively new type of application that resides on a remote server and interacts with multiple users on remote computers Because of the stateless nature of the hypertext transport protocol HTTP traditional application architectures must be modi ed in order to maintain state on behalf of an application s users One architecture that appears to be easily modi able for web application use is the Model View Controller MVC design pattern The MVC pattern represents a major departure from traditional strategies for developing interactive applications Most interactive traditional and web applications use a procedurebased approach to manage user interactions they retrieve data from storage display this data retrieve users changes and update storage This approach makes it dif cult to change the application s user interface independently from its typically more stable business logic The approach also obscures the application s business rules making them more dif cult to maintain The MVC pattern separates an application s business logic from the application s user interface This separation is accomplished using three kinds of elements controllers models and views Controllers receive user requests from views such as button clicks in the form of messages Controllers then respond by translating a message into a series of function calls that may modify the model or update a view Models implement an application s domain logic also known as its business logic Models interface to controllers through function calls that manipulate and retrieve the model s state Views present content to users Views do not implement business logic they merely present modelgenerated state and con gure controllergenerated messages for display Separating an application s presentationiie its viewsifrom its data management logiciie its controllers and modelsiallows controllers and models to be tested independently of the user interface This separation also allows views controllers and models to be modi ed independently from 1 one another so long as their API s remain stable In practice however changes to controllers and models typically affect these components interfaces An update to a model will usually produce changes in an application s controllers and views Similarly an update to a controller will usually produce changes in an application s views This loose coupling of views to models is not possible when multiple applications manipulate and modify shared content Shared content becomes an issue for example when different applications post messages to a shared log Ideally it should be possible for a realtime log viewer s View components to respond directly to these updates but pure MVC does not allow for this A workaround for this problem involves creating a central model and applying an Observer design pattern to it Event handles are added to the central model which allow the model to signal changes to the applications that use this model Model functions that change data are responsible to raise an event related to the change The applications views are responsible for attaching to the event handle and implementing the necessary update logic For the realtime log viewer a change of the logs modi cation date should re an update event Subscribing views should then query this model for the logs entries In more compleX applications more speci c event handles can be generated to reduce the amount of unnecessary view updates and model queries In Objects and the Web Alan Knight and Naci Dai present an objectoriented approach to creating maintainable web applications Knight and Dai contrast their approach with the typical rapid developmentbased approach to software development which they say produces monolithic and poorly differentiated applications According to Knight and Dai web applications can be decomposed into four parts which handle an application s inputs application logic business logic and outputs Dai amp Night 2002 The input logic is responsible for accepting and validating input strings and possibly converting them to other formats for use by the application s other components The application logic handles transitions between a page s states for example transitions between logic elements that display and process a page s form The business logic handles all logic that de nes an application s domain The output logic handles displaying the application s state to the user When web applications are produced using nonobjectoriented strategies for application design the resulting application s maintainability suffers due to duplicated logic and an intermingling of the four kinds of functionality ie o The input logic s conversion and validation functions are included in many pages As a result of this duplication keeping the input layer consistent involves ensuring changes are synchronized among pages 0 The application s ow control dataithe data that determines page stateiis passed between pages in a weaklytyped global dictionary of string object pairs This mechanism creates a need for replicating ow logic between pages which makes it dif cult to ensure that values are interpreted consistently throughout the application 0 The business logic layer consists of all code that de nes an application s domain This code is also intermingled with code from the other layers which complicates the identi cation and updating of an application s business rules 0 The output layer logic is tightly coupled with the business logic making it dif cult to distinguish from the other layers A change to an output statement might inadvertently change a business rule Knight and Dai s strategy for architecting web applications is a modi ed version of MVC called Web Actions A Web Actions application consists of ve elements an input controller a set of application controllers a set of actions a set of business objects and a set of views An input controller is a logic element that parses requests and passes them to application controllers A request is a URL with GET or POST data that is sent when a user interacts with a page such as clicking a link The input controller parses the data passed passing the data to an application controller to interpret An application controller is an object that acts as the application s dispatcher and state manager The controller s responsibilities include coordinating logic related to application ow handling errors maintaining longterm state and determining which View to display Dai amp Night 2002 An application controller receives the data from the input controller and determines what action to perform An action is an event handler called by an application controller to do a set of tasks An action should receive only that data that it needs to do its task Each task in turn is realized as a series of function calls that manipulate the application s business logic Business objects handle operations and state relevant to the application s domain Business objects are loosely coupled with the other system elements segregating the business logic Due to the segregation business objects should provide a carefully de ned interface that supports the retrieval and manipulation of object data by actions and views A view is a server page that presents data from business objects For maintainability views are required to treat business objects as readonly objects only functions needed to adapt the data for presentation are allowed in server pages Knight and Dai de ne the operation of a web actions application in terms of a sequence of ve states initiated by an interaction buttonlink click with the view In the rst state the input controller determines which application controller is responsible for the current request Dai amp Night 2002 In the second the indicated application controller accepts input retrieving the needed session and POSTGET variables to pass to the action In the third the controller invokes the required action In the fourth the application controller forwards control to the requested view Finally the view queries the business logic for the data it needs to present formats the data for presentation and updates the view The authors discuss two useful variations of Web Actions compleX views and action conteXt A compleX view is a composition of simple views in a single view A web application such as an Internet portal could be composed of several smaller views called applets eg an email client news story list weather tracker and search box Depending on the user request different applets could appear on the page even in different locations The other variation action conteXt allows an action s interpretation to 4 depend on the controller that executes an action The action context pattern supports the use of generic actions such as add and delete that vary by page This is similar to de ning abstract functions for concrete classes to implement The variations enhance an application s exibility while increasing its complexity In A Novel Web Application Frame Developed by MVC authors GuangChun Lu and Hanhong describe another MVCbased web application framework This framework is divided into three elements that closely resemble MVC a SYSController Model Center and LPM Center The SYSController s role is similar to the controller s role in the MVC framework the SYSController determines the userrequested action and then directs the model to do that action The SYSController however communicates with the controller using a shared le rather than a function call This le is an XML le that stores valid actions function calls pairs in a tree Each of this tree s interior nodes store function calls that are common to all of that node s children For example a create student and create teacher node might share a parent node with a stored function call that checks the requesting user s permissions This strategy in effect shifts responsibility for interpreting requests to the model allowing actions to be created or changed without modifying the controller Once it determines the function calls for the userrequestedaction the SYSController wraps the function calls in messages and passes them to the Model Center The Model Center is similar to MVC s model element it acts as a front for a database that maps the function calls to appropriate business logic elements Upon receiving a message the Model Center retrieves all needed business logic elements and executes the requested function calls Once it executes the function calls the Model Center wraps the results in another message and passes it to the LPM Center The LPM Center the framework s last element manages a collection of view elements The LPM Center uses a database to retrieve these views thereby removing the views from the framework code After receiving a message from the Model Center and determining which view to render the LPM Center populates this view s data elds and sends the view to the client s browser The authors suggest a modi cation for the Model Center to make it scale better for larger websites Currently when the web application framework processes an action a new instance of a Model Center is instantiated While this is acceptable for small web applications larger applications cannot tolerate the inef ciency The suggested modi cation instantiates Model Center once for all clients adding a queue to accept incoming messages from all clients thereby eliminating duplication and allowing for the parallel processing of queue items While the task of indicating which functions can be done in parallel is involved parallelizing processing would increase throughput especially if most actions are parallelizable data queries rather than data updates While the Web Actions and GuangChun frameworks appear to be competing architectures for a web application framework they are targeted at different sizes of web applications Night and Dai s framework is a simple translation of MVC to the web platform with little overhead This is appropriate for small applications where the risk of the framework being larger than the actual presentation and data management might occur For larger applications GuangChun Lu and Hanhong s framework is more desirable as it seems more robust and less coupled to the speci cs of any web application The framework would be implemented once separate from the actual applications and tested thoroughlyi reducing the testing required in future applications Testability combined with the modularity provided by different data stores holding models controllers and views allow for a more scalable framework Despite these differences both applications offer the ability to have the presentation be developed in parallel to the data management due to the separation of the two components They both approach to web design represents a miX of layered and object oriented strategies for application design which is better than an unstructured application Unfortunately both architectures yield larger applications than nonobjectoriented design approaches but the resulting architectures simplify testing and maintenance which are generally the more eXpensive processes of software engineering In Building User Interfaces for ObjectOriented System Alan Holub a critic of the MVC architecture argues that MVC is not object oriented and is not a suitable applicationlevel architecture In Holub s view a sound object oriented design is one whose classes hide their implementations including 6 their data Holub regards get and set functions which return data private from an object as Violations of good 00 design Instead of asking an object for data to manipulate a client object should ask that object to manipulate data on the class s behalf By only allowing interaction with the object through manipulation request functions the object s internals can change without affecting other classes This encapsulation includes user interface UI elements a class should be responsible for managing how it presents itself to a U1 whether GUI or CLI If any of these principles are Violated by any of a system s objects then the system is not object oriented When testing the MVC architecture s object orientedness against Holub s de nition of object oriented MVC fails because there s just too much data owing around the system to be maintainable Holub 1999 MVC s use of crosscutting layers to separate presentation logic from business logic runs counter to Holub s principle that objects should manage their own interactions with a U1 Without get and set functions MVC will not work as it cannot eXtract the data from the business logic objects for a View to render Furthermore the code to retrieve and render data is separatedithis becomes an issue when maintaining the system as code must be updated in at least two locations With an object oriented system though the change would be contained within a single class Because of the architecture of MVC it seems dif cult for it to conform to Holub s de nition of object oriented Unfortunately Holub s View on how web applications should be designed is unclear from his presentation In a followup article entitled More on Getters and Setters Holub clari es his View on objectoriented application design Holub s idea that a client object should ask an object to do a task is easy to accept when applying it to business logic objects A client object should not ask for as employee s wage increment it by an amount then store it back in the employee a client object should request that employee s wage be increase by an amount and let the employee object handle the actual incrementing The problem with Holub s View arises when attempting to design objects that handle how they are rendered by an application s UI In its most basic form Holub s precept would mean adding a renderO function to each object While this strategy might suf ce for simple applications attempting to incorporate multiple strategies for object representation would be clumsy and dif cultiespecially 7 when attempting to anticipate requirements for representations that are unknown when an object is designed Holub s solution is to use the Builder design pattern to eXtract and abstract the rendering functionality A Builder pattern is a more advanced version of an Abstract Factory pattern that allows an object to generate another object while abstracting the process of how it is generated This works well for business logic objects because the actual UI code is removed from the class Instead a business logic object contains an exporthstractBuilder obj function that requires a concrete builder parameter The business logic object de nes an interface of functions that the business logic object can call to send attributes to the builder Holub makes a point to use the word attribute for this part of the process as an object has attributesihis view of 00 does not intend to hide the fact that they eXist but the information on how they eXist The example he gave uses strings to pass information to the buildericompleX objects are not generally needed for an object to render itself Implementing a concrete builder involves implementing the interface speci ed by the business logic object and adding a get function to retrieve the nal product from the builder The get function then assembles the data passed from the business logic object into a desired object and returns it to the client object The get function is not part of the business logic object s interface with the builderi allowing the builder to determine what type of object is returned This solution seems to run counter to Holub s distrust of getters but Holub clari es his point on not using get and set functions Holub s get function is really a factoryiit doesn t directly retrieve an internal value from the object With this solution a business logic object may rarely change but the builder objects may vary freely If a new UI is needed for a business logic object a new concrete builder may be written and instantiated with no modi cation to the business logic object This effect is eXtremely similar to the effect MVC achieves except no get functions are required in any business logic objects Holub s other issue with MVC is the use of set function in business logic objects In web application programming set functions are a seeming necessity as an object could be populated with data from a form or a database Holub addresses this problem with a weak solution that potentially g violates his objectoriented rules Similar to the Builder pattern Holub proposes a reverse builder that is responsible for retrieving the values needed to initialize an object A business logic object speci es an interface for a reverse builder to implement containing get functions for the reverse builder to implement The reverse builder is responsible for providing the values whether through a database or a website s session data A business logic object implements a constructor that takes a reverse builder as a parameter and calls the get functions in the reverse builder to retrieve the values needed to populate the business logic object Holub eXplains that the get functions inside the reverse builder should be as abstract as possibleipreferring stringsibut admits that the functions are still get functions accessing the reverse builder s implementation speci c data Overall he feels that this implementation is better as only the importer and exporter class have get and set functions and they only apply to the object s interface they have implemented Although Holub s principles seem sound a wellthoughtout set of set and get functions in an object would accomplish the same task more quickly and simply Holub s ideas on objectoriented program while rough seem to be applicable to MVC for web applications Instead of discarding MVC I propose a more objectoriented web application framework entitled WebMVC The system s controller will consist of a message receiver message parser and a controller The message receiver receives messages from the UI and instantiates the appropriate controller Inside the controller is a parser that eXtracts all data needed for the message s associated function calls In the event a business logic object must be instantiated from POST GET or database data the necessary concrete implementation DBImporter FormImporter of the object Importer interface will be instantiated and passed to the object s constructor The controller s nal function call will render the requested view The view contains a single public function named render that renders the page to the browser For consistency a view would have an abstract base class that is responsible for rendering the page s default look header footer navigation placement Each concrete view would then add any eXtra data that needed to be rendered to the screen by retrieving the needed business logic objects using 9 importers or parameters passed to the function and call each object s export functions as needed If an object needs to display a form a different exporter would be usediwhich would be paired with a form importer for the next message sent to the message receiver Consider a simple web portal that allows a user to specify widgets on their screen When a user requests their page the controller could load a user through the user s importer that reads the user s cookie Once the importer reads the cookie a query would be made to the database to retrieve information on all the widgets the user has selected for display Each widget would be instantiated with its own importer using the database s retrieved data The controller would then call a view s render function passing it the user object The view would then render the portal s header and call the user s export using a default portal view exporter The exporter would be responsible for displaying all of the user s widgets by calling each widget s export Finally the view would render the portal s footer and the page will be complete 10 References Dai N amp Night A 2002 Objects and the Web IEEE Software 5159 GuangChun L Lu W amp Hanhong X 2003 A Novel Web Application Frame Developed by MVC ACM SIGSOFTSoftware Engineering Notes 7 Holub A 1999 July Building user interfacesfor object oriented systems Retrieved September 18 2008 from JavaWorldcom httpWwwjavaworldcomjavaworldjw07l999jw07 toolboxhtml Holub A 2004 January 2 More on Getters and Setters Retrieved October 16 2008 from JavaWorldcom httpWwwjavaworldcomjavaworldjw012004jW0102 toolboxhtmlpagel Microsoft Corp 2008 Model View Controller Retrieved September 28 2008 from Microsoft Developer s Network httpmsdnmicrosoftcomenuslibraryms978748printerast 11 Design Document Specification Cover sheet containing a Title e g Design Document for ETC b Submitted to c Prepared by Individuals and organization d Date Table of Contents Revision History 1 Introduction a Overview b Purpose and Scope of the document c Structure of the document 2 System Overview Design Considerations a Assumptions b Constraints c System environment d Design methodology e Risks 4 System Architecture a Architectural Design b Design Rationale 5 Component Design a Static design b Dynamic design 6 Data Design a Internal data description b Global data description c External data structures d Data dictionary System Interface Description a External system interfaces 8 User interface design References E gt1 Appendix A Glossary Appendix B Data Dictionary Appendix C Others as required Annotated Specification 1 Introduction This section provides an overview of the software design document SDD a Overview Highlevel description of the system and the relationship of this document to the system b Purpose and Scope of the document Describe the purpose of this document and its intended audience c Structure of the document Describe the format and structure of the remainder of this document 2 System Overview This section describes the highlevel overview of the functionality and context of the system 3 Design Considerations Assumptions Describe any assumptions background or dependences of the system its use operational environment Anything that you are assuming that directly affects the design Constraints Describe any constraints that have a significant impact on the system Examples are technology constraints performance issues and user characteristics Also anything the customer has specified eg the system will use MYSQL System environment The hardware and software within which the system must operate and interact Design methodology Briefly summarize the approach used to design the system Risks Briefly describe any risks that have been identified Include only technical risks not management customer or external environment risks 4 System Architecture This section describes the highlevel system architecture of the system a Architectural Design Provide the highestlevel view of the system with at least1 figure showing the system decomposition into first level subsystems Describe how the subsystems collaborate to achieve the needed functionality b Design Rationale Describe the decisions that were taken in the selection of the architecture 5 Component Design Describe the decomposition of the subsystems into components a Static design Organize this section by subsystems as appropriate Include functional decompositions or objectclass diagrams as appropriate Describe each class s responsibilities and describe each method b Dynamic design Organize this section by functionality or use case Describe how the components collaborate to provide the functionality Include sequence diagrams and state machine diagrams if appropriate E 0quot 0 2391 FD 6 Data Design Describe all data structures used including internal global temporary and external data structures used by your program a Internal data description Describe any data structures that are passed between the software components b Global data description Describe any data structures that are available to the system components c External data structures Describe any external data structures such as databases that are created or accessed by the system d Data dictionary The data dictionary describes each data element in the system If large can provide a reference to separate document or an appendix System Interface Description a External system interfaces Describe the interfaces to other hardware computers or special devices products or networks User interface design A description of the user interface design including screen shots and the location of a working prototype gt1 9 gt0 References Citations of any references in the text Appendix A Glossary A complete definition of all terms and acronyms used in this document Appendix B Data Dictionary if too large to include in body of the document Appendix C Others as required