software engineering 3156 6-nov-01 #19: maintenance and swing phil gross

Software Engineering 3156

6-Nov-01

#19: Maintenance and Swing

Phil Gross

2

Administrativia

Prototype status Modify schedule again, give a few more days? Perl Tomorrow 6-8pm No Wednesday class

– Guest speaker on Thurs

3

FYI

4

Being a maintenance programmer

Lots of maintenance: 67% on average of total time in lifecycle

Most difficult: incorporate everything else

5

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?

6

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

7

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

8

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”

9

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?

10

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

11

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

12

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

13

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

14

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

15

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

16

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!

17

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?

18

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

19

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

20

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

21

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

22

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

23

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!)

24

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

25

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