Communardo Software GmbH Lösungen aus Leidenschaft für Netzwerke

Communardo Software GmbHLösungen aus Leidenschaft für Netzwerke

Communardo Software GmbHLeistungsportfolio - Kompetenzen

Themen Produkte Technologien

• Knowledge Management

• Intranet 2.0

• Project & Team Collaboration

• Microsoft Office SharePoint Server

• Microsoft Office Project Server

• Atlassian Confluence Enterprise Wiki

• Communardo ProductivityNet Publisher SurveyFramework

• Individuelle Software- Entwicklung • auf Basis Java/JEE, .NET und PHP

• Technische An- forderungsanalyse und Software- konzeption

Communardo ThemenModerne IT Lösungen im Enterprise 2.0

KnowledgeManagement

Project & TeamCollaborationIntranet 2.0

• Wissensportale

• Enterprise Wikis

• Community

Portale

• Corporate Search

• Corporate

Tagging

• Team Workspace

• Corporate Blogging

• Collaboration Workflow

• Security Workspace

• Virtuelle Projekträume

• Weblogs für Firma, Bereich und Mitarbeiter

• Wissenswiki

• RSS-Feeds

• Social Bookmarks

• Personalisiertes Tagging

Communardo Software GmbH Referenten

Dipl.-Inf. Torsten Lunze

Software Architekt

www.communardo.de

www.xing.com/profile/torsten_lunze

Dipl.-Inf. Tino Schmidt

Teamleiter CMT

www.communardo.de

www.xing.com/profile/Tino_Schmidt5

Effiziente Softwareentwicklung

1. Motivation

2. Build Management

3. MDA

4. Software Factories

5. Test & Reports

Effiziente SoftwareentwicklungWas ist Effizienz?

DIN EN ISO 9000:2000

„Effizienz ist das Verhältnis zwischen dem erzielten Ergebnis und den eingesetzten Mitteln.“

> Maß der Wirtschaftlichkeit

Quelle: http://www.spmconsult.de/Effizienz.jpg

Effiziente SoftwareentwicklungWarum beschäftigt uns dieses Thema?

Standish Group führt seit 1994 Umfragen zum Erfolg von Softwareentwicklungsprojekten durch -> CHAOS Report

0% 20% 40% 60% 80% 100%

2004

2002

2000

1998

1996

1994

erfolgreich

behindert

gescheitert

Effiziente SoftwareentwicklungKriterien für den Erfolg von Projekten.

Termin eingehalten

Kosten eingehalten Anforderungen erfüllt


… führt zu:

- ertragreichen Projekten

- zufriedenen Kunden

- zufriedenen Mitarbeitern

- Wachstum und Arbeitsplätzen

- Freiraum für Innovationen

Die Summe zeigt: ein wichtiges Thema.


Schwerpunkt dieser Vorlesung:

- Betrachtung technischer Einflüsse

- Vorstellung MDA, Produktlinien

Was ist nicht Inhalt dieser Vorlesung:

- Projektmanagementthemen

- Teamstrukturen, Zusammenarbeit

- Kunden – Auftragnehmerbeziehungen

Probleme in der Softwareentwicklung

Analyse Entwurf Implemen-

tierung Integration

& Test Installation

Standards/Richtlinien werden nicht eingehalten

nicht ausreichende Dokumentation

unklare Anforderungen

hohe Fehlerrateninstabiles System

Copy&Paste - Code

lange Implemen-tierungszeiten

wiederkehrende Implementierungs-aufgaben durch fehlende Modularität

Kommunikation

Zu schneller Start in die Implementierung

Qualitätsmerkmale werden nicht festgelegt.

Vorgehens-modell fehlt

Systematische Tests fehlen

Kundenzufriedenheit sieht anders aus.


Frameworks und Bibliotheken nutzen

- generische Lösung für verwandte Probleme

- aktive Wiederverwendung

- z. B. Jakarta Commons Bibliotheken

