Introduction to the Podcast Series and the Connection to the Lecture and Lab

Introduction to the Podcast Series and the Connection to the Lecture and Lab Alexander Schatten www.schatten.info................................................. Institut für Softwaretechnik und Interaktive Systeme

Architectures and Practices for Agile Software Development Alexander Schatten................................................. Institut für Softwaretechnik und Interaktive Systeme

20 Years ago... "Reusing other people's code would prove that I don't care about my work. I would no more reuse code than Ernest Hemingway would have reused other authors' paragraphs. One of Apples important developers in the late 80s................................................. Institut für Softwaretechnik und Interaktive Systeme

Motivation!! Re-Invent the Wheel or!! Reuse, Recombine existing knowledge?................................................. Institut für Softwaretechnik und Interaktive Systeme

Agenda!! Introduction to Best-Practices in SE!! Introduction of Podcast Episodes! Design Patterns! Automation! Test-Driven Development! Component-based Development! Team-Cooperation! Runtime Observation! Technology Roundup................................................. Institut für Softwaretechnik und Interaktive Systeme

Agenda!! Architectural Challenges: Agile Sofware Development?!! Pattern-driven Architecture: Considering Patterns on various Levels!! (Enterprise) Architectures! Component-Based! Service-Oriented Architecture! Enterprise Integration Patterns! Event-Driven Architecture!! Runtime System Surveillance!! Test-Driven Development................................................. Institut für Softwaretechnik und Interaktive Systeme

Architectural Challenges: Agility?!! Agility? Fast Adaptation to! Changing Needs/Requirements (from Customer)! Changes in the Environment! Changes in the Development Team!! Reuse of Knowledge/Best Practices/Patterns!! Reuse of Components in Various Contexts!! Standardisation for Interoperability e.g. for! Enterprise Application Integration! Collaboration between Companies/Institutions (B2B, B2C, B2A)! E-Commerce Scenarios!! Support of Distributed (Global) Software Development!! Scaling and Virtualisation................................................. Institut für Softwaretechnik und Interaktive Systeme

Supporting Patterns (Best Practices) in Software Engineering!! Design Patterns (GoF)!! Software Build (see next presentation)!! Testing!! Enterprise Architecture! Component Frameworks/Platforms like EJB! SOA! EDA! Enterprise Integration Patterns!! UI Domain Patterns! Fat Client! Web-Application! I18N!! Management/Maintenance Patterns: Runtime Observation! Logging! System Monitoring, Surveillance!! Project Management and Collaboration Patterns! Open Source Systems! Distributed Development! Software as a Process!! Social Patterns! Global Cooperation! Decision Making..........!... Customer......... Integration......... (The.... new..... user.... Role)..... Institut für Softwaretechnik und Interaktive Systeme

Best-Practice-Software-Engineering: Software Design Patterns Alexander Schatten www.schatten.info.................................................

Design Patterns!! Decades of development experience!! Condensed in reusable patterns!! Patterns usable in different domains!! Only brief introduction here; reminder for patterns needed in the lab.................................................

Categorisation (Extract)!! Fundamental! Delegation! Interface! Strategy! Proxy!! Creational! Factory (Abstract, Prototype,...)! Singleton! Object Pool!! Structural! Container! Dependency Injection! Facade!! Behavioral! Observer/Observable! Event Listener!! Enterprise! Data Access Object Lazy Load! Model View Controler.................................................

................................................. Strategy Pattern

Singleton!! Only one (or a certain number) of instances of a class are allowed!! E.g.! classes that represent interfaces to hardware (there is only one machine of a certain type)! Classes that are resource intensive, but do not hold a specific state and can be reused.................................................

Factory Pattern alternatively!.................................................

Proxy Additional functionality can be addedd e.g., Aspects! Client! ProxySubject! RealSubject!.................................................

................................................. Object Pool

Without Facade Subsystem (z.b. send Email, Web-Session Handling)!.................................................

