T SOFTWARE PROJECT

Transcription

1 T SOFTWARE PROJECT Configuration Management Personal Assignment Configuration management.doc Page 1 of 47 Saiki Tanabe

2 Saiki Tanabe 57264V Configuration management.doc Page 2 of 47 Saiki Tanabe

3 Version Description Author Date 0.1 Initial draft Stanabe Structural changes Stanabe New policies Stanabe Finalization for delivery Stanabe Directory structure updates Stanabe Ant-tool removed, experiences and metrics updated Stanabe Delivery chapter updated Stanabe Finalizing assignment: Build scripts added, metrics updated and some other minor changes Stanabe Configuration management.doc Page 3 of 47 Saiki Tanabe

4 TABLE OF CONTENTS 1 INTRODUCTION WORK ENVIRONMENT VERSION CONTROL CVS SETUP CONVENTIONS POLICY INTEGRATION CHANGE REQUEST PROCEDURE DELIVERY IMPLEMENTATION TESTING CODING CONVENTIONS CLASS MEMBERS Configuration management.doc Page 4 of 47 Saiki Tanabe

5 8.2 ATTRIBUTE NAMES AND LOCAL VARIABLES METHODS NAME IMPORTS METHODS AND VARIABLE POSITIONS IN A CLASS EXPERIENCES AND METRICS ACRONYMS AND ABBREVIATIONS REFERENCES...47 Configuration management.doc Page 5 of 47 Saiki Tanabe

6 1 INTRODUCTION This personal assignment is meant to guide project members to use basic unified ways to carry out this software project. First, all members need to use similar kind of work environment and version control, which is providing basic software configuration management. Project has selected CVS to be a version control tool, because it is free and it can easily be used with HUT servers. However in CVS there are some drawbacks and some kind of conventions has to be used to keep version control in balance. Implementation chapter just emphasizes some basic ideas to write code in this project. Also testing is briefly handled, which is also used as to guide implementation in some components. To keep code and configuration management as smooth as possible there has been handled some basic coding convention rules regarding on this project. All steps are taken into use when something is done related to that issue. Version control is carried out through out whole project from the beginning till the end. Implementation and testing idioms are used as soon as implementation starts, which is in phase Implementation 1. Those are carried out at the same time, using test driven implementation. Coding conventions are also deployed at the same time. Configuration management.doc Page 6 of 47 Saiki Tanabe

7 Configuration management.doc Page 7 of 47 Saiki Tanabe

8 2 WORK ENVIRONMENT Basically work environment consists from personal computers and CVS server. Each group member uses a PC client to connect with CVS server to get artifacts related to the project. PC clients need at least following programs and those will be supported and guidance will be provided. WinCVS, which is a front-end for using a CVS server o Documentation tools for writing documents Eclipse, a free java based IDE for implementing java o JUnit for test driven development, unit and module testing o Build scripts Configuration management.doc Page 8 of 47 Saiki Tanabe

9 Work environment is used from the beginning of the project and the usage will end when the project ends. All the members of the project will use these tools except project manager doesn t use implementation tools. Configuration management.doc Page 9 of 47 Saiki Tanabe

