OHTO -99 SOFTWARE ENGINEERING LECTURE 7 Today: - Design principles: - maintainability & localisation - Testing & testing plan

OHTO -99 DESIGN PRINCIPLES We will talk generally about good software qualities later in the course. You will get in close contact with maintainability during assignments 2&3, that is why we can take a little peek to it now. What you will be implementing is, in effect, a part of a user interface of some software. To help you to produce maintainable software, we will go through some basic principles.

OHTO -99 DESIGN: PARAMETERIZE! Instead of hard-coding constants (texts and numerals) into your program, put them into a place where they can be retrieved (a local file, a.html file in the web, …) Good examples: protocol definition files, simulation images,… Bad examples: you can find constant texts in e.g. DiscoSimApplet.java (which is at least partly automatically generated, I believe :). If you have strings in the program, the ”least bad thing” is to put them in the same place.

OHTO -99 WHAT IS GUI MAINTENANCE? Graphical layout may change, sometimes this means programming, sometimes not. Functionalities may change (ok, usually this means programming…) Graphical items may change (logos, diagrams,…) The messages may change – if you are writing software which needs to be internationalised/localised, this is bound to happen – a few words about this in the next slide.

OHTO -99 LOCALISATION - ASPECTS Approriateness – culture, organisation, environment, … Linguistic issues Foreign text issues Cultural issues Process and organisational issues We will have a look at

OHTO -99 TESTING - GENERAL For the general part of this issue, we will watch a video by R. Pressman

OHTO -99 TESTING PLAN / 1 Usual testing procedure for software: unit/class testing – do the units/classes work? -> integration testing – do they work together? -> validation testing – do they work according to requirement specification? -> system testing – do they work in the real environment?

OHTO -99 TESTING PLAN / 2 So, put into your plan at least: 1. How are you going to test the individual changes to classes if all 2. How are the tests going to be performed (”I will run the applet and try out my changes” is not good enough!) In particular, what operation sequences are going to be performed. 3. What is the expected outcome of each test