Facade Pattern (Reduce Interface Complexity) If required! If required! Main Interaction! Subsystem! Facade!.................................................

................................................. Observer (Event Listener)

Model View Controler Source: Sun Developer Network!.................................................

................................................. Data Access Object

Best-Practice Software Engineering Information Resources Examples and Documentation http://best-practice-software-engineering.ifs.tuwien.ac.at/ Podcast http://best-practice-software-engineering-pc.blogspot.com/ Blog http://best-practice-software-engineering.blogspot.com/.................................................

Best-Practice-Software-Engineering: Automation in the Software Engineering Process Alexander Schatten www.schatten.info Reinhard Pötz www.indoqa.com

Agenda!! Why Automation?!! Considering the Complete Development Lifecycle including:! Code generation! Compilation! Validation! Generation of Documentation! Test execution and Reporting! Dependency management!! Leading to Continuous Integration!! Tool Integration!! Eventually: Automatic Software Creation with Model Driven Development?

Why Automation?!! Development Process contains a series of repeating tasks (see next slide)!! Manual execution has several drawbacks e.g.:! It is awkward to do repeated tasks! Manually repeating things is error-prone (e.g., important tasks can be forgotten)! Reproducibility can be a problem as a very clean documentation of all manual tasks would be required! Team Development is hardly possible when manual tasks have to be performed in the build process! Quality problems, as important, but boring tasks like executing test-plans are just not performed regularly when testing is not fully automatised! Continuous integration is not possible

Project Build Lifecylce: Best Practices!! Build Process should be Portable and Independent of IDE!! However Integration with common IDEs should be possible!! Reporting should be part of the Automation like! Project Documentation! Build Error and Problem Reports! Test Reports!! Integration into other Build Systems should be possible (e.g. to Continuous Integration Tools, IDEs), i.e. the system should have an API!! Apache Maven Team analysed Project Lifecycle and derived bestpractices for build process like:! Suggested Directory Structure! Provide Project Metadata! Generic Description of Dependencies! Definition of Project Build Lifecycle! Standardised Reporting

What can be Automated? Examples!! Validation (Metadata, Code,...)!! Source Generation (e.g. from Metadata or Annotations)!! Automatic Code-Quality Checks (e.g. Checkstyle)!! Compilation!! Post Processing of Binaries!! Generation of Test-Resources!! Execution of Tests!! Generation or various Reports (e.g. Test-Reports)!! Generation of Documentation (e.g. html, pdf)! Project Info! Source Code Docs! User Documentation! Test & Quality Reports!...!! Packaging!! And much more...

Advantages of Automation: Examples!! Project is Portable between Developers!! Quality of Project is increased! Automated Code Quality Checks! Automated Test-Execution!! Project Reporting can be automated!! Continuous Integration can be implemented

Build Support Tools!! Tools for different program languages and platforms!! Vary in capabilities and concept!! Examples! Unix make (e.g. for C/C++ projects)! Apache Ant for Java! NAnt for.net! Apache Maven! Rake for Ruby (on Rails)!! Also Shellscripts and Batchfiles are sometimes used; Problem: portability (e.g. among platforms)

Maven 2!! Based on Integrated Lifecycle-Management!! Build- und Deployment Tool!! Simplifies Management of Java Projects!! Manage Documentation of Java Projects!! Large Number of Plugins available! Embed Maven in IDEs (Eclipse, JavaDoc, etc.)! Plugins for Maven!! Project Object Model = POM!! Supporting Multi-Module Projects!! Dependency Management

Maven Build-Lifecycle 1 validate validate the project is correct and all necessary information is available. generate-sources generate any source code for inclusion in compilation. process-sources process the source code, for example to filter any values. generate-resources generate resources for inclusion in the package. process-resources copy and process the resources into the destination directory, ready for packaging. compile process-classes post-process the generated files from compilation, for example to do bytecode enhancement on Java classes. generate-test-sources generate any test source code for inclusion in compilation. process-test-sources process the test source code, for example to filter any values. generate-test-resources create resources for testing. process-test-resources copy and process the resources into the test destination directory.

