1. VAR3 3.0 Platform and Project Orientation Analysis

2. Platform Comparison GNU Linux  Very robust OS that has it vendor (Unix) and open source version (Linux)  The drivers for hardware is generally develped by third party foundations and it’s open source.  There is a community of developers that use mail lists, wikis, and forums to share knowledge. Windows NT/XP  Very robust OS, the most used in the world.  The drivers for hardware is developed by the vendor of the hardware and usually gives technical support. The driver comes with the product.  There is too a community of product’s users that share knowledge.

3. Development Paradigms There are four main development paradigms  Functional: everything is a function  Logical: it depends on clauses and statements  Imperative: it has a linear execution of instructions  Object Orientation: the functions and attributes are encapsulated in objects, this it’s easier to perform abstraction

4. Paradigms comparison Imperative  C, Cobol, etc…  Its execution is quicker  The hardware integration is easier  It’s more flexible in memory management  Difficult maintenance Object Oriented  Small talk, C#, C++, Java  Can hide information to modules that don’t need it.  Allows abstraction of conceptual modules directly.

5. …and for VAR3 ?? Imperative paradigm  The imperative makes the abstraction and modularization difficult  The style is too monolithic.  Scalability and Maintenance becomes uncomfortable.  The migration to web applications is difficult Object Oriented Paradigm  Makes the abstraction and modularization easier  It has a distributed style  Scalability is more managable and with a good design the maintenance is a lot easier and secure.  It’s much easier to migrate to web application style.

6. …and for VAR3 ?? Imperative  Specifically in C. the DBUS it’s not scalable to a distributed system.  With DBUS the abstraction becomes difficult because it doesn’t integrate a lot of functionality. Object oriented  The Java virtual machine can manage using simple threads.  The java technology in this case can be useful to a programmer because of its high level of functional abstraction.

7. Costs Imperative-C  At first sight, keeping the code developed and continue from then is the lowest cost way in short term.  As it was explained, with this paradigm we have troubles with maintenance and scalability and in long term that costs a lot. O.O – Java  Changing the programming paradigm has more cost attached.  The design that we have now can be reused and expanded to O.O.  But in a long term vision the maintenance and scalability will make this inversion worthy.

8. Portability – cross platform ability Imperative – C  The c code can be compiled in other unix/linux systems. But there are conflicts with a lot of dependencies For example: even in the same windows platform the development environments have different ways of coding. Conflicts between linux distributions O.O. Java  The java virtual machine concept allows to run in a set of different architectures without recompiling.  The configuration changes that may be needed can be made with in the data base or xml config file context

9. Troubles found

10. What do we have now ? The sound is drove by Gstreamer The process are intercommunicated by DBUS The GPI/O card is drove by a driver developed for CTI. You can match a zone with a certain number of lines of the GPI/O card

11. Gstreamer performance The gstreamer framework, as is shown, loads the CPU in a unacceptable way. The recommendation is to avoid the usage of this framework

12. Gstreamer performance

13. Gstreamer The generated code doesn’t convey with the design and this brings a lot of high coupled code: each modification in one part implies modifications in many places and a lot of recompiling.

14. DBUS interprocess communication Doesn’t support a distributed paradigm It has a poor abstraction of a messaging schema The semantic becomes a programmer’s responsibility (work load) Expanding the system will be extremely difficult especially in a distributed scheme

15. Development documents In the company there was a lack of software development documents. There were no documents in these areas :  Specification  Design  Programming  Testing The wiki navegavility was a little uncomfortable There was no software development standard at all.

16. Data base right now SQLite3 Disadvantages  No security  No referential integrity  No stored procedures  No triggers

17. Good things found Audiopath design General Layer design Client scheme Backbone design VCP definition Embedded DB

18. NEW PROPOSAL

19. New horizons Adopt Object Oriented paradigm Cross-platform Java Virtual Machine There are some parallel issues: development methodology, and documentation schema. The audio path abstraction can be reused along with the scheduler logic, the admin and configuration logic. too

20. Very general overview

21. The layer design

22. Some protocols and interfaces must be supported by the new design Back End CTI AIP (Analog Interface Protocol) xDA old protocol (ASCII based) used for:  uDA  bbDA  cbDA  M4-bbDA  bbDA1094 SNMP for the new xDA technology Legacy drivers and protocols for some devices in use

23. Drivers and Protocols abstraction xDA device family example

24. Hardware Control Layer Design - a design oriented to the modularization

25. The factory knows what classes to instantiate

26. HW Control Layer Sequence Diagram

27. Data base server architecture Referential integrity Security Stored procedures Scalability -- MySQL (open source) Data base Proposal

28. Data Base Access Diagram

29. MySQL Cross platform: works in more than 30 platforms Big subset of ANSI SQL 99 Stored Procedures Triggers Views VARCHAR support Distributed transaction support Independent data engines (for quick read and transactions) SSL support

30. Documentation Schema Project specification Project plan Project time table  Work plan (MS Office Project) Requirements specification  Use cases diagrams (MS Office Visio)  Data base conceptual model (MS Office Visio) Detailed Design Tests Plan  Error Report (MS Office Excel)

31. Framework to use: SPRING By Rod Johnson Programming to interfaces rather than concrete classes The applications are not attached to the spring framework