10 3 VERSION CONTROL 3.1 CVS CVS is used as version control system in the project. It will be used as unreserved checkout with watch feature. Unreserved checkout means that multiple users can edit files at the same time and in conflict situations merging will be done using e.g. Beyond Compare (provides very good visual merging, With watch feature users are able to see who are editing files. For more information on CVS, see [2]. [3] 3.2 SETUP Project has select WinCVS for a client program. For taken WinCVS in to use, following set ups needs to be done. Configuration management.doc Page 10 of 47 Saiki Tanabe

11 3.2.1 Basic settings 1. First, preferences needs to be set. Those can be found from the Admin menu: Admin-> Preferences. See Figure 1. Configuration management.doc Page 11 of 47 Saiki Tanabe

12 Figure 1 WinCvs Preferences select SSH authentication. Configuration management.doc Page 12 of 47 Saiki Tanabe

13 Set path where the CVSROOT can be found on the server. /m/nfs1.niksula/home1/u4/stanabe/.cvs Host address: jolly.cs.hut.fi User name: add you own user name here in Niksula CVSROOT: this will automatically generated when all the information have been entered 2. Select Settings See Figure 2. Configuration management.doc Page 13 of 47 Saiki Tanabe

14 Figure 2 SSH Options Configuration management.doc Page 14 of 47 Saiki Tanabe

15 RSA private key file (identity) needs to be checked if public-key authentication is used. That will be explained later. In case public-key authentication is not used, check box needs to be left empty. Text box example: e.g. C:\Documents and Settings\st\Application Data\SSH\identification SSH client defines a SSH command line client program, which is used to have secured connection to CVS server. Text box example: C:\Program Files\SSH Communications Security\SSH Secure Shell\ssh2.exe Public-key authentication In case public-key authentication is used, user doesn t have to type password and user name when using CVS server. First public and private key pair needs to be generated. Following guide is done with Secure Shell. If this client program is not available, guide for creating a key pair with command line in Unix is described in Settings Settings can be found from Edit->Settings->User Authentication->Keys. See Figure 3. Configuration management.doc Page 15 of 47 Saiki Tanabe

17 Figure 3 Public-authentication Settings Select Generate new Next->Next->Next Configuration management.doc Page 17 of 47 Saiki Tanabe

19 Figure 4 Key Generation Leave password fields as empty in Figure 4 After a public-private-key pair has been created, Configure needs to be selected to create identification file. Created public key has to be sent to saiki@iki.fi, for accessing CVS server with public-key authentication. NOTE Private key authentication doesn t work if the user hasn t logged into Niksula at least ones with public key authentication to his/hers home directory. 3.3 CONVENTIONS Renaming and moving of files needs special attention. In basic use CVS doesn t support these operations and those have to be done, using several operations. Renaming and moving are actually same things. Simplest way to rename a file is to delete it from the version control and then bring it back as a new file, with a new name. A constraint is that version history is lost. In addition to keep version history within a new file a version control administrator needs to be contacted. In this way renaming and moving can be done with history. Configuration management.doc Page 19 of 47 Saiki Tanabe

20 Basic directory structure will be provided through CVS as a first checkout. CVS is tagged with unique name when each delivery is made. 3.4 POLICY Everything is kept in version control For code, everything has to compile, which is kept in version control Try to make each commit as a small task o Keeps version control in consistency o Integration is easier and is done more often Checkout files as read-only. See Figure 5. It probably means that module needs to be checked out for getting everything as read only Configuration management.doc Page 20 of 47 Saiki Tanabe

21 Figure 5 Checkout read-only When files are edited those should be taken out for edition Configuration management.doc Page 21 of 47 Saiki Tanabe

22 o Enables using a watch feature o View in WinCVS looks like following. Note in the beginning of files means read only. Editing tools look like this:. See Figure 6. o Pen: Edit file (after this file is able to be edited) unreserved checkout o Pen + c: reserved checkout. Which can be used when only one person is allowed to edit a file at a time. However it is not recommended and should be used only with documentation files, not with source codes. o Rubber: Unedits file(s). Set files back to read only mode. o Pen +?: Editors selection. Shows users who are editing files Remember to commit after edition. Editing rules has to be followed! Configuration management.doc Page 22 of 47 Saiki Tanabe

24 Figure 6 Files checked out as read only Configuration management.doc Page 24 of 47 Saiki Tanabe

25 4 INTEGRATION Roadmap Tool is build from 7 different packages as Table 1 describes. Those will be implemented simultaneously and as previously was mentioned, everything has to be kept in version control and all components needs to compile. There is not any specific integration phase and integration is done all the time. Developers need to design interfaces for their own components that they are responsible of. Interfaces are published through the version control and if any changes arise by the client, a new change request is made to the component developer. Change request are very informal procedure at the beginning of the project and those can be just agreed between developers. This concerns phases Implementatio 1 and Implementatio 2. After those phases, official CR request procedure should be followed, see 4.1. However architecture design has to be followed. In case architecture design needs improvement, changes requests should be posted to chat room. There might be small gaps that source codes between components in version control don t compile, because of interfaces changes. Those changes needs to be done to the client side also by the developer who is responsible of interfaces change or it can be agreed that client side developer makes changes as soon as noted. These changes have to be notified and marked in the chat room ( Chat room saves all the messages and is considered as database for change requests. Configuration management.doc Page 25 of 47 Saiki Tanabe

26 Therefore there will not be specific integration phase and integration is done all the time. - roadmap tool is implemented in the directory structure of rmt Controller Dialogs Engine ExternalDocumentHandler GraphicLibrary GUI LayerManager Localization Configuration management.doc Page 26 of 47 Saiki Tanabe

27 Storage Table 1 Packages how, when, and by whom it will be used 4.1 CHANGE REQUEST PROCEDURE Chat room is considered as official change request database and requests will be processed in there. Comments can be given by anyone, but project manager or design architect approves the CR. Change request types: Requirement, UI and Implementation Change request states: New, Debate, Approved, Implemented New: is the initial phase (when CR is created) Debate: when comments are given Approved: when CR has been accepted and after this state it can be implemented Configuration management.doc Page 27 of 47 Saiki Tanabe

28 Implemented: when change has been done a last message in a CR should be this state Change request title format: CR: <type> <state> Create interface change request example. Post message o Name: Saiki o Subject: CR: Implementation New o Message: Class rmt.engine.ermtengine method ErmtObject CreateRMTObject(int aobjecttype) is deprecated and needs to be removed. This will be replaced with methods: public ERmtObject CreateActivity() public ERmtObject CreateEvent() public ERmtObject CreateNote() CR will be processed as Follow Up (reply) to created CR. Configuration management.doc Page 28 of 47 Saiki Tanabe

29 5 DELIVERY There is an internal build every week and it will be delivered to client too. The developers and testers tests builds. When delivery is made, RMT as a whole is labelled in the version control system. Tag format is RMT_<date>_<delivery_name>. Deliveries will be supported with release scripts, which will make packages ready. For running those Perl will be needed. Deliveries will be made according to a tag. Build script Description make.bat Cleans first all the class files and then compiles everything. run.bat Launches RoadmapTool application. make_build.bat Makes delivery zip: RoadmapTool.zip RoadmapTool.zip content RoadmapTool.jar RoadmapTool_Src.jar DefaultRoadmap.rmt Description It is the executable jar file. All the source codes. Default roadmap will be created on base of DefaultRoadmap.rmt. Configuration management.doc Page 29 of 47 Saiki Tanabe

30 Help Libs Html help documentation for RoadmapTool. Additional libraries that RoadmapTool is depended on. Official deliveries will be done in the end of each phase and person who is responsible of delivery is designated in the project meeting. Configuration management.doc Page 30 of 47 Saiki Tanabe

31 6 IMPLEMENTATION Preliminary architecture design should be done before implementation. Here it is meant a class and sequence diagram, so that developer knows what he is doing. Design and implementation is done iteratively and those go later by hand in hand. Architecture design needs to be followed to make integration and coding in control. Remember to thought client side when implementing services for other components. Make component as reusable as possible. JUnit can be used here to use test-driven implementation. That will probably make you to achieve a better design and the code will be tested at the same time and regression testing is much simpler later. Configuration management.doc Page 31 of 47 Saiki Tanabe

32 7 TESTING Unit and module testing is needed for some parts. Especially engine part of the application will be module tested. With module testing is meant for testing a public interface, which is seen by clients. Unit testing will be executed for most vital part of the system. Unit testing sees inside of a module and testing is done based on that. UI part is not tested with unit neither module testing. Those will be tested through user interface, using the actual application, RMT. In addition UI part tests code with asserts and invariants. Asserts will be placed at least for checking method attributes in public functions. Invariants checks class state. Testing will be done as part of implementation. It will support it and makes integration easier and more mature. Unit and module testing will be carried through with JUnit. Functional testing will be carried through according to official builds. Nothing is taken from the version control system. Packages, which will be and are delivered, are base for these tests. Configuration management.doc Page 32 of 47 Saiki Tanabe

33 8 CODING CONVENTIONS Coding and commenting conventions are following java style see [2]. However some exceptions occurs. 8.1 CLASS MEMBERS Class members have a pre addition, which is coming from Symbian coding conventions for C++. E.g. class MyClass { private int imyvalue; } Pre addition i is coming from instance and it helps others to review code. It differentiates immediately local and member variables. Configuration management.doc Page 33 of 47 Saiki Tanabe

34 8.2 ATTRIBUTE NAMES AND LOCAL VARIABLES Attributes naming in a method has a prefix and local variables are written in lower case letter. E.g. void Bar(int avalue) { int localvariable = avalue; } It is instantly seen that which is method attribute and which is local variable. 8.3 METHODS NAME Also other suggestion is differentiating from standard java style coding. Methods name are starting with capital letter. E.g. class MyClass { public void Foo() { } } Configuration management.doc Page 34 of 47 Saiki Tanabe

35 8.4 IMPORTS Imports are done explicitly for each class. E.g. import java.awt.borderlayout; 8.5 METHODS AND VARIABLE POSITIONS IN A CLASS. class MyClass { // constructors public MyClass() { } // Interface (public functions) public void Bar() { } // Implementation (private member functions) private void Foo() { Configuration management.doc Page 35 of 47 Saiki Tanabe

36 } // data private int imyvalue; } Explanation for this order is that first it is good to see public interface. Lowest there is the private stuff, which is not mentioned for clients who are using the class. So the visibility determines order in the class. Configuration management.doc Page 36 of 47 Saiki Tanabe

37 9 EXPERIENCES AND METRICS Version control experiences and metrics are followed through CVS with watch feature. Also there is sometimes possible to see how people are using CVS in their machines. Also questions are a base for these metrics. Coding conventions are easily followed from the code implemented by the developers. Chat room is one of the key databases for collection metrics for integration and change requests. Version control also gives possibility to follow test-driven implementation. Practise Adoptation Experience Effects Configuration management.doc Page 37 of 47 Saiki Tanabe

38 Work WinCVS Environment: All the project members have been installed and used WinCVS. There was some difficulties for set upping WinCVS especially, with public key authentication. Documentation has been improved for set upping public-key authentication. For some people there has been some difficulties for using it. There was some surprises in the end of the project. Especially when integrating a huge amount of code at the same when the usage of cvs wasn t possible due to lack of internet connection. Merging of files by CVS Configuration management.doc Page 38 of 47 Saiki Tanabe

39 wasn t so good and increased the load of integration. Work Environment: Documentation tools Tools were already adopted before the project. For agreeing RTF format took a little time. For later usage with CVS showed that rtf format was way to heavy to use, because the size of rtf was enormous compared to doc. RTF document format is used in for documenting the project. Doc format has been replaced as official file format in this project. Work Eclipse Environment: Only developers have been installed and used Eclipse. There have been some difficulties to use program. Every developer has been adopted tool Adoptation have been taken some time and it slightly affects at the moment for what has been implemented. Configuration management.doc Page 39 of 47 Saiki Tanabe

40 been adopted tool very nicely and it has been used for developing the project. However it will be taken back when using Eclipse. Some drawbacks have been noticed during the project. Eclipse was very good IDE for being free, but some e.g. key bindings slowered smooth implementation. Also IDE needs a lot of memory. Work Environment: Ant compiling tool Not taken into use yet. Tool was dropped. Usage was not necessary to this project, because compiling was quite Scripts were made to replace handling of builds. Configuration management.doc Page 40 of 47 Saiki Tanabe

41 simple and Eclipse was used as IDE. Therefore compilation was made all the time. Work Environment: Junit for test driven development Only three members have been acquainted to use this tool. It seems little bit complicated at first. All developers has been adopted to use JUnit. There have been done a separate Personal Assigment for using Junit. CVS Set up All the members have done this. CVS, just seems to be little bit slow to use. Started to use doc format. Rft files became enormous. CVS Conventions and This seems not to be Conventions and policy This will need further Configuration management.doc Page 41 of 47 Saiki Tanabe

42 Policy used by all the members of the project. are mostly used but it seems that small task are not taken into use. For some project members this has been quite difficult. Source files has been quite many times broken and the project were not been able to compile. investigation and probably guidance. Guidance has been given to developers. Make.bat, run.bat and make_build.bat made to support checking the integrity and to ease making weekly builds. Integration Integration has been All the interfaces have There are made a initially started, but not yet been build every week, implementation hasn t implemented and this which is tagged and achieved full speed is still little bit open delivered to client. yet. issue. Configuration management.doc Page 42 of 47 Saiki Tanabe

43 Integration is happening all the time. Interfaces has been implemented and agreed. CR procedure No CR has been produced yet. Chat room has been good place for those. Some UI CR s has been made. Delivery No deliveries yet. On going. There were some problems to make working jar delivery package. Zip delivery package has been made, which includes executable jar and source files. Implementation The system architect has done preliminary architecture design. There have been some difficulties for resolving conflicts, which arise when Developers has been guided to solve conflicts e.g. with Beyond compare Configuration management.doc Page 43 of 47 Saiki Tanabe

44 Architecture has been iterated, but core architecture has remained basically the same. two or more developers edit same files. differentiation tool. Testing Not done yet. On going. Test driven development has been used to implement components. Coding Conventions Initially started by the developers. Mostly used by developers, however there some drop backs on this time to time. This is probably quite difficult to achieve in such a short project where no one can force to obey these rules. This has been quite difficult to achieve, Some modification as an example has been done to showing all the members how to use coding conventions in practise. Configuration management.doc Page 44 of 47 Saiki Tanabe

45 but most of the code has been done by following coding conventions. Configuration management.doc Page 45 of 47 Saiki Tanabe

46 10 ACRONYMS AND ABBREVIATIONS Acronyms/abbreviations SSH CVS RMT CR Definition Secure Shell Concurrent Versions System Roadmapping tool Change Request Configuration management.doc Page 46 of 47 Saiki Tanabe

47 11 REFERENCES [1] Derek Robert Price, CVS--Concurrent Versions System v [WWW document]. < [2] Sun Microsystems, Code Conventions for the JavaTM Programming Language. [WWW document] [3] Fogel Karl, Open Source Development with CVS. Arizona: Coriolis Configuration management.doc Page 47 of 47 Saiki Tanabe