Maven Build-Lifecycle 2 test-compile test compile the test source code into the test destination directory run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed. package pre-integration-test take the compiled code and package it in its distributable format, such as a JAR. perform actions required before integration tests are executed. This may involve things such as setting up the required environment. integration-test process and deploy the package if necessary into an environment where integration tests can be run. post-integration-test perform actions required after integration tests have been executed. This may including cleaning up the environment. verify install run any checks to verify the package is valid and meets quality criteria. install the package into the local repository, for use as a dependency in other projects locally. deploy done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Lifecycle Actions!! At each lifecycle phase various tasks can be performed!! Many tasks available packaged with Maven!! Others can be added as plugins!! Development of own tasks: Maven Mojo

Archetypes!! Create default projects with Maven archetypes mvn archetype:create \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DgroupId=com.mycompany.app \ -DartifactId=my-app

Maven!! Maven provides a default-structure: <project> <modelversion>4.0.0</modelversion> <groupid>com.mycompany</groupid> <artifactid>my-app</artifactid> <packaging>jar</packaging> <name>sample application</name> <dependencies>... <dependencies> </project>

Dependency Management

Documentation!! General Project Information! Version! Name, Description! Contributors! License! Development Tools (Mailinglist, Repository,...)!! Architecture Description!! Source Code (javadoc)!! Code Quality Reports! Test Reports! Checkstyle! Component Dependency Reports!...!! User Documentation

Testing!! Maven executes test-cases (junit)!! Test Reports are produced! Text! XML! HTML!! Integration into Documentation System

Continuous Integration!! Provide Maven POM including SVN repository definition!! Automatically! Updates code! Build Project! Create Documentation! Test Project!! Make notifications (mail, IM,...) according to project status (testfailure,...)!! Example: Apache Continuum!! See Martin Fowlers article on Continuous Integration: http://www.martinfowler.com/articles/continuousintegration.html

Automated Code Quality Checks!! Some types of code-quality checks can be performed automatically and can give hints about potential problems in the code!! Specialised tools can check unit test code coverage (e.g. Clover)!! Several tools exist to support such checks! IDEs! Specialised tools like Checkstyle!! Tools like Checkstyle can be embedded in Build automation (see later slides) and can provide integrated reporting

Example: Checkstyle for Java!! Javadoc Comments!! Naming Conventions!! Headers!! Imports (*)!! Size Violations!! Parenthesis!! Modifier Order!! Coding (30 Optionen)! Modified control variable (for...)! Simplify boolean expressions!! Duplicate Code!! Cyclomatic Complexity (minimal path through codepart)!! NPath Complexity (number of possible execution paths through a function)!! Search for TODO: Comments

Automation, Reporting and Documentation!! Documentation and Reporting are integral aspects of automated testing!! Most tools produce test reports in generic formats, that can be reused! Text! XML! HTML!! Integration into Documentation Systems e.g.. with Maven is recommended!

Continuous Integration!!! Martin Fowler indicates the following best-practices:! Single Sourcecode Repository! Build Automation! Make build Self-testing! Daily (or more regular) commits by each developer!! Keep the build fast! Test in a clone of the production environment! Transparency! Easy access to latest binary (see e.g. Apache Daily builds)! Everyone should see the status (web-reports, notifications)! Automate Deployment

E.g. Cruise Control

Apache Continuum!! Maven Subproject!! Installation on Server!! Definition of series of projects! Maven 1! Maven 2! Ant! Shell!! Integration with several SCM (source code management) systems like SVN, CVS!! Web-Frontend for working with projects & reporting!! Schedule Definition for Build automation!! Reporting!! Notification!! See Example Screeshots on next slides

Reporting During Build Process

Build Process Nearly Finished

Result List

Details about Build Result

