Obsah
- Architektury rozsáhlých aplikací v Javě
- Komponentní vs. objektové programování
- Architektury orientované na služby (Service-oriented Architectures - SOA)
- Extreme Programming (XP)
- Správa sestavování - Ant
- Systémy správy verzí
- Maven
- Motivace
- Maven - charakteristika
- Project Object Model (POM)
- Projekt v Mavenu
- Maven repository
- Instalace a nastavení
- Příklad POM (project.xml)
- Příklad POM - pokračování
- Struktura POM obecně
- Proměnné (properties) v POM
- Struktura repository
- Cíle v Mavenu
- Maven Plugins
- Často používané cíle
- Vytvoření projektu
- Reporting
- Rozšíření možností Mavenu
- Skriptování v javovém prostředí - BSF
- Skriptování v javovém prostředí - Groovy
- Řízení a sledování aplikací - protokolování
Na obecných principech OOP není mezi teoretiky a vývojáři (v různých jazycích) až taková shoda, jak by se mohlo zdát:
-
bez zdrojového kódu lze dobře znovupoužít jen kvalitní objektový kód,
-
kód je znovupoužitelný většinou jen na mikroúrovni - jednotlivé třídy
-
k znovupoužití je třeba detailní znalosti celého prostředí programu, rozhraní větších programů bývá většinou komplikované - i proto, že komponenty (objekty) jsou příliš malé, jemné
V zásadě vychází z objektového, ale:
-
komponenty jsou VELKÉ (coarse-grained) objekty zapouzdřující ucelený kus aplikační logiky nebo dat,
-
komponenty jsou nezřídka přístupné i vzdáleně (tj. po síti, často i z jiných platforem/jazyků),
-
komponenty mohou (za podpory middleware) existovat relativně samostatně
-
vazby k ostatním jsou dobře kontrolovatelné a obecně spíše volné
-
jako protokoly, datové formáty atd. jsou přednostně použity standardní, byť třeba ne tak efektivní
Na vývoj software má vliv mnoho faktorů, které se neustále mění (zadání, návrh, technologie, trh, složení týmu apod.). Obecně lze říci, že změna je jedinou konstantou vývoje software. Problémem vývoje softwaru je schopnost úspěšného zvládnutí těchto změn za přijatelné náklady.
Od ostatních metodik se XP odlišuje v následujících vlastnostech:
- Automatizované testování
-
testy jsou tvořeny před samotnou tvorbou zdrojového textu za účelem následného ověření skutečného pokroku ve vývoji softwaru z hlediska jeho požadované funkcionality (testy navrhuje zákazník) a architektury programového modulu (testy navrhuje programátor).
- Verbální komunikace
-
společně s testy a zdrojovým textem slouží ke sdělování systémové struktury a záměru projektu.
- Intuice
-
Postupy, které podporují intuici programátorů a dlouhodobé zájmy projektu (testování, refaktorizace, integrace apod.).
- Komunikace
-
Udržení řádných komunikačních toků ovlivňuje kvalitu jednotlivých postupů XP (testování modulů, párové programování, stanovení metrik apod.).
- Jednoduchost
-
Vývoj software je řízen zásadou, že je lepší udělat jednoduchou věc dnes, s vědomím, že zítra bude možná nutné provést další změnu, spíše než udělat složitější změnu dnes, která nemusí být uživatelem využita. Jednoduchost a komunikace jsou spolu komplementární. Čím více tým komunikuje, tím je mu jasnější co přesně má dělat. Naopak čím je jednodušší systém, tím méně potřebujeme komunikovat.
- Odvaha
-
Členové týmu jsou ochotni experimentovat s vyšším rizikem a ziskem.
- Hraní na výhru
-
představuje soustředění práce týmu na kvalitu vyvíjeného produktu, nikoli na zbytečné alibistické činnosti, kdy tým pracuje „podle předpisů“ (mnoho papírů a porad), aby se tzv. „neprohrálo“.
- Konkrétní experimenty
-
kdy všechna abstraktní rozhodnutí by měla být převedena do řady experimentů, které jsou následně otestovány.
- Práce v souladu s lidskými instinkty
-
a nikoli proti nim představuje práci s krátkodobými zájmy lidí, kteří se rádi učí, vyhrávají, komunikují s ostatními apod.
- Cestování nalehko
-
představuje hodnotné a účinné nástroje vývoje softwaru, které tvoří především testy a zdrojový text.
-
Plánovací hra stanoví šíři zadání následující verze software pomocí kombinace obchodních priorit a technických odhadů.
-
Malá verze představuje rychlé uvedení jednoduchého systému do provozu. Následně jsou uvolňovány malé přírůstky systému ve velmi krátkých cyklech.
-
Metafora pomáhá všem v projektu pochopit základní prvky systému a vztahy mezi nimi na základě jednoduchého přirovnání.
-
Jednoduchý návrh u něhož je nadbytečná složitost ihned odstraněna v okamžiku jejího zjištění z návrhu.
-
Testování představuje činnost programátorů a zákazníků, kdy programátoři testují zdrojový text z hlediska jeho programových vlastností, aby mohli pokračovat v jeho dalším psaní, a kdy uživatelé otestují funkcionalitu modulu, která je úspěšným provedením testu dokončena.
-
Refaktorizace představuje restrukturalizaci systému s cílem zdokonalení jeho nefunkčních kvalit (pružnost, zjednodušení) bez vlivu na jeho chování.
-
Párové programování představuje vývoj zdrojového textu dvěma programátory na jednom počítači.
-
Společné vlastnictví
-
Nepřetržitá integrace - okamžitá integrace dokončeného otestovaného přírůstku do systému.
-
40 hodinový týden plus se nepracuje nikdy přesčas dva týdny za sebou.
-
Zákazník na pracovišti - odpovídá na otázky programátorů při vývoji software.
-
Standardy pro psaní zdrojového textu
- Plánování
-
představuje stanovení termínu programátory společně se zákazníky na základě postupu plánovací hry. Do uvolnění první verze by mělo trvat mezi dvěma až šesti měsíci.
- Smrt
-
představuje stav systému, kdy je software neschopen své existence z důvodu neekonomického rozšíření jeho funkcionality, entropie (tendence k většímu počtu chyb). Zákazníci i manažeři by měli souhlasit s ukončením údržby systému s tím, že se snaží identifikovat příčiny zániku systému.
![[Varování]](http://www.fi.muni.cz/~tomp/slides/images/warning.png)
- commit
- publikuje (odešle, potvrdí) změny z lokálního pracovního prostoru do skladu (repository)
- remove
- maže soubory z lokálního pracovního adresáře, ze skladu se smažou až po "commit"
- add
- přidá nový soubor do pracovního adresáře, do skladu se přidají až po "commit"
- update
- aktualizuje lokální kopii pomocí změn zaregistrovaných ostatními ve skladu
- ckeckout
- vytvoří soukromou lokální kopii požadovaných souborů ze skladu, tyto můžeme lokálně editovat a posléze potvrdit (commit) zpět
Pro sestavování, správu a údržbu SW projektů menšího a středního rozsahu se delší dobu úspěšně využíval systém Ant.
Oproti klasickým nástrojům typu unixového make poskytoval Ant platformově nezávislou možnost popsat i složité postupy sestavení, testování a nasazení výsledků SW projektu.
-
pro každý projekt (i když už jsme podobný řešili) musíme znovu sestavit - poměrně velmi technický - popisovač (build.xml)
-
popisovač je vždy téměř stejný a tudíž
-
neříká nic o obsahu vlastního projektu, je jen o procesu sestavení, nasazení...
-
neumožňoval zachytit metadata nezbytná pro zařazení projektu do širšího kontextu, mezi související projekty, atd.
-
nástroj řízení SW projektů
-
open-source, součást skupiny nástrojů kolem Apache
-
dostupný a popsaný na http://maven.apache.org
-
momentálně (září 2004) již jako použitelná, ostrá, verze 1.0
-
projekt řízený Mavenem je popsán tzv. POM (Project Object Model), obvykle project.xml
-
POM nepopisuje postup sestavení, ale obsah projektu, jeho název, autora, umístění, licenci...
-
postup sestavení je "zadrátován" v Mavenu, protože je pro většinu projektů stejný
-
programátor není frustrován opakováním psaní popisovačů build.xml, návrhem adresářové struktury...
-
nicméně, Maven je založen na Ant, jeho build.xml popisovače lze znovupoužít
-
základním organizačním nástrojem pro správu vytvořených (nebo používaných) artefaktů je repository
-
artefakt, tj. výstup projektu, se může v repository vyskytovat ve více verzích
-
repository je:
- vzdálená (remote)
-
slouží k centralizovanému umisťování jak vytvořených, tak používaných artefaktů
dosažitelná pro čtení pomocí HTTP: je to de-facto běžné webové místo
- lokální (local)
-
slouží k ozrcadlení používaných artefaktů ze vzdálené repository
typicky zvlášt každému uživateli - v jeho domovském adresáři
slouží též k vystavení vytvořených artefaktů "pro vlastní potřebu"
-
Maven má nástroje (pluginy) pro vystavování artefaktů do repository
Maven lze stáhnout z http://maven.apache.org v binární i zdrojové distribuci.
Binární distribuce je buďto čistě "java-based" nebo ve formě windowsového .exe.
Pak se nainstaluje do Program Files
Po instalace je třeba nastavit proměnnou prostředí MAVEN_HOME na adresář, kam se nainstaloval.
Příklad minimálního popisovače project.xml:
<project>
<pomVersion>3</pomVersion><!-- verze POM - zatím vždy 3 -->
<id>RunningCalculator</id><!-- jednoznačné id projektu -->
<name>RunningCalculator</name><!-- (krátké) jméno/nemusí být jednoznačné -->
<currentVersion>0.1</currentVersion><!-- momentální verze -->
<organization><!-- organizace vytvářející projekt -->
<name>Object Computing, Inc.</name>
</organization>
<inceptionYear>2004</inceptionYear><!-- rok zahájení projektu -->
<shortDescription>calculates running pace</shortDescription><!-- stručný popis -->
<developers/>
Příklad minimálního popisovače project.xml:
<dependencies><!-- závislosti -->
<dependency><!-- závislost -->
<groupId>junit</groupId><!-- skupina artefaktu -->
<artifactId>junit</artifactId><!-- označení artefaktu -->
<version>3.8.1</version><!-- verze artefaktu -->
</dependency>
</dependencies>
<build><!-- odkud se co a jak sestavuje... -->
<sourceDirectory>src/java</sourceDirectory><!-- adresář zdrojů -->
<unitTestSourceDirectory>src/test</unitTestSourceDirectory><!-- adresář zdrojů testů -->
<unitTest><!-- které soubory jsou třídy testů -->
<includes>
<include>**/*Test.java</include>
</includes>
</unitTest>
</build>
</project>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="MAVEN_HOME/maven-project.xsd">
<pomVersion>3</pomVersion>
<id>unique-project-id</id>
<name>project-name</name>
<groupId>repository-directory-name</groupId>
<currentVersion>version</currentVersion>
<!-- Management Section -->
<!-- Dependency Section -->
<!-- Build Section -->
<!-- Reports Section -->
</project>
-
Jsou podobně jako u Antu definovatelné a využitelné (odkazovatelné) v popisovači, zde project.xml.
-
Vyskytne-li se zavedení určité vlastnosti (property) vícekrát, uplatní se poslední.
-
Vlastnosti jsou vyhledávány v pořadí:
-
project.properties
-
build.properties
-
${user.home}/build.properties
-
vlastnosti specifikované na příkazové řádce -Dkey=value
-
-
Na vlastnost se lze odvolat pomocí ${property-name}
Týká se jak vzdálené, tak lokální repository.
Obecně je relativní cesta v rámci repository k hledanému artefaktu: repository/resource-directory/jars/jar-file
Cíle (goals) v Mavenu odpovídají zhruba antovým cílům (target).
Spouštění Mavenu vlastně odpovídá příkazu k dosažení cíle ("attaining the goal"):
Zásuvné moduly (plugins) obsahují předdefinované cíle (goals) a jsou taktéž uloženy v repository.
Většinou jsou jednoúčelové, slouží/směřují k jednomu typu artefaktu, např.:
-
vytvořit prázdný adresář pro vytvářený projekt
-
spustit maven genapp (Zeptá se na id projektu, jeho jméno a hlavní balík. V něm předgeneruje jednu třídu.)
-
tím se vytvoří následující soubory:
-
project.xml, project.properties
-
src/conf/app.properties
-
src/java/package-dirs/App.java
-
src/test/package-dirs/AbstractTestCase.java
-
src/test/package-dirs/AppTest.java
-
src/test/package-dirs/NaughtyTest.java
-
Generování reportů (zpráv) je jednou se základních funkcí Mavenu.
Které reporty se generují, je regulováno v project.xml v sekci reports:
<reports> <report>maven-checkstyle-plugin</report> <report>maven-javadoc-plugin</report> <report>maven-junit-report-plugin</report> </reports>
Cílů (goals) je sice v Mavenu řada, ale přesto nemusejí stačit anebo je třeba měnit jejich implicitní chování.
Potom lze před nebo po určitý cíl připojit další cíl pomocí preGoal a postGoal.
Ty se specifikují buďto v nebo.
Zcela nové cíle je možné napsat ve skriptovacím jazyku jelly (s XML syntaxí).
Co odlišuje skriptování od "ostatních" pg. jazyků?
- Rychlý vývoj, přímočarý životní cyklus SW: napiš - spusť (- potom odlaď)
- Obvyklé dynamicky (až za běhu) typovaný jazyk, nevyžaduje deklarace proměnných, definice tříd...
- Jazyk je často kombinovatelný s běžnými pg. jazyky - lze volat jejich metody, používat knihovny...
- Prostá, obvykle intuitivní, syntaxe
- Mnohdy jde de-facto o syntaktický klon "plného" jazyka - mj. aby se snáze učilo
- Obvykle malé nároky na udržovatelnost, dokumentovatelnost, rozšiřitelnost vzniklých SW výtvorů
- Jednoduché věci jdou napsat jednoduše, složité složitě, nepěkně nebo pořádně vůbec...
Proč je potřeba skriptovat silná právě dnes, když je tolik dokonalých programovacích jazyků s rychlými překladači?
![[Poznámka]](http://www.fi.muni.cz/~tomp/slides/images/note.png)
Bean Scripting Framework (BSF) je projektem jakarta.apache.org, původně však vytvořený v IBM T.J.Watson Laboratories (jako produkt "alphaWorks").
- BSF (software i další info) lze získat na http://jakarta.apache.org/bsf.
- Vynikající články o BSF jsou k dispozici přímo na http://jakarta.apache.org/bsf/resources.html.
- úvodní prezentace V. Orlikowského.
- http://www.javaworld.com/javaworld/jw-03-2000/jw-03-beans.html
- Již delší dobu pro Javu existuje rámec BSF podporovaný řadou skriptovacích jazyků.
- Autorům Groovy se však většina z nich zdála syntakticky "těžko stravitelná" pro javového programátora, který "málo, ale občas přece" potřebuje skriptovat.
- Groovy je tedy vytvořet v Javě a na míru pro javové programátory.
- Nabízí velmi příjemnou a intuitivní syntaxi, hezkou konzolu pro spouštění atd.
- Skript se překládá do javového bajtkódu, je tedy na běhové úrovni dobře interoperabilní s Javou.
- Groovy najdeme na http://groovy.codehaus.org.
- Plná, tj. zdrojová i binární distribuce má vč. dokumentace a příkladů přes 56 MB!!!
- Je zároveň hezkou ukázkou netriviální projektu řízeného Mavenem.
Definice mapy (asociativního pole) a přístup k prvku:
map = ["name":"Gromit", "likes":"cheese", "id":1234] assert map['name'] == "Gromit"
Řízení toku pomocí switch s velmi bohatými možnostmi:
x = 1.23
result = ""
switch (x) {
case "foo":
result = "found foo"
// lets fall through
case "bar":
result += "bar"
case [4, 5, 6, 'inList']:
result = "list"
break
case 12..30:
result = "range"
break
case Integer:
result = "integer"
break
case Number:
result = "number"
break default:
result = "default"
}
assert result == "number"
Existuje několik "standardních" protokolovacích API:
Obě řešení jsou srovnatelná, log4j je o něco elegantnější a propracovanější. Nejlépe (pokud to stačí) je použít zastřešujícího API: