Jan 2011
Lecture 8
27/01/11 01:32
Topic 8: Model-View-Controller: The Basic Architecture
- further discussion of DotPanel and its role in DrawVersion6.java
- coverage of the roles of the model, view, and controller aspects of an application
Learning Objective: can you explain why a modification to the model (in this case, an object of type SimpleThreeDotModel) has the result that a portion of the screen gets redrawn by the window manager?
Class discussion of the URL-based labtests from the week 3 labtests
*assumption: all students have downloaded and successfully invoked the L7L8 example applications from the "Course Materials" section of this site.
The Model-View-Controller (MVC) Paradigm
The MVC paradigm isolates "domain logic" (the application logic for the user) from the user interface (input and presentation),
permiting independent development, testing and maintenance of each (separation of concerns).
The model
- manages the behavior and data of the application domain
- responds to requests for information about its state (usually from the view),
- responds to instructions to change state (usually from the controller).
- notifies observers (usually views) when the information changes, so that they can react.
- is both the data and the business/domain logic needed to manipulate the data in the application
- In sum, the model holds all of the data, state, and application logic. The model is oblivious to the view and the controller, although it provides an interface to manipulate and retrieve its state and it can send notifications of state changes to observers.
The view
- Renders the model into a form suitable for interaction, typically a user interface (which itself is a set of interactive elements (widgets), which are hierarchically composed)
- Multiple views can exist for a single model for different purposes.
- In sum, the view provides a presentation of the model. The view gets the state and the data it needs for its display directly from the model. The view is an observer of the model, so that when the model changes, the view knows that it is time to update itself.
The controller
- receives input and initiates a response by making calls on the model.
- accepts input from the user and instructs the model to perform actions based on that input.
- In sum, the controller takes the user input and figures out what it means to the model
- further discussion of DotPanel and its role in DrawVersion6.java
- coverage of the roles of the model, view, and controller aspects of an application
Learning Objective: can you explain why a modification to the model (in this case, an object of type SimpleThreeDotModel) has the result that a portion of the screen gets redrawn by the window manager?
Class discussion of the URL-based labtests from the week 3 labtests
*assumption: all students have downloaded and successfully invoked the L7L8 example applications from the "Course Materials" section of this site.
The Model-View-Controller (MVC) Paradigm
The MVC paradigm isolates "domain logic" (the application logic for the user) from the user interface (input and presentation),
permiting independent development, testing and maintenance of each (separation of concerns).
The model
- manages the behavior and data of the application domain
- responds to requests for information about its state (usually from the view),
- responds to instructions to change state (usually from the controller).
- notifies observers (usually views) when the information changes, so that they can react.
- is both the data and the business/domain logic needed to manipulate the data in the application
- In sum, the model holds all of the data, state, and application logic. The model is oblivious to the view and the controller, although it provides an interface to manipulate and retrieve its state and it can send notifications of state changes to observers.
The view
- Renders the model into a form suitable for interaction, typically a user interface (which itself is a set of interactive elements (widgets), which are hierarchically composed)
- Multiple views can exist for a single model for different purposes.
- In sum, the view provides a presentation of the model. The view gets the state and the data it needs for its display directly from the model. The view is an observer of the model, so that when the model changes, the view knows that it is time to update itself.
The controller
- receives input and initiates a response by making calls on the model.
- accepts input from the user and instructs the model to perform actions based on that input.
- In sum, the controller takes the user input and figures out what it means to the model
Lecture 7
25/01/11 01:32
Model-View-Controller: Separation of Model and View
-lecture covered the series of examples DrawVersion1.java up to DrawVersion5.java
-Learning Objective: be able to understand and to explain the nature of the modification that is made from one example in the series to the next. For instance, can you explain what was done to DrawVersion1.java in order to turn it into DrawVersion2.java, and so on.
The most challenging material of this module is the difference between DrawVersion5.java and DrawVersion6.java. This entails reading and understanding the API of the class DotPanel.
-lecture covered the series of examples DrawVersion1.java up to DrawVersion5.java
-Learning Objective: be able to understand and to explain the nature of the modification that is made from one example in the series to the next. For instance, can you explain what was done to DrawVersion1.java in order to turn it into DrawVersion2.java, and so on.
The most challenging material of this module is the difference between DrawVersion5.java and DrawVersion6.java. This entails reading and understanding the API of the class DotPanel.
Lecture 6
20/01/11 01:32
Topic 6: Basics of Aggregation
• coverage of sec 8.1.1-8.1.4, with the exception of the latter part of sec 8.1.3
- recap of terminology from Fig 2.9 concerning feature, method, attribute, field.
one of the "take home" messages: the underlying issue with the topic of aggregation/composition is one of "power" (as in the power for a client to (potentially) modify an attribute of an object (suppose we call it A), where that attribute is itself an object (suppose we call it B). The fact that object A can have an attribute of type B is unremarkable. We already know that objects can have attributes of primitive and non-primitive types. The issue here is how do clients gain access to the attributes of object A (if at all).
One mechanism for clients to gain access to a class' attributes is if the class' implementer sets their visibility to public. This renders the attribute public, thus making it a field (e.g, Fraction.separator is the way in which a client can gain access to the field called "separator" of the class Fraction). But we covered in class the reasons why this design practice is frowned upon (see "In More Depth 2.6").
The other mechanism for clients to gain access to a class' attributes is if the class' implementer provides an accessor method (eg the "getSeparator()" method of Fraction). But what is the nature of the object that is returned by the accessor? Is it a reference to the actual object B or is it a reference to a object C, which is merely a copy of the object B. Clearly, if the implementer returns a copy, then this can allow the client to satisfy its curiousity about the state of object B, but the client will not be able to (purposely or inaderventently) modify the state of B.
• coverage of sec 8.1.1-8.1.4, with the exception of the latter part of sec 8.1.3
- recap of terminology from Fig 2.9 concerning feature, method, attribute, field.
one of the "take home" messages: the underlying issue with the topic of aggregation/composition is one of "power" (as in the power for a client to (potentially) modify an attribute of an object (suppose we call it A), where that attribute is itself an object (suppose we call it B). The fact that object A can have an attribute of type B is unremarkable. We already know that objects can have attributes of primitive and non-primitive types. The issue here is how do clients gain access to the attributes of object A (if at all).
One mechanism for clients to gain access to a class' attributes is if the class' implementer sets their visibility to public. This renders the attribute public, thus making it a field (e.g, Fraction.separator is the way in which a client can gain access to the field called "separator" of the class Fraction). But we covered in class the reasons why this design practice is frowned upon (see "In More Depth 2.6").
The other mechanism for clients to gain access to a class' attributes is if the class' implementer provides an accessor method (eg the "getSeparator()" method of Fraction). But what is the nature of the object that is returned by the accessor? Is it a reference to the actual object B or is it a reference to a object C, which is merely a copy of the object B. Clearly, if the implementer returns a copy, then this can allow the client to satisfy its curiousity about the state of object B, but the client will not be able to (purposely or inaderventently) modify the state of B.
Lecture 5
18/01/11 01:32
Topics
1. Basics of Graphical Display
2. Separation of Model and the View
3. The Graphics2D class
Additional Notes
1. Basics of Graphical Display
2. Separation of Model and the View
3. The Graphics2D class
1. Basics of Graphical Display
2. Separation of Model and the View
3. The Graphics2D class
Additional Notes
1. Basics of Graphical Display
- take-home message: graphical display entails a considerable amount of low-level hardware detail; it is desirable to encapsulate all of that low-level detail and then to deal with the graphical display at a more abstract level
- computer displays consist of pixels (picture elements), which is the smallest single component of a digital image. They are normally arranged in a regular two-dimensional grid (possibly staggered).
- The number and arrangement of the grid depends upon the display (e.g., VGA display of 640x480 vs higher-end display of 1920×1200). The number of distinct colors that can be represented by a pixel depends on the number of bits used to specify each pixel's value. One bit means two possible values, so 1 bit per per pixel means that the graphics sub-system can either turn the pixel on or off (think of early-generation e-ink, although e-ink is now capable of having multiple possible pixel values). Larger number of bits per pixel mean a larger range of colour. Don't assume that the number of bits per pixel is eveny divided among the colours sub-components (e.g., the red, blue, and green element of the pixel). Some colours get a smaller range of possible values (this tailors the display to the properties of the human vision, for which the ability to distinguish among close shades depends on the particular color - e.g., red vs blue).
- Think of what this means for display - suppose I wanted to cause a circle to appear in the middle of my display window, where the diameter of the circle is half of the available height. To do so, I would need to determine the total amount of real estate, where is the middle, how many pixels there are (in order to map the middle to a particular pixel), identify all of the pixels involved, figure out how to refer to the pixels, figure out what number corresponds to the colour I want etc. It would be much easier if there were an intermediary who I could ask - draw me a circle with center (x,y) and diameter d. The intermediary would be in charge of carrying out that instruction. This is what the Graphics2D object does - it encapsulates the graphics system and provides an API to us so that we can specify instructions.
2. Separation of Model and the View
- recall that we are learning about the separation of the view and the model. Recap: what is a "view"? A view is a visual representation - it must convey the state of the system to the user; it is the basis for the user's perceptions about what the system might allow them to do, as well as his/her perceptions about the consequences, if any, of their actions upon the system.
- In practical terms, a view is actually a hierarchy of interactive elements, where those interactive elements are commonly referred to as widgets.
- Work through several eg's of interfaces - identifying all of the widgets, discussing them, and building the widget hierarchy.
- The take-home point is that our view needs a root, and the JFrame class provides the services that we need (in terms of being able to be displayed, being able to add widgets to it).
- Discussed events as being dispatched depending on the user's actions (e.g., mouse presses, button activations, scroll sliding, etc)
3. The Graphics2D class
- Refer to sec 8.1.6 and lab 8.2.
- Discuss services of UniPanel.
- Develop app Draw.java (available as course eg).
Lecture 4
13/01/11 01:32
1. Recap of the System class
- it is a utility class by virtue of the absence of a constructor. It is not the presence of static methods that makes a class a utility class - remember, even non-utility classes can have static methods. In fact, a class could be defined such that it has a constructor and all of its methods are static - such a class still would not be a utility class.
-System has three publically-accessible fields - in, out, and err. The latter two are of type PrintStream. System HAS-A attribute that is a PrintStream object (it just so happens that out and err, by default, refer to the same PrintStream object, namely the one that encapsulates the console).
==> UML diagrams to represent this relationship between classes (see Ch2 for review of UML, see sec 7.1.3 for the three different inter-class relationships and the notation)
2. Overview of Input Streams (reference: case study 8.1.5)
-establishes a data conduit from a source (some place from which a data stream might be issued forth) to a receiver or "data sink" (our program)
-we read from the stream byte by byte; the stream will block until there is something to send
-the work of turning the byte stream into a character stream, this is the role of the buffer. The buffer needs to know something about the the platform's charset. This is delegated to a separate module (the reader)
-the work of delivering the character stream to us, a line at a time, is the buffer
-the charset tells us - how to interpret a particular byte? is it ascii?is it UTF-8 Eight-bit UCS Transformation Format? we then map between different character encoding schemes to Unicode
==> Key point - in constructing a Scanner object, we pass to the Scanner constructor an object that represents an InputStream. Typically, we use System.in, but the next part of lecture shows that we can use an InputStream that encapsulates the data flow from a web server.
3. Basic WWW concepts:
- http protocol is mechanism for communication between "browsers" and servers
- stateless (meaning no information saved from one exchange to the next) - can demonstrate by contrast to human conversation (which is state-based)
-there are two players - the "browser" who makes GET/POST requests, and the server who responds to them
-use FireBug to illustrate the browser issuing the GET/POST requests and the responses from the server.
-a component of the GET request is the URL
-the URL consists of http:// prefix, server specification, resource path, arguments, (and part)
e.g., in the URL http://www.cse.yorku.ca/~roumani/jba/ase/se.cgi?hrss=+.AB, the part "hrss=+.AB" is the argument list
-how do URL's get composed?
-within browser - can have http://www.cse.yorku.ca/~roumani/jba/ase/index.html
-also can do so programmatically composing name/value pairs by string concatenation (foreshadow - do we have a way to programmatically issue GET/POST request to a server)
-server-side processing unpacks the argument list and then invokes some code that generates a response.
-notice that one can manually compose the URL with name/value pairs.
-we can use services of URL class (in java.net package) to open an InputStream that corresponds to what the server will serve up (deliver in response to a request)
-in-class development of solution to Lab7.3
- it is a utility class by virtue of the absence of a constructor. It is not the presence of static methods that makes a class a utility class - remember, even non-utility classes can have static methods. In fact, a class could be defined such that it has a constructor and all of its methods are static - such a class still would not be a utility class.
-System has three publically-accessible fields - in, out, and err. The latter two are of type PrintStream. System HAS-A attribute that is a PrintStream object (it just so happens that out and err, by default, refer to the same PrintStream object, namely the one that encapsulates the console).
==> UML diagrams to represent this relationship between classes (see Ch2 for review of UML, see sec 7.1.3 for the three different inter-class relationships and the notation)
2. Overview of Input Streams (reference: case study 8.1.5)
-establishes a data conduit from a source (some place from which a data stream might be issued forth) to a receiver or "data sink" (our program)
-we read from the stream byte by byte; the stream will block until there is something to send
-the work of turning the byte stream into a character stream, this is the role of the buffer. The buffer needs to know something about the the platform's charset. This is delegated to a separate module (the reader)
-the work of delivering the character stream to us, a line at a time, is the buffer
-the charset tells us - how to interpret a particular byte? is it ascii?is it UTF-8 Eight-bit UCS Transformation Format? we then map between different character encoding schemes to Unicode
==> Key point - in constructing a Scanner object, we pass to the Scanner constructor an object that represents an InputStream. Typically, we use System.in, but the next part of lecture shows that we can use an InputStream that encapsulates the data flow from a web server.
3. Basic WWW concepts:
- http protocol is mechanism for communication between "browsers" and servers
- stateless (meaning no information saved from one exchange to the next) - can demonstrate by contrast to human conversation (which is state-based)
-there are two players - the "browser" who makes GET/POST requests, and the server who responds to them
-use FireBug to illustrate the browser issuing the GET/POST requests and the responses from the server.
-a component of the GET request is the URL
-the URL consists of http:// prefix, server specification, resource path, arguments, (and part)
e.g., in the URL http://www.cse.yorku.ca/~roumani/jba/ase/se.cgi?hrss=+.AB, the part "hrss=+.AB" is the argument list
-how do URL's get composed?
-within browser - can have http://www.cse.yorku.ca/~roumani/jba/ase/index.html
-also can do so programmatically composing name/value pairs by string concatenation (foreshadow - do we have a way to programmatically issue GET/POST request to a server)
-server-side processing unpacks the argument list and then invokes some code that generates a response.
-notice that one can manually compose the URL with name/value pairs.
-we can use services of URL class (in java.net package) to open an InputStream that corresponds to what the server will serve up (deliver in response to a request)
-in-class development of solution to Lab7.3
Lecture 3
11/01/11 01:32
1. review of the Options and Check applications
2. Further discussion of the Human Action Cycle with a focus on goals are being the motivation behind user interaction
3. Separation of the view and mode - discussion of various instances of this separation
Specific discussion of html - the view is how the browser renders it, the model can be seen as a set of elements, where those elements can be captured in a text file or alternatively, shown as a graphical structure (The html DOM Node Tree)
2. Further discussion of the Human Action Cycle with a focus on goals are being the motivation behind user interaction
3. Separation of the view and mode - discussion of various instances of this separation
Specific discussion of html - the view is how the browser renders it, the model can be seen as a set of elements, where those elements can be captured in a text file or alternatively, shown as a graphical structure (The html DOM Node Tree)
Lecture 2
06/01/11 01:32
1. comparison of the primitive data types and the wrapper classes
example to demonstrate the difference in behaviour between them
memory diagram for each example
The in-class examples (plus an additional eg) can be found in the directory containing the Lecture Examples
2. Overview of the Human Action Cycle; Introduction to the two gulfs - gulf of execution and gulf of evaluation. See Course Materials for synopsis document.
3. The basics of MVC - the three roles of the model, the view, the controller.
example to demonstrate the difference in behaviour between them
memory diagram for each example
The in-class examples (plus an additional eg) can be found in the directory containing the Lecture Examples
2. Overview of the Human Action Cycle; Introduction to the two gulfs - gulf of execution and gulf of evaluation. See Course Materials for synopsis document.
3. The basics of MVC - the three roles of the model, the view, the controller.