Generierung nutzen

- in der integrierten Entwicklungsumgebung

- bei der Erstellung von WebServices

- für ganze Projekte und Module

Implementierung


Einheitliche Entwicklungsumgebung

- Pakete mit Voreinstellungen bereitstellen

- Eclipse Distribution: Yoxos

Wikis & FAQs

- Links der Umgebungen (Dev, TuA, Live)

- Entwicklungshandbuch

- technische Beschreibungen, Zugangsdaten

Infrastruktur


1. Motivation

2. Build Management

3. MDA


5. Test & Reports

Buildmanagement

• Teil des Konfigurationsmanagements

• Erstellung eines Softwarepaketes (Buildskripte)

• Verteilen der Softwarepakete (Deployment)

• Berechnung von Softwaremetriken

• Automatisierung dieser Punkte

• Tools:

• Ant• Maven• Continous Integration (Continuum, Cruise Control)• Shell Skripte

© Communardo Software GmbH · Fon +49 (0) 351 833820 · [email protected] · www.communardo.de

Folie 15

Entwickeln im Team


Folie 16

SVN Repository

Commit


Folie 17

SVN Repository

Commit

Update

Entwickeln im Team

Entwickeln im Team


Folie 18

SVN Repository

Commit

Update

Compiler Error!

Ursachen für Fehler

• Fehlerhafter Stand wurde eingecheckt

• Bearbeitung gleicher Module

• Fehler im lokalen Code

• Falsche Konfiguration


Folie 19

Continous Integration


Folie 20

SVN Repository

Commit

Update

Compiler Error!

Build

Test

Report

Fehler im Buildaufgetreten?



Folie 21

SVN Repository

Commit

Update

Compiler Error!

Build