Definition of Schedulers for Build Automation

Best-Practice Software Engineering Information Resources Examples and Documentation http://best-practice-software-engineering.ifs.tuwien.ac.at/ Podcast http://best-practice-software-engineering-pc.blogspot.com/ Blog http://best-practice-software-engineering.blogspot.com/

Best-Practice-Software-Engineering: Component-based Programming Alexander Schatten www.schatten.info Markus Demolsky Indoqa

Enterprise Architecture: Levels of Reuse Coupling Object direct invocation, Instantiation Object decoupled invocation over indirection (Delegation, Factory,...) Object Interface Object Reuse of Components within Component Framework (Dependency Injection...) Component Framework Object Potential Reusability Aggregation Component Component (s) Platform Specific Communication or Remoting Reuse of Components as (Platform Independent) Services Service Framework: Registry, MOM, ESB, SLA, Security,... Platform Neutral Communication or Remoting, e.g. WSDL/SOAP, XML/REST Object Overhead, Complexity

From Objects to decoupled Components and Application Aspects!! Objects!! Interfaces!! Components and decoupling!! Componet Frameworks

Objects!! Object encapsulates! Data! Functionality Data Public Variables Private Variables Functionality Object o = new Object() Public methods Private methods

Interfaces!! Interfaces describe abstract functionality without Implementation Interface Objects Declaration of Class Interface No Functionality Implementation Method Signatures Interface i; i = new Object/Component();

Components!! Component wraps larger blocks of functionality! Clear Interfaces! Reuse! Loose Coupling!! Component framework allows decoupling of client objects from concrete component implementations! Interface i;! i = componentframework.getcomponent( Name of Component );

Interface Objects Declaration of Class Interface No Functionality Implementation Method Signatures Component Framework Management of Component Lifecycle Configuration mycomponent = conrete Object Interface i; i = componentframework.getcomponent( mycomponent );

Dependency Injection!! Information Service use other service components in order do the work " Dependencies!! Resolved with Dependency Injection

Object Graphs through Dependency Injection!! Well known concepts to build object-graphs:! Factory Pattern! Name-System (JNDI)! Service Locator!! Disadvantage? " Increasing complexity " Dependency on Infrastructure " Component retrieves dependency!! Dependency Injection injects dependency from outside!! Types of Dependency Injection: - Setter Injection - Constructor Injection!! Spring supports both types

Spring!! Lightweight in the sense of: - No other infrastructure required(e.g.: application server) - modular concept

Comparison of Initialisation Options!! Direktes Erzeugen public class ShopServiceImpl implements IShopService{ private IOrderDAO orderdao = new IOrderDAOImpl(); private IProductDAO productdao = new IProductDAOImpl(); private ICustomerDAO customerdao = new ICustomerDAOImpl(); }!! Mittels Factory public class ShopServiceImpl implements IShopService{ private IOrderDAO orderdao = Factory.getOrderDAO(); private IProductDAO productdao = Factory.getProductDAO(); private ICustomerDAO customerdao = Factory.getCustomerDAO(); }!! Mit Dependency Injection (Setter Injection) public class ShopServiceImpl implements IShopService{ private IOrderDAO orderdao; private IProductDAO productdao; private ICustomerDAO customerdao; public void setproductdao(iproductdao dao){ this.productdao = dao; } public void setorderdao(iorderdao dao){ this.orderdao = dao;.......... } }....................................... Institut für Softwaretechnik und Interaktive Systeme

Dependency Injection with Spring!! Configuration file, e.g.: beans.xml <beans> <!-- DAOs --> <bean id="productdao" class="at.demolsky.product.dao.iproductdaoimpl"/> <bean id="customerdao" class="at.demolsky.customer.dao.icustomerimpl"/> <bean id="orderdao" class="at.demolsky.order.dao.iorderdaoimpl"/> <!-- SERVICE BEANS --> <bean id="shopservicetarget" class="at.demolsky.shop.shopserviceimpl"> <property name="orderdao" ref="orderdao"/> <property name="productdao" ref="productdao"/> <property name="customerdao" ref="customerdao"/> </bean> </beans>

