COMS W3156: Software Engineering, Fall 2001

1. COMS W3156:Software Engineering, Fall 2001 Lecture #18: Maintenance, Swing/AWT Janak J Parekh janak@cs.columbia.edu

2. Administrativia • My laptop died  • One downside of being a CS major… • Prototype status • Your status? • Modify schedule again, give a few more days? • Next Monday: interesting talk on XML…

3. Et tu, XML? The downfall of the relational empire Philip Wadler, Avaya Labs Monday November 12, 2001 11am-12:15pm Interschool Lab, 715 CEPSR Three decades past, the relational empire conquered the hierarchical hegemony. Today, an upstart challenges the relational empire's dominance, threatening the return of hierarchy. XML is Lisp's bastard nephew, with uglier syntax and no semantics. Yet XML is poised to enable the creation of a web of data that dwarfs anything since the Library at Alexandria. This talk examines the design of XQuery, the W3C standard query language for XML.

4. Next class • Start discussion on languages • Mini-introduction to C • Smooth your transition to future semesters • Collaborative environments • Suhit’s research

5. Today’s class • Finish up tools from last time • Maintenance • Swing/AWT • More on this in recitation next week…

6. Regular Expressions: A bit more • Can use [] operators to designate a choice • ab[xyz]c matches: • abxc, abyc, abzc only • ab[0-9]c matches • ab0c, ab1c, …, ab9c • ab[a-zA-Z1-4]c matches • abac, abZc, ab3c • not ab5c • Can also combine wildcards, such as ab[a-z]*c • abzzaaccbbddeeffggc

