250 likes | 370 Views
Software Engineering 3156. 6-Nov-01 #19: Maintenance and Swing Phil Gross. Administrativia. Prototype status Modify schedule again, give a few more days? Perl Tomorrow 6-8pm No Wednesday class Guest speaker on Thurs. FYI. Being a maintenance programmer.
E N D
Software Engineering 3156 6-Nov-01 #19: Maintenance and Swing Phil Gross
Administrativia • Prototype status • Modify schedule again, give a few more days? • Perl Tomorrow 6-8pm • No Wednesday class • Guest speaker on Thurs 2
FYI 3
Being a maintenance programmer • Lots of maintenance: 67% on average of total time in lifecycle • Most difficult: incorporate everything else 4
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? 5
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 6
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 7
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” 8
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? 9
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 10
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 11
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 12
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 13
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 14
Reverse engineering (II) • No source code, you say? • Decompile • Oh, BTW, lots of luck • Java slight exception here… • JAD is supposedly really good • Introspection side effect 15
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! 16
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? 17
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 18
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 19
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 20
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 21
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 22
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!) 23
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 24
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 25