Spring ApplicationContext!! Spring offers BeanFactory (pure DI) and ApplicationContext (extended BeanFactory adds e.g.: Resourceaccess, Events, i18n)!! One or many config files ApplicationContext context = new ClassPathXmlApplicationContext ("applicationcontext.xml"); IShopService shop = (IShopService) context.getbean("shopservice");! Dependencies were injected by Spring!

Layered Architecture Style

Enterprise Architectural Styles: SOA!! Reusable, platform neutral Service (e.g. XML based Messaging using SOAP)!! Service Oriented Architecture (SOA)! Strong Decoupling! Platform Independent Service Access! Reuse over Boundaries! Various additional Requirements! Service Descriptions! Encapsulation of Legacy Systems (see next slide)! Unified Bus for Communication (see next slide)! Security (Encryption, Authentication,...)! Reliability! Service Level Agreements! Registry Services! Service Aggregation! Service Orchestration and Choreography!...

Best-Practice Software Engineering Information Resources Examples and Documentation http://best-practice-software-engineering.ifs.tuwien.ac.at/ Podcast http://best-practice-software-engineering-pc.blogspot.com/ Blog http://best-practice-software-engineering.blogspot.com/

Test-Driven Development Alexander Schatten, Erik Gostischa-Franta.................................................

About... Testing!! We offer special lectures to quality assurance, testing, inspection...!! In this first lecture we only cover fundamental testpractices:! Test-Driven development with Unit Tests! Test-plan.................................................

Testing as a team effort!! Intelligent distribution of roles within the team is neccessary!! Testers (Testing roles):! Test your objects just like they will be used in the context of your program! Tests are "living documents" they document how a class should be used!! Architects (Architect roles):! Modular Design: "short" programs with "tiny" methods! Autonomous Design: isolated classes (instances are required)! Create class diagrams.................................................

Test-Driven Development!! Every feature in the application that gets implemented has to be testable!! E.g., falsification in science: every new theory has to be expressed in a way, that it can be tested/falsified!! I.e. when you consider new functionality, at the same time think how it can be tested!! Testing either automatically using unit tests, automatic UI tests,... or manually following test-plans!! Test comes before or parallel to implementation!! Challenges are new architectural styles (SOA, EDA).................................................

Test-Driven Development Traditional: Programming Test Definition Test Execution Finding Bugs becomes difficult, particularly in a team-environment Better: (1) Write Test before Implementation (2) Short Cycles TD P TE TD P TE TD P TE.................................................

................................................. Categorisation by Granularity

Amount of Tests by Granularity!! The time for a rich Unit-Test codebase is well invested since it simplifies integration tests. (bottom-up testing)!! System Tests!! Integration Tests!! Unit Tests.................................................

Test-driven implementation class X! junit! extends TestCase Execute Test! class XTest! Method X.a()! Method X.testA1()! Method X.testA2()! Method X.b()! Method X.testB()!...!.................................................

Basic Unit Testing Framework!! In Object-Oriented Languages: Unit == Class!! A minimal Unit-Testing 'framework' consists of 4 classes, for example:!! TestCase, basic Unit-Test class!! StudentDAOTest, inherits from TestCase!! StudentDAO, class to be tested!! TestRunner, runs the test and reports the test result!! TestCase: because every new Test inherits from this class the TestRunner is able to execute it in a standard way!! TestRunner: Running tests and reporting the result is fundamentally simple.................................................

................................................. Class Diagram

................................................. Initialise Junit Testcase

................................................. A Test Method

Best-Practice Software Engineering Information Resources Examples and Documentation http://best-practice-software-engineering.ifs.tuwien.ac.at/ Podcast http://best-practice-software-engineering-pc.blogspot.com/ Blog http://best-practice-software-engineering.blogspot.com/.................................................

