The second paper I will ask you to read concerns requirements analysis and specification:
Jackson, M. 1995. The world and the machine. In Proceedings of the 17th international Conference on Software Engineering (Seattle, Washington, United States, April 24 - 28, 1995). ICSE '95. ACM, New York, NY, 283-292. DOI= http://doi.acm.org/10.1145/225014.225041
This is among the most lucid accounts I know of what it means to write a specification. The writing is light-hearted (the paragraph about steering mechanisms for cars busts me up laughing), but it's a very serious and deep consideration of the topic ... it's worth reading more than once, and thinking carefully about.
The paper accompanied an invited (keynote) talk at the International Conference on Software Engineering. Two years later, Jackson and Zave published a journal paper which encompasses some of the same material. If you like this paper, you might (at your option) follow on with:
Zave, P. and Jackson, M. 1997. Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Methodol. 6, 1 (Jan. 1997), 1-30. DOI= http://doi.acm.org/10.1145/237432.237434
Wednesday, October 29, 2008
Tuesday, October 21, 2008
Some test data, but ...
Amy exported some XML from a City of Eugene geodatabase for me, and I've put it in an accessible place, but I'm not sure how useful it will be. It looks like the individual layer files are basically empty of actual shape data. The full XML dump of the database is quite large (53M), but I'm not sure if it contains data that corresponds to layer data in the campus map. If you want to give it a try, it's at
/home/faculty/michal/public_html/08F-GIS-Eugene
on the Sun (ix) file system, or
http://www.cs.uoregon.edu/~michal/08F-GIS-Eugene
through the web server.
The .shx files are in a native ESRI data format, and the .dbf files are some kind of native database file ... the Unix "file" command claims they are in DBase 3 data file format, which is possible. The "file" command claims the .mdb file is a Microsoft Access database, but that seems unlikely. If there is data useful for testing, it is likely to be in the file XMLExport_GeoDataBase.xml . Warning, that's 53 megabytes of XML text with really long lines. Whether it has anything usable or not, I really can't tell ... trying to look through it with Emacs didn't get me very far, and it crashed Firefox!
We're hoping for real OSB data at the end of the week.
/home/faculty/michal/public_html/08F-GIS-Eugene
on the Sun (ix) file system, or
http://www.cs.uoregon.edu/~michal/08F-GIS-Eugene
through the web server.
The .shx files are in a native ESRI data format, and the .dbf files are some kind of native database file ... the Unix "file" command claims they are in DBase 3 data file format, which is possible. The "file" command claims the .mdb file is a Microsoft Access database, but that seems unlikely. If there is data useful for testing, it is likely to be in the file XMLExport_GeoDataBase.xml . Warning, that's 53 megabytes of XML text with really long lines. Whether it has anything usable or not, I really can't tell ... trying to look through it with Emacs didn't get me very far, and it crashed Firefox!
We're hoping for real OSB data at the end of the week.
Friday, October 17, 2008
Why Keith's parser doesn't produce an XML file
A few people have been confused about how Keith Albin's stylesheet parser fits with the rest of the system. In particular, there is a "Main" program in the parser directory, but that "Main" program is just a test harness to make sure the parser can accept the grammar of the style sheet. Unlike the older stylesheet parser (used by the Red and Blue teams), Keith's stylesheet parser does not produce an intermediate XML file representation of the style sheet.
So what does it do? If you call it from that Main class, it does basically nothing ... it builds some internal data structures and then throws them away. But take a look at StyleSheetReader.java in the actionscript directory --- this is where the parser is really called. It builds those data structures in the readStyles method, and then uses the data structures in the applyStyles method.
I don't know this code inside-out, but I think the basic logic goes something like this: We read the style sheet and create some internal tables with (keyword, value) pairs (which may actually be triples ... there is something called a "modifier" and I'm not certain what that is). Then we read all the map "shapes" from an XML file. Then, for each of those shapes, applyStyles looks in the tables and figures out what attributes should apply, and sticks those attributes into the shape object. Then we generate code (actionscript or a data structure for the Java display engine, as the case may be) using the shape information and all its style attributes.
So what does it do? If you call it from that Main class, it does basically nothing ... it builds some internal data structures and then throws them away. But take a look at StyleSheetReader.java in the actionscript directory --- this is where the parser is really called. It builds those data structures in the readStyles method, and then uses the data structures in the applyStyles method.
I don't know this code inside-out, but I think the basic logic goes something like this: We read the style sheet and create some internal tables with (keyword, value) pairs (which may actually be triples ... there is something called a "modifier" and I'm not certain what that is). Then we read all the map "shapes" from an XML file. Then, for each of those shapes, applyStyles looks in the tables and figures out what attributes should apply, and sticks those attributes into the shape object. Then we generate code (actionscript or a data structure for the Java display engine, as the case may be) using the shape information and all its style attributes.
OSB data new ETA - next week
I got word from Amy that there were some problems getting the OSB data into the geographic database. The problems have been worked out, but the new projected time to get the data is next week. That's awfully late in the (first half) project, and I worry that you won't have time to deal with whatever surprises turn up when you're working with a new data set (and I can almost guarantee there will be some surprises, though I don't know what they will be).
On the positive side, this is a realistic experience ... dealing with some external dependence that was not resolved as planned happens all the time.
So how do we cope with it? Here are my thoughts:
On the positive side, this is a realistic experience ... dealing with some external dependence that was not resolved as planned happens all the time.
So how do we cope with it? Here are my thoughts:
- It's worth at least taking a shot at handling the OSB data when we get it ... but I won't be surprised if the result of that is identifying some problems rather than solving them. Identifying problems is progress.
- I've asked Amy if we can get some different GIS data, possibly from downtown Eugene, so that we can have some kind of test of the ways you are generalizing the input handling.
- If all we can do is test the generalized input processing on the existing input data ... it's not what I hoped for by the midterm, but it's better than nothing.
Monday, October 13, 2008
Recommended article on checklists
I highly recommend the New Yorker article "The Checklist" by Atul Gawande. (I considered requiring it, but decided for this term just to recommend it.)
Why would I ask you to read a paper about use of checklists by doctors and nurses in hospitals? Because the basic principles here (and even the practice of using checklists) apply also to software development. Creative, problem-solving tasks take a lot of our mental energy. Organizing the routine work and having well-defined steps that we follow in a set order helps us to avoid simple mental slips, and actually help us focus better on the not-so-routine aspects of work. Even so, professionals often chafe at checklists and other ways of organizing their routines.
Returning to my mantra that everything in software development is design: The problem being addressed here is that people are actually very bad at minding a lot of details. In fact, when we're "on autopilot" we tend not to even remember what parts of our routine we have and have not completed. It's both a strength and a limitation of the way our minds work, and we have to design our work methods accordingly. Making some things even more routine, with defined methods and even checklists, helps us make sure we're doing the routine stuff right, and makes sure at least a little attention passes over each of the things we ought to be paying attention to. Supporting the routinization of those parts of the work relieves some distraction from the hard, creative parts we want and need to focus on.
A common use of checklists is in code and design reviews. They can serve as a feedback mechanism, across as well as within projects: If we keep good records of problems that are found in a project (bugs, poorly defined requirements, whatever), we can mine those records to identify the points at which they might have been prevented or detected earlier and more cheaply. We put those on checklists, and work through the checklists at the appropriate points in future projects. These can be simple code organization rules like "Keep configuration constants together in a separate source file" or "use only relative file paths except in a single top-level configuration file". They can also apply in requirements elicitation, specification, and early design stages. For example, a good routine for checking that a requirement is well-defined is to require one or more test cases to be defined as part of the requirement.
Why would I ask you to read a paper about use of checklists by doctors and nurses in hospitals? Because the basic principles here (and even the practice of using checklists) apply also to software development. Creative, problem-solving tasks take a lot of our mental energy. Organizing the routine work and having well-defined steps that we follow in a set order helps us to avoid simple mental slips, and actually help us focus better on the not-so-routine aspects of work. Even so, professionals often chafe at checklists and other ways of organizing their routines.
Returning to my mantra that everything in software development is design: The problem being addressed here is that people are actually very bad at minding a lot of details. In fact, when we're "on autopilot" we tend not to even remember what parts of our routine we have and have not completed. It's both a strength and a limitation of the way our minds work, and we have to design our work methods accordingly. Making some things even more routine, with defined methods and even checklists, helps us make sure we're doing the routine stuff right, and makes sure at least a little attention passes over each of the things we ought to be paying attention to. Supporting the routinization of those parts of the work relieves some distraction from the hard, creative parts we want and need to focus on.
A common use of checklists is in code and design reviews. They can serve as a feedback mechanism, across as well as within projects: If we keep good records of problems that are found in a project (bugs, poorly defined requirements, whatever), we can mine those records to identify the points at which they might have been prevented or detected earlier and more cheaply. We put those on checklists, and work through the checklists at the appropriate points in future projects. These can be simple code organization rules like "Keep configuration constants together in a separate source file" or "use only relative file paths except in a single top-level configuration file". They can also apply in requirements elicitation, specification, and early design stages. For example, a good routine for checking that a requirement is well-defined is to require one or more test cases to be defined as part of the requirement.
Tuesday, October 7, 2008
Reading: Herbsleb & Grinter
Please read this week:
Herbsleb, J. D. and Grinter, R. E. 1999. Splitting the organization and integrating the code: Conway's law revisited. In Proceedings of the 21st international Conference on Software Engineering (Los Angeles, California, United States, May 16 - 22, 1999). International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA, 85-95.
There are a couple reasons for reading this paper. For one, I want you to understand Conway's law (the relation between the structure of a software system and the structure of the organization that creates it), and in general the way technical issues in software design are tangled up with social and management issues. In addition, as software development is increasingly global, the cultural and communication issues discussed in this paper will become more and more important.
You should be able to download the paper from the ACM server, using the link above, when you are connected through the University. Let me know if you have problems with that.
Herbsleb, J. D. and Grinter, R. E. 1999. Splitting the organization and integrating the code: Conway's law revisited. In Proceedings of the 21st international Conference on Software Engineering (Los Angeles, California, United States, May 16 - 22, 1999). International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA, 85-95.
There are a couple reasons for reading this paper. For one, I want you to understand Conway's law (the relation between the structure of a software system and the structure of the organization that creates it), and in general the way technical issues in software design are tangled up with social and management issues. In addition, as software development is increasingly global, the cultural and communication issues discussed in this paper will become more and more important.
You should be able to download the paper from the ACM server, using the link above, when you are connected through the University. Let me know if you have problems with that.
What are my exams like?
Daniel asked the question, but maybe others would also like to know ...
My midterm from last fall is at http://www.cs.uoregon.edu/classes/07F/cis422/midterm.html
Here's the final exam from that term (which was a sit-down exam, while the midterm was a take-home exam):
Final exam, CIS 422, Fall 2007
You may write (legibly) by hand, or you may use your laptop computer and turn in a plain text file by USB. Text files should be named JohnDoe.txt (but use your own name), and your name should also the first thing I see inside the file. I need your name if you use paper, too.
1. We sometimes replace recall tasks by recognition tasks to reduce memory load. Considering this goal, very briefly describe why each of the following is or is not a good application of replacing a recall task with a recognition task in an online shopping application that is used only occasionally (say, once a month) by each user.
2a) Instead of typing a date, pop a calendar chooser.
2b) Instead of typing the user's state (e.g., OR for Oregon) in the delivery address, pop a menu of states.
2c) Instead of choosing a brown sweater by clicking on its picture (in a row showing brown, blue, and red sweaters), pop a menu with color choices.
2d) Instead of typing "sleeveless turtleneck" in a search interface, check the "sleeveless" and "turtleneck" boxes in an array of style choices.
2. "Visibility" in a software development process means being able to assess how we are doing at each point along the way. The general concept of visibility applies both to schedule (are we on schedule? how far behind or ahead?) and to qualities like maintainability, usability, and dependability.
Visibility is a major challenge in project planning. Briefly describe:
• A visibility issue faced by your project team (whether or not you successfully addressed it)
• One or two actions your team took to address that challenge, AND/OR
• One or two actions you wish your team had taken to address that challenge
To the extent possible, describe how the actions your team took or might have taken relate to processes we have discussed in class.
My midterm from last fall is at http://www.cs.uoregon.edu/classes/07F/cis422/midterm.html
Here's the final exam from that term (which was a sit-down exam, while the midterm was a take-home exam):
Final exam, CIS 422, Fall 2007
You may write (legibly) by hand, or you may use your laptop computer and turn in a plain text file by USB. Text files should be named JohnDoe.txt (but use your own name), and your name should also the first thing I see inside the file. I need your name if you use paper, too.
1. We sometimes replace recall tasks by recognition tasks to reduce memory load. Considering this goal, very briefly describe why each of the following is or is not a good application of replacing a recall task with a recognition task in an online shopping application that is used only occasionally (say, once a month) by each user.
2a) Instead of typing a date, pop a calendar chooser.
2b) Instead of typing the user's state (e.g., OR for Oregon) in the delivery address, pop a menu of states.
2c) Instead of choosing a brown sweater by clicking on its picture (in a row showing brown, blue, and red sweaters), pop a menu with color choices.
2d) Instead of typing "sleeveless turtleneck" in a search interface, check the "sleeveless" and "turtleneck" boxes in an array of style choices.
2. "Visibility" in a software development process means being able to assess how we are doing at each point along the way. The general concept of visibility applies both to schedule (are we on schedule? how far behind or ahead?) and to qualities like maintainability, usability, and dependability.
Visibility is a major challenge in project planning. Briefly describe:
• A visibility issue faced by your project team (whether or not you successfully addressed it)
• One or two actions your team took to address that challenge, AND/OR
• One or two actions you wish your team had taken to address that challenge
To the extent possible, describe how the actions your team took or might have taken relate to processes we have discussed in class.
Saturday, October 4, 2008
Field trip?
Bob Disher, technology specialist at Oregon School for the Blind, asked if we would like to visit as a group. I think that could be an excellent thing to do, but I have a lot of questions about how and when to do so, and of course I will need to know how interested CIS 422/522 students are in such a field trip. And of course there are the practical issues of transportation and paying for it (e.g., if we rent one or more vans for a field trip).
Regarding scheduling, I can think of three plausible times to go:
Regarding scheduling, I can think of three plausible times to go:
- As soon as possible
- Mid-term, when we have initial prototypes to show off, so we can solicit feedback and ideas
- At or near the end of the term, when we have more to show off (but feedback and ideas are more for future developers)
Quantitative and ordinal attributes
In discussion of what the OSB map should include, two quantitative attributes were mentioned:
In tactile maps, there are symbols indicating incline.
The current soundscape map system has no provision for such attributes, nor is there a way to describe them in the style sheet language. My first thought is that we probably need ways of modulating existing sound cues (e.g., altering pitch) in a way that maintains the meaning of the cue ("this is a sidewalk") and conveys additional information. It might be ok to discretize quantitative attributes, for example representing incline only by one of the discrete categories "steep down", "down", "level", "up", "steep up".
We don't absolutely have to come up with ways of handling such attributes this term, but it's on the "wish list" for things that you may consider if it fits in your development schedule. As I said in class Wednesday, your project should be structured as a sequence of increments, so that the question is not when you are done but rather what you get done. (This is a very common approach to system design and project planning when deadlines are inflexible.)
- Incline (e.g., slope of a path or lawn)
- Width of a sidewalk
In tactile maps, there are symbols indicating incline.
The current soundscape map system has no provision for such attributes, nor is there a way to describe them in the style sheet language. My first thought is that we probably need ways of modulating existing sound cues (e.g., altering pitch) in a way that maintains the meaning of the cue ("this is a sidewalk") and conveys additional information. It might be ok to discretize quantitative attributes, for example representing incline only by one of the discrete categories "steep down", "down", "level", "up", "steep up".
We don't absolutely have to come up with ways of handling such attributes this term, but it's on the "wish list" for things that you may consider if it fits in your development schedule. As I said in class Wednesday, your project should be structured as a sequence of increments, so that the question is not when you are done but rather what you get done. (This is a very common approach to system design and project planning when deadlines are inflexible.)
Notes from OSB visit, 3 Oct 2008
I accompanied Prof. Amy Lobben to Oregon School for the Blind (OSB) in Salem Friday, along with a geography student who is gathering raw data for the OSB map using a GPS unit. We met primarily with Bob Disher, Technology Specialist at OSB. Here are a few notes on that visit and what I learned.
The OSB campus is smaller than University of Oregon campus, and the map will be quite a bit simpler, with fewer layers (classes of object). Objects to be included in the map include at least the following:
In discussions about longer term trajectory for the project, Bob asked about producing maps from data that is not in a geographic information system, e.g., from a plan of a building that is in terms of relative positions but not referenced to lattitude and longitude. This seems conceptually straightforward (it really shouldn't matter to us whether the coordinate system is degrees or feet, or where the origin is), but it does suggest that our earlier discussion about not tying our input data format too tightly to a fixed GIS data source is in fact relevant.
In a separate discussion with Amy, on the way to Salem, I asked whether we should be considering GIS systems other than those of ESRI (the company that makes ArcGIS). Amy said that, while GIS systems sometimes do provide some limited interoperability by reading other data formats, in practice ESRI dominates the field so strongly that supporting ESRI formats is enough for handing pretty much all GIS data we are likely to encounter.
The meeting was quite loosely structured, and in addition to needs for the current project, we discussed the way the project has evolved and the way it involves students. Bob Disher extended an invitation for us to visit OSB as a group. I'll write a separate post to discuss that possibility.
The OSB campus is smaller than University of Oregon campus, and the map will be quite a bit simpler, with fewer layers (classes of object). Objects to be included in the map include at least the following:
- Buildings
- Some rooms within buildings
- Auditorium, media center, main office, infirmary, dining hall
- Some main doors to outside
- Parking lot
- Sidewalks
- Campfire pit (a meeting place)
- Sensory garden (as a single object)
- Major features of the immediately surrounding area
- Cross streets
- Intersections
In discussions about longer term trajectory for the project, Bob asked about producing maps from data that is not in a geographic information system, e.g., from a plan of a building that is in terms of relative positions but not referenced to lattitude and longitude. This seems conceptually straightforward (it really shouldn't matter to us whether the coordinate system is degrees or feet, or where the origin is), but it does suggest that our earlier discussion about not tying our input data format too tightly to a fixed GIS data source is in fact relevant.
In a separate discussion with Amy, on the way to Salem, I asked whether we should be considering GIS systems other than those of ESRI (the company that makes ArcGIS). Amy said that, while GIS systems sometimes do provide some limited interoperability by reading other data formats, in practice ESRI dominates the field so strongly that supporting ESRI formats is enough for handing pretty much all GIS data we are likely to encounter.
The meeting was quite loosely structured, and in addition to needs for the current project, we discussed the way the project has evolved and the way it involves students. Bob Disher extended an invitation for us to visit OSB as a group. I'll write a separate post to discuss that possibility.
Subscribe to:
Posts (Atom)