SHDLSTUDIO Presented by : AL SAATI Razann BARDET Marine EL AOUYED El Mehdi ESSAID Sanaa FANGAR Mohamed

Plan Introduction Legacy New Specifiation Work Organization Development approach GUI Amelioration Bug List and Test procedure Quality management Conclusion

Introduction Language used for logic circuits simulation SHDL Language : What is the SHDL language ? Language used for logic circuits simulation Simple Hardware Description Language This language is used for teaching purposes at ENSEEIHT (easier than VHDL) Created by Jean-Christophe Buisson, researcher at IRIT laboratory. An Older Software (MDLE) was developed ten years ago. (reference for the project) Project began in 2010 : 3rd development team.

Introduction module fulladder(a,b,c:s,r) s=a*/b*/c+/a*b*/c+/a*/b*c+a*b*c; r = a*b + a*c + b*c; end module

Legacy Software: Documents: Maintenance Manual not provided. SHDLStudio Documents: Report SoftwareDevelopmentPlan SoftwareQualityRequirement SoftwareRequirements SoftwareValidationRequirement Maintenance Manual not provided.

Work Organization and environment Java - Netbeans 6.9.1 Environement : Origo - Subversion ENSEEIHT – Room A-204

Project Management Client Meeting: Change control Board Reviews Supervisor Meeting: Progression of the project Software documents Software Quality approach Team Meeting: Work Organization Client and Supervisor requirements. Project status Client Meeting Team Meeting Supervisor Meeting Daily work : everyday from 10:00 am to 6:00 pm room A-204 (basement Bat A.)

Development approach GUI modifications and correction of bugs: incremental cycle

Development approach virtual objects:

Risks and preventive actions Requirements Volatility Frequent review with the client Frequent team meeting Technology unknown New task : appropriate code Make prototypes

Planning

Client Requirements Correction of bugs Virtual Objects (Lift, Oscillator, 7-segment Display) Amelioration GUI (Design, Chronogram) Document (Maintenance Document)

BUGS Check functionalities Establishment of a list Resolution of them We started to check functionalities when we received the latest version of the software. With results of theses checks we establish a bug list (formalized in a document for the bug part) in a shared file. Along the project we tried to solve the most important whose multi-view exception (which allow the user to open several modules) Resolution of them

Virtual Object Electronic system, whose behaviour is simulated by the software 3 required objects : Lift Seven Segment Display Oscillator

Lift Simulation Code SHDL: new Module(a,b:c,d) lift(a,b:c,d); end module Design

7-Segment Display Design Code SHDL: new Module(a[7..0]) afficheur7seg(a[7..0]); end module Simulation

Oscillator Design Code SHDL: new Module(a:b) oscillator(a,20:b); end module Design frequency Simulation

GUI Amelioration : Simulation and Chronogram Modification of inputs values Modification of signal value during the simulation Modification of the Chronogram display Displayed Signals in Chronogram : not yet implemented

Design amelioration: Comparison GUI Modifications:  Design amelioration: Comparison

Design amelioration: The magnetic grid GUI Modifications:  Design amelioration: The magnetic grid One step (s) Operator location One step is a multiplier of this distance (h) S=h x 4

GUI Modifications: Design ameliorations Hidden input connection points Inputs operator labels Different colours for input and output labels The radius of points had changed Different lines depending on the arity

Test procedure General check at the beginning Integration test for virtual object (use in edition and behavior in simulation) Functional tests Tutorials As I said we made a general test of functionalities to see what was already implemented in the software. For each virtual objects we made integration test. We tested the object itself, the use in source view, design view and the behaviour in simulation At the end with the software requirement documents we test each requirements written in the SRD. The results are met in a table. This way, the following group will have a structured basis. To finish we make a global test, by doing the tutorials of architecture module at ENSEEIHT.

Test Results Virtual object:      lift : outputs problem      7 seg display ok      oscillator : frequency problem Functional tests:      53% work well      37% not implemented yet      9% bugged Tutorial:      ok : fulladder ...      nok : flipflop+oscillator .. The virtual object works more or less The functional test are globally ok but there is a lot of requirements not implemented Some bugs remain Concerning the N7 tutorials, the first module is ok but the rest doesn't work.

Coding and documenting rules The source code must obey these rules: - R1 : Every class must be commented. - R2 : For a package, each class contains maximum 1000 lines in average. - R3 : Each new function contains maximum 30 lines. - R4 : Average of cyclomatic complexity < 7. - R5 : The document's template should be respected. - R6 : The reference should be indicated with the number of pages.

Metrics results (Simple code metrics) Packages Metrics Conversion Actions Simulation Cyclomatic complexity average 5.27 1.27 3.12 Total LOC 1616 1054 4586 Total Classes 2 12 25 Average 808 87,8 183,44 Total Methods 35 69 193

Project Future Delivrables : Software Requirement document. Development plan document. Validation plan document. Quality insurance plan document. Source code An executable of the software. Maintenance document and User guide Configuration management plan

Technology unknown : Netbeans RPC Conclusion constraints Short Time : 8 weeks Quality supervisor : Documents needed Technology unknown : Netbeans RPC Client’s needs : Source Code

Demonstration

Thank you for your attention