Best-Practice-Software-Engineering: Team Cooperation Alexander Schatten www.schatten.info Reinhard Pötz www.indoqa.com

Team Cooperation!! Sourcecode and Document Repository!! Communication! Email: Mailinglist! Chat/VoIP! Forum!! Continuous Integration!! Unit-Tests (!)! Communication of expected functionality! Communication of bugs!! Groupware! Issue Tracker! Wiki

Sourcecode Management!! The Problem of File-Sharing! Email! Shared Folders!...!! File Portability!! Data Safety!! Versioning!! Branching and Merging!! Centralised and decentralized variants e.g.:! Subversion (SV)! GIT!! Clients! Standalone (UI)! Commandline! IDE support! Build Tool support (e.g., Ant, Maven)

Collaboration Strategies!! File-Sharing!! Lock-Modify-Unlock!! Copy-Modify-Merge!! The following examples base on Subversion (SVN) See: Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, TBA (2007)

Example Hierarchy with Subversion root! myproject! trunk! branches! src! test! docs! experim_alex! Main.java! src! test! docs! Main.java! Experim.java! Release_1.1! Release_1.2!...! anotherproject! tags! beta_1! release_1! release_2! beta_3!...! src! test! Main.java! trunk! branches! tags!

Basic Operations!! Initial Checkout!! Update local copy!! Make Changes to local copy!! Commit Changes to repository

Further Operations!! Merge Conflicts!! Review History!! Go back to older version!! Branching (work with different versions)!! Tagging

Revisions in SVN!! An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents, create, delete, rename and copy files and directories, and then commit a complete set of changes as an atomic transaction.!! Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.!! From: Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, TBA (2007)

Code Quality Checks on commit!! SVN Hook!! Check on sourcecode quality criteria e.g.! Spaces/tabs (history!)! Checkstyle!...

Issue Tracking & Tool Integration!! Automated Testing is important, but many problems and issues are found by humans, i.e.! Developers themselves! Customers! Users!! A proper Bug/Issuetracking tool is imperative for a software project!! All stakeholders should have access to the tool!! Users should be able to add issues!! Select/configre tool so that also end-users are able to add issues!!! Examples on next slides

Issue Tracking?!! What?! Capture! Issues! Bugs! Feature Requests! ToDos! Create Reports (per developer,...)! Allow Queries!! Who?! Developers! Tester! Customer/User!! Define Roadmap(s)!! Should Operate hand in hand with versioning system

Example: Trac Issuetracking

Trac Tickets to Roadmap

Trac Reports

Trac Ticket Details

Trac Timeline

Tool Integration!! Ideally build-tools are highly integrated!! E.g.: Trac allows to connect to SVN using post-commit hooks, this means! When developers commit changes and add the Ticket ID to the commit info Trac gets informed about the commit! Then Trac shows the SVN info / sources with the ticket!! Continuous Build Tool! React on SVN commits! Notify developers (mail, IM)!! Requirements-Tracking! Attach Requirements to SVN, Issues,...

Example Trac Ticket closed

Link to Changeset

Best-Practice Software Engineering Information Resources Examples and Documentation http://best-practice-software-engineering.ifs.tuwien.ac.at/ Podcast http://best-practice-software-engineering-pc.blogspot.com/ Blog http://best-practice-software-engineering.blogspot.com/

Best-Practice-Software-Engineering Lab: A First Technology Roundup All used technologies are Open Source technologies! Alexander Schatten www.schatten.info.................................................

Used technologies!! Build Management: Apache Maven!! IDE Eclipse!! Logging: Apache log4j!! Testing: JUnit!! Component Framework: Spring!! I18n!! Persistence! Relational Database: hsqldb! Configuration and DAO: Spring! JDBC! Spring JDBC Templates! (XML: dom4j)!! User Interface: Java Swing!! Documentation! Javadoc! Apache Maven.................................................

