Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
EGOWS 2004: Workshop „System Architecture“ Recipients Participants of the EGOWS 2004 conference Author Date Martin Lehmann, sd&m AG 2004-06-25 Revision history No 1.0 Document Date 2004-06-25 Revision First draft of the minutes This document is a minute document on the results of the EGOWS 2004 workshop on „System Architecture“. Please refer also to the mindmap EGOWS2004_WorkingGroup_SystemArchitecture.mmp (or its PDF printout, respectively). Workshop Topics No. 1 2 3 4 5 6 7 8 Topic Why are we dicussing Architecture ? Don’t we get the Architecture for free ? "Convince Process" needed Design Topics Role of Java Development Process Usage of Off-the-shelf systems Is there a panacea for Architecture ? 1 Topic 1 Why are we dicussing Architecture ? The topic „System Architecture“ is important due to several reasons. Workstation system have a long life cycle (up to 15 years), so that the definition of a useful and stable System Architecture is important. Currently, new workstations systems are in development, examples: Germany: Development of NinJo to replace the MAP system Hungary: Current HAWK version has reached the end of its life cycle, new HAWK version is developed Topic 2 Why don’t we get the System Architecture for free ? The pure collection of ideas and features does not lead to a stable and good architecture automatically. Good solutions for special problems might be known already (from the experiences of the development of older/other systems). But the glue components and the „big picture“ might be missing. So the definition of a System Architecture does not come „for free“. Its definition is an on-going process. "Cleaning steps" and „Refactoring“ are needed and useful , as long as the overall architecture ideas are not violated. Topic 3 Convince Process is needed A "Convince Process" is needed to make sure, that people understand, why the definition of the System Architecture is useful. So the project teams has to convince management and developers … … as following an overall architecture idea might lead to delays … that „pure coding and hacking“ is not the solution … that new technologies should be used … that things have to start from scratch sometimes This „Convince Process“ is successful, if one sees the benefits of the overall Architecture. Example are the very positive experiences when doing NinJo benchmarks: Absolutely no efforts were needed when porting NinJo release to the Apple platform. 2 Topic 4 Design The idea of Design Patterns has been proven. Benefits are: No need to invent the wheel again and again ... Design Patterns are very helpful for the communication: Just naming the pattern helps to communicate effectively and one can communicate very precise. Examples: MVC („Model-View-Controller“) for GUI design NinJo uses PAC pattern („Presentation-Abstraction-Control“) For the development process the so-called Template Pattern is very helpful: A code template is defined for how components should look like. Base classes and interfaces help to define these templates and to enforce that the pattern is followed. Frameworks and other generic base implementations help the developers, too: There is then no need to care for a lot of functionality as this is encapsulated and cared for in the generic components. In Object-Oriented Languages the combination of inheritance and defining interfaces has been proven. But: Inheritance might be a problem as this implies a tight coupling between the modules. Topic 5 Role of and Experiencies with Java Java is proven to be a good choice for Workstation Systems: Portability on the most popular platforms is available for Java. Portability issues are moved to external packages, which care for the binding to the platform. Examples: Java Advanced Imaging (JAI), OpenGL etc... One has the benefit of using utilities and lots of Open Source packages, where it is easy to get support. The incredible richness of libraries helps a lot, so that one does not need to start from scratch. Comparing Java to other languages: Is is useful to do the implementation of core modules in C ? You might win some speed but loose a lot of flexibility, portability etc. Java vs. DOT.NET: DOT.NET is still not a choice if one really needs portability (Linux port "MONO" is not really available) Future of Java open at the moment but available since years Role of SUN and Microsoft not totally clear after their deal some weeks ago. Java has very strong support by IBM: IBM pushes Java and wants it to get Open Source. 3 Topic 6 Development Process In a large and distributed team, a Development Process has to be defined, as „Communication is everything“. This has several implications: Documentation (like Javadoc, Design documents to show the big picture). Documents should be published and made available for everyone in the team. Naming Conventions are helpful. Coding Standards should be defined (Java example: Book "Elements of Java Style"). A Architecture Core team is needed to ensure the process and the core idea of the Architecture. Sometimes: "You need the person with the whip"; so one how finally decides (chief architect for design issues). Training Courses and Updates are helpful to distribute the knowledge. Example: NinJo courses with slide presentations and programming exercises. Change Management has to be defined: Requirements have to be defined and written down. Feedback to the authors of requirements is needed if new/changed requirements have huge impacts on the architecture. Topic 7 Usage of Off-the-shelf systems: "Write or buy" ? Old systems difficult to maintain, especially as lot of the functionality has been written as individual software. So the (re)usage of (commercial) standard components might be helpful. Moving from „reusing of Code“ to „reusing of Systems“ is an on-going process. Commercial databases and/or application servers (like defined in J2EE) might be worth a look. Problems and Deficiencies of off-the-shelf systems: Integration with own software is not easy. Normally only a small amount of functionality can be reused: Overhead is a „killer“ argument. (Example: Commercial GIS vs. Individual Workstation) Commercial apps do not really fit the needs. Most of the time a „90% solution“ is not acceptable. (Example: NinJo library for diagrams: Commercial „Jchart“ was not sufficient so that an individual NinJo Diagrams framework was developed) 4 Conclusion Is there a panacea for Architecture ? No, unfortuately, there is no silver bullet but some „Golden Rules“: On the "Technology level": Create the system open and extensible Use abstraction On the "Process level". Care for: Communication Training Experience So it is important to have … the Commitment by management and developers … a well defined process … the help of standard techniques (like Design Patterns) 5