7. Regular Expressions: The Dot • ‘.’ matches any character (“.?” like DOS wildcard “?”) • ab.c matches abbc, abqc, ab6c, ab(c, ab^c • Common: .* • ab.*c matches any string beginning with ab and ending in c • \. matches a literal period

8. Regular Expressions: Using • bash, egrep have decent regular expression support • gnu.regexp has a sample applet associated with it, you can try it out • We’ll give sample code, recitation will also cover • It all comes from Perl • Perl = two languages in one • Amazing string processing • Practical Extraction and Report Language • Pathologically Eclectic Rubbish Lister

9. Make • Convenient build tool • http://www.gnu.org/manual/make-3.79.1/html_node/make_toc.html • Given a Makefile, automatically build code • Automatically figures out which code has to be rebuilt • Java supports most of this, so you don’t see it as often • Until OS, that is

10. Makefiles • Specify rules for building • Target(s): prerequisites command1 command2 … • Target is filename, usually • Prerequisite is files/rules on which this has a dependency • Commands: what to do • Must use tab before command lines: it will break otherwise

11. Make Example • For C, myprogram: myprogram.o gcc –o myprogram myprogram.o • Automatically knows how to generate “.o” file

12. Make Example (II) • For Java: myprogram.class: myprogram.java javac myprogram.java • Why is this useful? • Well, you can run javac *.java • But if you’re not in directory with top-level modules, Java won’t recompile everything

13. Make features • Knows how to compile C/C++ programs, in particular • Keeps track of timestamps: if source is newer, recompile; otherwise ignore • Can do shell-like things, including variable expansion

14. Other build tools • Autoconf/configure scripts • Ant • “Make for Java” • http://jakarta.apache.org/ant/ • Don’t need to use these: Java does most of the work for you • But you’re welcome to

15. Maintenance • Schach is a maintenance engineer • Why is it necessary? • Corrective maintenance: Correct faults (specification, design, coding, documentation, etc.) • Perfective maintenance: Change code to improve effectiveness • Adaptive maintenance: Make changes to product to react to environmental changes • Which do you think is most frequent?

16. FYI

17. Being a maintenance programmer • Lots of maintenance: 67% on average of total time in lifecycle • Most difficult: incorporate everything else

18. Corrective maintenance • Need to debug if fault report is good • Deal with regression faults • Poor documentation • Testing, including regression testing • Need to document changes • But what about adaptive and perfective maintenance?

19. Even more work… • Often, you need new functionality implemented • Must go through requirements, specification, …, integration again • Or change existing ones • Again, lack of documentation • Conclusion: you need a good programmer

20. And in return… • No thanks: if users were happy, they wouldn’t need maintenance • User’s problems frequently caused by original developer, but maintainer blamed • Original code might be badly written • Not a “glamorous job”: drudge work • “After-sales service” • Needs management help

21. Mini-case study • Temperate Fruit Committee • “We need only 7 fruits” • Maintainance • “Oh, we actually need 8” • Fortunately, hooks were in there • Time passes… • “We now need 26… you went from 7 to 8, so it must be trivial”

22. Case study lessons • Problem with product: no provision for expansion • Original developer’s fault: “obey” chairman • Original developer probably thought it was a success • Client doesn’t understand that maintenance is hard • Previous perfective maintenance succeeded, right? • Software development should keep an eye out for maintenance • Why were 7 hardcoded? Why not arbitrary numbers?

23. Managing maintenance (I) • Fault reports • Need to establish a standardized fault report • Both user and maintainer update it • Circulate to other users: “known problems” • Common: usually gather up faults • Authorizing changes • Need to have separate SQA group test it against baseline code • Schach: “must, must, must” be independent

24. Managing maintenance (II) • Ensuring maintainability • Maintenance is not a one-time effort! • Plan for maintenance from the beginning • Documentation • Variable naming, etc • Repeated maintenance • Moving target problem • As long as the client has money… • No easy solution

25. Object-oriented maintenance • Not really easier • In fact, can make maintenance harder • Inheritance, polymorphism, etc. can make understanding the code a more subtle effort • Use CASE tools to help • And time, of course

26. Maintenance skills vs. development skills • Ability to determine failures, etc. not just for maintenance: used throughout integration and testing • Standard lifecycle skills (Requirements, Design, etc.) needed here as well • Conclusion: skills not particularly different • Except that a maintenance programmer must be skilled in all of them

27. Reverse engineering (I) • You don’t want to, but sometimes have to • Poor documentation • (gasp!) No source code • CASE tools help with the first • Reconstruct just design, or specifications? • Usually the former, latter very hard • Restructuring: not changing functionality • Reformatting source code

28. Reverse engineering (II) • No source code, you say? • Decompile • Oh, BTW, lots of luck • Java slight exception here… • JAD is supposedly really good

29. Challenges • Did I mention enough already? • Classical SE is development-then-maintenance • Schach would like this changed so that one thinks of maintenance from day 1 • Unrealistic • Requirements change frequently • Faults often have to be fixed • Development from scratch now becoming rare • Often, maintain before delivery!

30. Rapid review of AWT/Swing • Swing: set of user interface components built on AWT • AWT questions/review • Themeable, very flexible • Event model • Swing’s model-view-controller mechanism • So, what tools will you need for the project?

31. Layout management • Need to lay out various components • Might use IDE for this, though I don’t • BorderLayout, GridLayout, CardLayout, FlowLayout, GridBagLayout • Last one pain to do by hand • Use JPanels to embed one in another • setPreferredSize() • Tip: draw out on paper first

32. Images (I) • Toolkit.getDefaultToolkit().loadImage(…) • Create a MediaTracker to wait for image to load • Caching images: Java or you? • Drawing images: g.drawImage(…) • Override paint method in the class

33. Images (II) • Image transparency • Needed for object-on-tile • Use Photoshop or even the GIMP to edit images • We linked to a set on the webboard • May release our modifications/subset • Consider laying out tiles in a GridLayout

34. Images (III) • Alternative image construct: ImageIcon • Can embed in a JLabel • Useful for buttons and other places where you don’t have access to Graphics context • More awkward for actual game board

35. JTables • Capable of showing complex data constructs fairly easily • Set up a data model behind the table • Extend AbstractTableModel • Specify the number of rows and columns • Specify what data is in each cell • Let the JTable do the rest • JLists are similar: AbstractListModel • Can use Default{Table,List}Model: less useful

36. Actions • JButton • addActionListener(new ActionListener()…) • Keyboard • addKeyListener(new KeyAdapter()…) • KeyEvent lets you check for most any key plus modifiers • Right-click • addMouseListener(new MouseAdapter()…) • Uses button masks (1.4 supports wheel!)

37. Miscellany • JMenu/JMenuBar for menus • JPopupMenu – the name implies it all • repaint(), revalidate() • JScrollPane to support scrolling of large areas • Grid, perhaps?  • Jsp.getViewport().setViewPosition(…) to force the scrollpane around • Ideally, have it “follow” the player

38. What does this mean for you? • Regexps: Important for AI people, to be covered a bit in recitation next week • Maintenance: you’re mostly off the hook for this one, excepting between base and full implementation • AWT/Swing: Client people will need this