Integrated Development Environment: Eclipse!! Project Management and Dependency Management defined in Maven POM!! Build driven by Maven!! Maven generates project files e.g. for Eclipse!! Eclipse supports daily development process! Editing! Code Completion! Package Management! Refactoring! Debugging!...!....................................................

Why Logging using Apache log4j?!! System.out.println -> Performance loss!! log4j optimizes performance!! Declare! What to log! When to log! Where to log to!! Flexible logging configuration for different contexts! Development! Test! Debugging! Operational.................................................

Logging with log4j!! Log what? (log-level)! DEBUG! INFO! WARN! ERROR! FATAL!! Debug<Info<Warn<Error<Fatal!! Log when? Fine tune packages that should be logged with what log-level!! Log where to?! Console! Database! Logfile!....................................................

Container/Component Framework.................................................

Internationalisation (i18n)?!! Example: Application should run in multiple languages!! Hard-coded String problematic! -> Duplication of Sourcecode... Very bad solution!!! Translation should be done by translator not technician!! Goal: Separation of Text and application.................................................

Solution: ResourceBundle!! Separation from Sourcecode and Strings!! One Option: Store Strings in textfile as key/value pairs!! Support by Eclipse!.................................................

Access to ResourceBundle!! Class Messages loads Strings from file and returns it to application according to locale.................................................

Multiple Languages/Translations!! Messages in resource-textfile (key/value)!! Naming of resource file!! <name>[_<languagecode>][_<subset>].properties!! For example! messages.properties! messages_de.properties! messages_de_at.properties!! Automatic selection of best-fitting translation!! If nothing fits, the default file is used.................................................

I18N and Localisation!! Unicode!! Formatting (e.g., date, time, currency)!! Sorting (é before ê or...?)!!....................................................

Persistence!! Relational Database: hsqldb!! JDBC: Standard Java interface for database access!! Configuration and DAO: Spring!! Spring JDBC Templates, no plain JDBC!! Clear separation of SQL code and Java application! Full integration into Component Framework! Usage of Spring DAOs, Transaction,... possible!! (XML: dom4j).................................................

Relational Database HSQLDB!! Pure Java Database with minimal footprint!! Easy to use!! Hardly configuration and setup required!! Integrates perfect in Java environment! Can be used embedded, starts then with application, no server setup! Integrates well in test, development and debugging!! Different operation modes (partly on table level)! Embedded! Server! Memory only.................................................

User Interface Java Swing!! User interfaces are developed with Java Swing!! Platform Independent UI library!! Following Model View Controler Pattern!! Check out good resources like! Sun Swing Tutorial! Guide Krüger: Javabuch.de! Basic Example.................................................

Information Sources.................................................

Best-Practice SE!! best-practice-software-engineering.ifs.tuwien.ac.at! Follow introductions to examples, patterns and technologies! In each section additional references are given!! best-practice-software-engineering.blogspot.com!! TuWel Foren!! Repetitorien!! Podcast?.................................................

.................................................

Open Source Projects!! Websites of projects, e.g., Maven site, Sun Swing tutorial etc.!! Mailing-lists and archives of the according project!! gmane.org newsserver integrates mailing lists!! Books (partly free books available, e.g., for Maven, Subversion, Java, Swing)!! Wikis of projects.................................................

Homework!! Get on overview on the BP site and Blog!! Download Basic Example and try to get an overview!! Get an overview on the project websites of the used technologies!! Try to create a simple project structure with Maven following the Maven Getting Started guide!! Download the Guide Krüger book: javabuch.de!! Post all questions and problems into the tuwel forum!! Repeat patterns learned today for next lecture unit!! Try to abstract the information presented here! What is concrete, special (e.g., for Java)! What are general architectural approaches.................................................

Contact Dr. Alexander Schatten Vienna University of Technology Institute for Software Technology and Interactive Systems Vienna, Austria, Europe :-) http://www.schatten.info.................................................