• Definition Martin Fowler: „Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.” [http://martinfowler.com/articles/continuousIntegration.html]


Folie 22

Vorteile Continous Integration

• Schnelles Auffinden von Fehler

• Automatisierung von Tests

• Automatisierung der Überprüfung von Metriken

• Bereitstellung einer aktuellen Version zum Testen


Folie 23

Deployement


Folie 24

Lokal 1


DB

Applikation

Code

…DB

Applikation

Code

DB

Applikation

Code

DB

Applikation

DB

Applikation

Testsystem Wirksystem

Lokal n

Vorteile Build Management

• Standard Build Umgebung

• Früher: eigenes ANT Build Framework• Heute: Maven (1 und 2), Nutzung der Standardfunktion soweit es

geht

• Nutzung von Funktionen wie Continous Integration• Bündelung und Bereitstellung von Software• Kontinuierliche Generierung von Reports• Ähnliche Struktur der Projekte


Folie 25


1. Motivation

2. Build Management

3. MDA


5. Test & Reports

Motivation für MDA

• Welchen Vorteil bringt uns eine MDA Lösung?

• Anforderungen

• Return of Investment• Erlernbarkeit• Stabilität• Geringe Kosten für Tools


Folie 27

AndroMDA

• Java Sourceforge Projekt

• Version 3.2 im weiteren verwendet

• Modellierung erfolgt über UML

• Anpassungen durch UML Profile (Stereotypen und Tagged Values)

• Generierung anhand von Velocity Templates

• Bündelung von Templates und Konfigurationen in Cartridges

• Anpassung an generierten Code durch

• Vererbung• Mergemappings


Folie 28


Folie 29

Andromda Generierungsprozess

Cartridges

• Vorgefertige Cartridges:

• (N)Hibernate• EJB3• Spring• Webservices (AXIS, Xfire)• Struts


Folie 30

AndroMDA und Cartridges können direkt verwendet werden ohne Generator oder Templates anzupassen oder zu erstellen.


Folie 31

Andromda Standardarchitektur


Folie 32

=>

Modelliert

Generiert

RentalServiceBase

#handleGetCustomersByName( name : String )

+getCustomersByName( name : String )

#getCarDao() : CarDao

#handleGetAllCars()

+getAllCars() : List

#getPersonDao()

RentalServiceImpl

#handleGetCustomersByName( name : String )#handleGetAllCars()

RentalService

+getCustomersByName( name : String )+getAllCars() : List

ServiceLocator

+getRentalService() : RentalService

CarDao

+remove( car : Car, id : Long ) : void+allCarsRented() : boolean

+update( car : Car ) : void+create( car : Car ) : Car

+load( id : Long ) : Car+loadAll() : Car

CarDaoBase

+remove( car : Car, id : Long ) : void

#handleAllCarsRented() : boolean

+allCarsRented() : boolean

+update( car : Car ) : void

+create( car : Car ) : Car+load( id : Long ) : Car

+loadAll() : Car

CarDaoImpl

#handleAllCarsRented() : boolean

Car

-name : String-serial : String

-type : String-id : Long

+isRented() : boolean+getOwner() : Person

Person

-birthday : Date-name : String

+getCars() : Collection

CarImpl

+isRented() : boolean

Person.hbm.xml

Car.hbm.xml

PersonDao

Einmalig generiert

-owner

1

-cars

0..*

MDA - Buildmanagement

• Integration der Generierung in Maven 2

• Kleine Änderung im Modell

• Ziel: Nur die Dateien neu generieren, die davon betroffen sind

• Lösung: Generierung nur eines bestimmten Packages Generierung nur durch ausgewählte Cartridges

• Die Festlegung was neu generiert werden soll, wird nicht automatisch sondern muss vom Entwickler getroffen werden.

Versionierung von Modellen

• Problem: XML Format eines Modells komplex

• Mergen nahezu unmöglich

• Lösung:

• Aufsplitten der Modelle in Schichten (FE/Service/Backend) und Komponenten (User/Evaluation/Security…)

• Mehrere Modelldateien

• Nutzen von Locks in Versionskontrollen

• Alternativ:

• Teamworkserver (Checkin/Checkout über MagicDraw)

• Generierte Dateien nicht in Versionskontrolle

MDA - Releasemanagement

• Neues Release 2 wird entwickelt.

• Das Modell für Release 2 wird umfangreich angepasst.

• Es tritt ein Bug im Release 1 auf.

• Der Bugfix benötigt eine Änderung des Modells für Release 1.

• Die Änderung muss auch in Release 2 nachgezogen werden…

• Automatismus?

MDA - Probleme

• Konfliktlösung in Modellierung falls Entwickler gleichzeitig ein Modell bearbeitet haben

• BPM4Struts Cartridge zu unübersichtlich verwendbar

• Modellierung zu umständlich mit MagicDraw• Zusätzlich hoher Lernaufwand um Cartridge zu verstehen

• Bugs die durch Cartridge / Generator erzeugt werden sind schwieriger zu beheben

• Lösungen die an Standardarchitektur vorbeigehen:

• Erstellung von nichtgenerierten Klassen • Keine Modellierung im Modell


Folie 36

Einfluss auf den Softwareprozess

• Learning Curve: „Lernen statt Arbeiten“• Lernaufwand höher: Zu verstehen was wird wie wo generiert• Dafür Einsparung von Arbeit: Kleine Anpassung im Modell

Große Änderung im Code (anstatt per Hand)

• Bei der Konfiguration des Projektes:• Auswahl der zu nutzenden Cartridges• Anpassung, Erweiterung an Architekturforderungen

• Während des Projektes:• Fehlerbehebung und Anpassung der Cartridges• Zu entscheiden: Passe ich die Implementierung an oder suche

ich eine generische Lösung durch Veränderung der Cartridges?

• Nachdem Projekt:• Einfluss der Erfahrungen• Wiederverwendung in neuen Projekten


Folie 38

Andromda - Vorteile

• Vorgefertige Cartridges (Hibernate, Spring) sind Out Of The Box verwendbar

• Müssen in anderen System i. d. R. erst von Hand geschrieben werden

• Anpassbarkeit gegeben

• Schnelles Entwickeln: Modell in Code

• Gerine Fehleranfälligkeit durch generierten Code

• Sicherstellung von Architekturrichtlinien

• Konsistenz zwischen Code und Modellen

Erhöhung der Entwicklungsgeschwindigkeit


Folie 39

Andromda - Nachteile

• Muss mit den vorgefertigten generierten Konzept der 3-Schichten-Architektur leben

• Trennung des Plattformspezifisches Modell nicht gegeben (für Andromda 4 geplant)

• Verknüpfung von mehreren AndroMDA Projekten nur durch Anpassung von Cartridges


Folie 40

Open issues

• Stabilität des Datenmodells

• Auswirkungen auf Datenbank

• Entfremdung des Entwicklers vom Code

• Herstellerabhängigkeit durch Verwendung der Tools

• Modellierung im Team

• Releasemanagement


1. Motivation

2. Build Management

3. MDA


5. Test & Reports

Software Factories

- aktuell: Begriff stark von Microsoft geprägt

- Paradigma der industriellen Softwareentwicklung

- Aufsetzen von Produktlinien

Ziele: Risiko, Kosten, Fehlerraten minimieren

Produkt-/ Projekteinführungszeiten verringern

hohe Qualität beibehalten / erreichen

Software Factories

Prinzipien: - Geschäftsorientierung

- Domänenentwicklung und Applikations- entwicklung

- Trennung von Produkt übergreifenden und Produkt spezifischen Funktionen

- Architektur zentrierte Entwicklung

- Varianten Management

Software Factories

Vorgehen:

Quelle: iX 5/2008. „Softwarewiederverwendun. Produktlinien – die Zukunft der industriellen Softwareentwicklung“

Software Factories

Funktionsplattform Konkrete Variante

Erstellung konkreter Produkte - Bindungszeitpunkte

Software Factories

Erstellung konkreter Produkte - Bindungszeitpunkte

Funktionsplattform Konkrete Variante

Software Factories

Herausforderungen:

- Trennung in Domän- und Applikationscode

- Änderung und Weiterentwicklung

- Dokumentation u. Information bei Änderungen

- Build Management

Teamorganisation:

- Abstimmung über Änderung am Domäncode

- Durchführung von Änderungen


1. Motivation

2. Build Management

3. MDA


5. Test & Reports

Test & Quality

Automatisierte Test

- Junit, Mock-up Test

- Frontend Tests: Selenium

Quality Reports (Force Feedback für Entwickler)

- in der integrierten Entwicklungsumgebung (Metriken, CheckStyle)

- im Build Prozess verankert – Maven Reports

- Nutzung technischen Know Hows

Syntaktische Tests

- CheckStyle, Java Doc Abdeckung

- JDepend

Semantische Tests

- PMD Report

- FindBugs Report

manuelle und automatische Auswertung möglich >> Beispiel

Test & QualityMaven Reports

Frontendtests

• Testen der Funktionalität so nah am Anwendungsfall wie möglich

• Verschiedene Frameworks:

• HttpUnit, HtmlUnit, Selenium

• Vorteile Selenium:

• Testen direkt im Browser• Testen von verschiedenen Browserderivaten mit einer

Codebasis möglich• Testen der Frontendkomponenten (insb. Javascript, Formulare)


Folie 51

Selenium


Folie 52

Praktikanten. Diplomarbeiten.

Aktuelle Arbeiten:

- Tagging Server

- Tag Cloud Navigationen

- Performance Optimierung von Webapplikationen

Aktuelle Themen:

- Produktentwicklung,

- Enterprise 2.0,

- Visualisierung von Informationen,

- Projekt Twitter


Vielen Dank.

Documents

Communardo Software GmbH Lösungen aus Leidenschaft für Netzwerke