BlueJ, birden fazla üniversitenin bir araya gelerek Object Oriented mantığı Java’ya yeni başlayanlara daha çabuk öğretmek amacıyla geliştirilmiştir.

BlueJ Java ile yazıldığı için tüm sistemlerde çalışmaktadır. Tek yapmanız gereken http://www.bluej.org/download/download.html adresinden kendi sisteminize uygun versiyonu indirip çift tıklamak.

Eğer siz de Pardus kullanarak Java’ya başlangıç yapmak istiyorsanız bu dergiler işinize yarayacaktır.

Note: There is a file embedded within this post, please visit this post to download the file.
Note: There is a file embedded within this post, please visit this post to download the file.
Note: There is a file embedded within this post, please visit this post to download the file.

WTP = Web Tools Platform
Eğer update yapıp WTP’yi kurmak istiyorsanız tek yapmanız gereken
http://download.eclipse.org/webtools/updates/
adresini kullanarak Eclipse Update yapmanız.

http://download.eclipse.org/webtools/downloads/
Adresinden kendi makinanıza uygun WTP kurulu Eclipse’leri indirebilirsiniz.

NOT: Aşağıdaki süreçlere devam edebilmeniz için bilgisayarınızda Java’nın ve Tomcat‘in kurulu olması gerekiyor.

1. Eclipse’i çalıştıralım.

2. Yeni bir proje oluşturalım.

3. Dinamik olarak web projesi oluşturmayı seçelim.

4. Burada projemizin ismini JavaciWeb girelim.

5. Target Runtime seçmek için More düğmesine tıklayalım.

6. Tomcat’in kurulu olduğu klasörü seçelim.

7. Eclipse otomatik olarak Tomcat kütüphanelerini tanıyacaktır. Kurulumu tamamlayalım.

8. Bir önceki adımda oluşturduğumuz Tomcat’i seçelim.

9. Burada kullanacağımız teknolojileri seçiyoruz. Biz şimdilik basit bir JSP sayfası yapacağız. Bu nedenle aşağıdaki gibi seçmemiz bizim için yeterli

10. Eğer yaptığınız sitenin Context’ini değiştirmek istiyorsanız buradan değiştirebilirsiniz. Şu an bizim yaptığımız örnek http://localhost:8080/JavaciWeb/ altında çalışacak.

11. Projemizi oluşturduk

12. Şimdi yeni bir Servlet oluşturalım ve bu Servlet ile ekrana basit bir yazı bastıralım

13. Servlet için paket ismini net.javaci, sınıf ismini JavaciServlet olarak yazın

14.URL Mappins kısmını kullanarak bu oluşturduğunuz Servlet’in hangi kalıplarda çağırılacağınız ayarlayabilirsiniz. Biz http://localhost:8080/JavaciWeb/JavaciServlet olarak çağırılmasını istiyoruz.

15.Burada Servletimiz otomatik olarak oluşacaktır

16.doGet methodu içerisine response.getWriter().println(”"); ile istediğiniz bir yazı yazabilirsiniz. Bu yazı direkt olarak web sayfası içerisinde görünecektir.

17.Şimdi web sayfamızı Tomcat içerisinde çalıştırmalıyız. Bunun için proje üzerine sağ tıklayıp gelen menüde Run on Server diyoruz.

18.Tomcat’i seçiyoruz.

19.Oluşturduğumuz projeyi seçiyoruz.

20.Bitirdğimizde sitemiz Eclipse içerisinde açılacaktır yada
http://localhost:8080/JavaciWeb/JavaciServlet adresini kullanarak başka browser ile görebilirsiniz.

Bir sonraki yazıda JSP ve Servlet kullanarak Database CRUD(Create-Read-Update-Delete) işlemlerini yapmayı öğreneceğiz.

Şu an için 3 ana kategoride dersler bulunmakta. Sertifika alınamasa bile bu derslerin öğrenilmesi ve öğrencilere ücretsiz sunulması güzel birşey. Bu 3 kategori için ayrı sertifikalar veriliyor. Mesela Sun SPOT Certification’a sahip olmak için 7 sınavdan da %80 veya üzeri başarıyla geçmek gerekiyor.

Herkese başarılar…

* Java kodunda elemanlar sırayla

paket isimlendirmesi
import edilen sınıflar
Sınıf deklerasyonu
şeklinde olmalıdır.

package net.javaci;
import java.io.*;
public class Test {}

* import komutu recursive çalışmaz
import net.javaci.*; dediğimiz zaman net.javaci.bean.MyBean sınıfını kullanamayacağız.

* Yorumlar(comments) her yerde olabilirler.

* Her bir dosya içerisinde sadece ve sadece bir tane public sınıf olabilir ve bu sınıf ismi dosya ismi ile aynı olmak zorundadır.

MyClass.java dosyası içerisinde

public MyClass {}
 
YourClass {}

kodu yazıyor olabilir. Bu hata vermez.

* Java kaynak dosyasının içerisinde bir public sınıf olmaz zorunda değildir.

* Java kaynak dosyası boş bir dosya da olabilir. Java derleyicisi bunu kabul edecektir.

* Değişken isimleri sadece harf, $ veya _ ile başlayabilirler, sonraki karakterleri harf, $, _ veya sayı olabilir.

* Java’da saklı olan isimler değişken isimleri olarak kullanılamazlar.

* const ve goto isimleri Java’da saklı isimlerdir fakat kullanılmazlar.

* Java’da 8 tane ilkel değişken tipi(primitive data types) vardır.

* Bütün rakamsal değişkenler signed özelliktedir yani pozitif ve negatif değerleri vardır fakat char değişkenleri sadece pozitiftir(unsigned).

* Object değişkenlerinin ilk değerleri null değerindedir.

public class MyClass {
	JFrame frame; // frame değişkeninin default değeri null
}

* Rakamlar Java otomatik olarak int tipinde algılanır. Ondalık sayılar ise double tipinde algılanır.

* Array'ler Java'da birer objedirler. Bu nedenle 5 boyutunda bir String arrayi oluşturursanız aslında 6 tane obje yaratmış olursunuz.
* Array'ler farklı şekilde oluşturulabilirler.
* Array'lerin boyutları sabittir ve değiştirilemez, derleme zamanında bilinmelidir.

int[] i = new int[2] { 5, 10};  // Hatalı
int i[5] = { 1, 2, 3, 4, 5};  // Hatalı
int[] i[] = {{}, new int[] {} }; // Doğru
int i[][] = { {1,2}, new int[2] }; // Doğru
int i[] = { 1, 2, 3, 4, } ; // Doğru

* Array indexleri 0′dan başlar.
* Java Virtual Machine’in bir sınıfı çalıştırabilmesi için main methodunun olması gerekmektedir.

public static void main(String args[])
 
static public void main(String[] s)

* args isminin önemi yoktur, herhangi birşey olabilir. args[0] program çalıştırılırken girilen ilk parametredir ve args.length girilen toplam parametre sayısıdır.
* İlkel değişkenler değer atamalarda değerlerini atarlarken Obje tipindeki değişkenler sadece referanslarını atamaktadır.

	int a = 5; // a=5
	int b = a; // a=5, b=5
	b = 10;	// a=5, b=10
	// Yukarıda görüldüğü üzere a değişkeninin değeri değişmedi
	// Eğer yukarıdaki işlemi Object değişken üzerinde yapmış olsaydık 
	// ilk değişkenin değeri değişirdi.

Java ile ilgili ipuçlarını verdikten sonra Java kurulumunu tamamlayabilirsiniz. 
Windows’da Kurulum

Linux’da Kurulum
Bundan sonra kod yazarak Java’yı öğrenmeye çalışacağız.
]]>
			http://www.javaci.net/2008/05/28/ders-2-javanin-kurallari/feed/
		
		
		
		http://www.javaci.net/2008/05/08/yazilim-muhendisligi-pratikleri-ve-kurumsal-java-teknolojileri/
		http://www.javaci.net/2008/05/08/yazilim-muhendisligi-pratikleri-ve-kurumsal-java-teknolojileri/#comments
		Thu, 08 May 2008 06:11:36 +0000
		ekocaman
		
		

		

		

		

		

		http://www.javaci.net/?p=201
		
			Yazılım geliştirme genel olarak karmaşık ve zaman alan bir süreçtir. Uzun yıllar boyunca bu karmaşık süreci disipline etmek ve belirli bir sistematiğe oturtmak amacıyla değişik yazılım mühendisliği metodları ve pratikleri ortaya konmuştur.

İlk olarak 90’lı yılların ortalarında kullanılmaya başlanan Java programlama dili orta ve büyük ölçekli kurumsal yazılım sistemlerinin geliştirilmesinde dominant bir platform haline gelmiştir. Açık kaynak kod hareketinin ve Java teknolojileri etrafında kümelenen geniş bir geliştirici topluluğunun da etkisi ile kurumsal Java platformu aslında kökleri çok daha eskilere dayanan güncel birtakım yazılım mühendisliği metod ve pratiklerinin, örneğin nesne ve aspect tabanlı programlama, çevik metodlar, XP, yazılım örüntüleri (pattern) gibi, ana uygulama alanına dönüşmüştür.
Zaman içinde bu metod ve pratikler ve kurumsal Java platformu karşılıklı olarak birbirlerinin evrilmelerine ve yaygınlaşmalarına ciddi katkıda bulunmuşlardır. Bu makale boyunca çeşitli yazılım mühendisliği kavram, metod ve pratiklerinin bazılarından, bunların yazılım projelerine uygulanmasından ve Spring, Hibernate, JSF gibi popüler bazı kurumsal Java teknolojilerinden bahsedeceğiz.
Yazılım projelerinde neden bu kadar “spagetti kod” olarak tabir edilen türden kötü, anlaşılması ve bakımı zor kod yazılıyor? Sanırım hemen her projenin geliştirme sürecinde belirli bir noktaya gelindiğinde projenin üyelerinin ağzından şu sözleri durmak mümkündür: “Bu projeyi sıfırdan tekrar yazmamız mümkün olsaydı, bazı şeyler çok daha farklı olurdu!” Burada hemen ünlü Mythical Man Month kitabının yazarı Fred Brooks’un bir sözü aklımıza geliyor: “Üzerinde çalıştığınız işin bir kopyasını çöpe atmayı planınıza ekleyin, çünkü eninde sonunda bunu yapacaksınız.”
Sosyoloji bilimindeki önemli metaforlardan birisi de “Kırık Pencereler Teorisi” dir. Bu teoriye göre, eğer bir binanın kırılan bazı pencereleri hemen tamir edilmez ise, etrafa zarar vermeye meyilli insanların bu binadaki diğer camları da kırma ihtimali daha da fazlalaşır. En sonunda bina bu tür insanların istilasına uğrayabilir, onların yerleşim mekanına dönülebilir, hatta içerisinde yangın vb. diğer hasar verici olayların meydana gelmesi bile söz konusu olabilir. Sonuç olarak başında küçük birkaç pencere kırığına sahip bina zaman içerisinde tamamen metruk bir hale bürünebilir.
Yazılım projelerinde de benzer bir durum söz konusudur. Her proje geliştirilmeye başlandığı ilk andan itibaren ömrünü tüketmeye de başlamıştır. Eğer sistem içerisinde oluşan küçük tasarım ve kod hataları düzeltilmezse bunlar zaman içerisinde bir çığ olup projenin geliştirilmesine ve bakımına ciddi problem teşkil edecek bir noktaya gelecektir. Başlangıç aşamasında çok kolay çözülebilecek bu tür problemler belirli bir noktaya gelindiğinde artık el sürülemez bir hal alacaktır.
Burada karşımıza son yıllarda popüler olan bir yazılım mühendisliği pratiği çıkmaktadır: Refactoring. Refactoring, kodun dışsal davranışını ve çalışma şeklini değiştirmeden iç yapısını düzenlemeyi, iyileştirmeyi hedefler. Bir dizi küçük yapısal dönüşümden oluştur. Bu küçük fakat sürekli yapısal dönüşümler zaman içerisinde ciddi bir yeniden yapılandırma olarak karşımıza çıkar.
Son dönemlerde önem kazanan bir diğer yaklaşım da büyük ön hazırlıklı, tasarımlı yazılım geliştirme faaliyetlerinin yerine aşamalı, azar azar adımlarla yürütülen yazılım geliştirme faaliyetleridir. Yazılım mühendisliği dünyasından dışarıya baktığımızda da, pek çok diğer uzmanlık alanında büyük ön planlamalara dayalı faaliyetlerin, özellikle şehir, bölge planlamacılığı gibi, zaman içinde ciddi problemlerle karşılaştığı görülmüştür. Bu tür büyük ön hazırlıklı, planlamalı çalışmaların başarısızlığındaki temel nedenler bunların katı olması, baştan bazı yanlış kabullere dayanmaları ve güncelliklerini zaman içerisinde yitirmeleridir. Bu tür sistemlerin kullanıcıları zaman içerisinde baştan öngörülemeyen pek çok değişikliğe ihtiyaç duymaktadırlar. Bu nedenle sadece planlama yapmak yeterli değildir.Değişikliklere uyum sağlayabilecek planlamalar yapmak gerekmektedir.
1986’da uzaya fırlatılan Mir Uzay İstasyonu artırımlı geliştirme için çok güzel bir örnektir. Mir Uzay İstasyonu yeniden konfigüre edilebilir ve modüler biçimde büyütülebilir biçimde tasarlanmıştır. Fırlatılış tarihinden itibaren 1996 yılına kadar uzay istasyonuna zamanın ihtiyaçlarına göre pek çok yeni ekleme ve düzenleme yapılmıştır. Uzay istasyonu bu genişleme sürecinde tekrar tekrar ayarlamalara tabi tutulmuştur. Mir Uzay İstasyonu 2001 yılında işlevini yitirdiğinden dolayı yörüngesinden çıkartılmış ve Fiji sahilleri yakınlarında atmosfere girerek parçalanmıştır.
Artırımlı ve büyük planmalara dayalı geliştirme modellerini kıyaslarsak, artırımlı geliştirmenin kademeli onarım ve tamirat kavramı üzerine kurulmasına karşın büyük planlamalı geliştirmenin ise toptan değiştirme üzerine bina edildiği görülmektedir. Büyük ön hazırlığa dayalı çalışmalar ilk seferde mükemmele ulaşılabileceği yanlış inancına kapılmıştır. Artırımlı geliştirme, hataların kaçınılmaz olduğunu, sistemlerin ve kullanıcıların birbirlerine uyumlarının zaman alan ve yavaş bir süreç olduğunu kabullenmektedir.
2001 yılında bir grup yazılım mühendisliği kanaat önderinin bir araya gelmesi ile “Agile Manifesto” adında bir bildiri yayımlanmıştır. Bu bildiri de yazılım projelerinde yaşanan başarısızlıklar ve problemlere çözüm olabilecek birtakım yaklaşımlar vurgulanmıştır. Bu bildiride öne çıkan konuları şöyle sıralayabiliriz:
1. Yazılım projelerindeki en öncelikli konu erken ve sürekli biçimde, çalışır bir yazılım sisteminin ortaya konması ile müşteri tatmininin sağlanmasıdır.

2. Geliştirme sürecinin sonlarında olunsa bile kullanıcı ihtiyaçlarındaki değişklikler hoş karşılanmalıdır.

3. Sık aralıklarla çalışan bir sistem kullanıcıya teslim edilmelidir.

4. Müşteri, analistler ve yazılım geliştiriciler gün boyunca birlikte çalışmalıdırlar.

5. Projeler motive kişilerle geliştirilmelidir.

6. En etkili ve verimli bilgi edinme ve iletişim yöntemi yüz yüze iletişimdir.

7. Projenin asli ilerleme göstergesi çalışan yazılımdır.

8. Teknik mükemmellik ve tasarımda kalite hedefi çevikliği geliştiren unsurlardır.

9. Yapılması gerekmeyen iş miktarını artırmak, yani basitlik esastır.

10. En iyi mimariler ve tasarımlar kendi kendilerine organize olabilen ekipler tarafından ortaya konmaktadır.

11. Ekipler belirli zaman aralıklarında çalışmalarını ve iş yapış şekillerini gözden geçirmeli ve bunları iyileştirmelidirler.
1977 yılında Christopher Alexander isimli bir mimar ortaçağ dönemlerinde yapılmış binaların, yaşam alanlarının neden çekici, insanlara yaşam enerjisi verici ve ortamla uyumlu olduğunu sorgulayan bir eser yayımlamıştır. “A Pattern Language: Towns, Buildings, Construction” isimli eserinde bu sorulara verdiği cevap, bu binaların o dönemlerdeki ve yapıldıkları ortamlardaki bazı yerel düzenlemelere ve kurallara uymak zorunda olmalarına rağmen mimarlarının o ortamda karşılarına çıkan belirli birtakım ihtiyaç ve problemlerde bağımsız karar verebilmeleri, bu kararların, yapıların şeklini, kullanımını o ortama uygun biçimde şekillendirdiğini tespit etmiştir. Christopher Alexander, kitabında daha estetik, çevre ve insan doğası ile uyumlu binalar, yaşam alanları yaratmak için örnek resimler, tasarımlar sunmuş, ancak kesin kararların alınmasını her bir projenin, çalışmanın kendisine bırakmıştır.
1994 yılında, daha sonra “Gang of Four” lakabı ile tanınır olacak dört yazılım mühendisi Christopher Alexander’ın bu kitabından etkilenerek yazılım sistemlerindeki bazı tasarım örüntülerini (pattern) kataloglayan bir çalışma yayımlamışlardır. Tasarım örüntüleri sistematik biçimde isimlendirilmiş ve bunların nesneye dayalı sistemlerde hangi tasarım problemlerine çözüm getirdiği açıklanmıştır. Genel olarak bu çözümler statik ve dinamik olarak sınıf ve nesne modellerinden, bunların açıklamalarından, kod örneklerinden ve bu örüntüler uygulandığı vakit ortaya çıkacak olumlu ve olumsuz sonuçlardan oluşmaktadır.
Tasarım örüntüleri ve refactoring kavramlarının birlikte yorumlanması ile 2000’li yıllarda değişik bir bakış açısı ortaya çıkmıştır. Genel olarak tasarım örüntüleri, kodumuzda varmak istediğimiz nihai aşama olarak düşünülürse, refactoring çalışmaları bu nihai aşamaya ulaşmaya yardım eden ara adımlar olarak görülebilir. Herhangi bir problemin ilk çözüm aşamasından itibaren bir örüntünün doğrudan kullanılmaya çalışılması zaman zaman çözümün gereksiz yere karmaşıklaşmasına neden olmaktadır. “Refactoring to Patterns” yaklaşımı ile basit bir yapıdan yola çıkarak ideal çözüme zaman içinde ihtiyaçlar doğrultusunda kademeli olarak varılmaktadır.
Son yıllarda öne çıkan diğer bir yazılım mühendisliği pratiği ise test güdümlü programlamadır. Aslında test kavramı programcılığın ilk dönemlerinden itibaren geliştiricilerin dağarcığında yer etmiştir. En basitinden bir uygulamanın kabul edeceği girdi ve üreteceği çıktının kodlamadan evvel değerlendirilmesi ve asıl fonksiyonalitenin bundan sonra yazılması bilinen bir çalışma yöntemidir. Test güdümlü programlamada ise ilk önce istenilen fonksiyonaliteyi veya iyileşmeyi sınayan bir test kodu yazılır. Ardından bu testin başarılı biçimde çalışmasını sağlayacak gerçek fonksiyonalite kodu yazılır. Daha sonra ise refactoring ile yazılan kod ve tasarım daha sonraki ihtiyaçları karşılayacak biçimde iyileştirilir. Yazılım projelerinde genellikle yoğun çalışma temposu ve sıkışık teslim süreçlerinde stres katsayısının artması sonucunda ekiplerin ilk terk ettikleri aktivitelerden birisi test kodlarının yazılması ve çalıştırılması olmaktadır. Malesef bu durum “test için zamanımız yok” kısır döngüsü ile sonuçlanmaktadır. Daha az test yazılması ve çalıştırılması geliştiricilerin sistemle ilgili özgüvenlerini azaltacağı için stres katsayısının daha da artmasına sebep olmaktadır. Stres katsayısının artışı da testlerin yazılmasını iyice azaltmaktadır.
Herhangi bir yazılım sisteminin tasarımının iyi veya kötü olup olmadığını hangi kriterlerle değerlendirmeliyiz? Kötü bir tasarım hakkında neler ipucu olabilir? Bu noktada karşımıza birkaç temel kriter çıkmaktadır. Eğer sistem içerisinde herhangi bir modülü değiştirmek zorsa, bu değişiklik sistemin pek çok diğer bölümünü etkiliyorsa bu esnek olmayan bir tasarım demektir. Eğer sistemde yapılan bir değişiklik ilgisiz diğer bölümlerde hatalara sebep oluyorsa bu durumda sistem kırılgan demektir. Sistem içerisinde herhangi bir modülün başka benzer bir problem de de kullanılabileceği gözlenmesine rağmen, bu modülün diğer sistemde kullanılacağı vakit mevcut sistemden kolayca ayrıştırılamaması sistemin yeterince izole olmadığı anlamına gelmektedir. Yazılım geliştirciler herhangi bir problemle kaşılaştıklarında mevcut tasarım içerisinde bu problemi çözen birden fazla yol bulabilirler. Bunlardan bazıları mevcut tasarıma uygun olup, sistemin genel mimarisi ve tasarımı ile çelişmeyen, diğerleri ise “hacking” diye tabir edilen kestirme, günü kurtaran çözümlerdir. Eğer uygun çözümlerin uygulanması, kestirme çözümlere göre çok daha zor ve zaman alıcı ise geliştiricilerde doğal olarak kolay olan yolu tercih edeceklerdir. Bu durum sistemin yeterince olgunlaşmadığına, akışkan olmadığına işarettir.
Peki kaliteli bir nesneye yönelik tasarım ortaya çıkarmak için sınıf, nesne, soyutlama, encapsulation, soya çekim gibi temel nesneye yönelik kavramların bilinmesi ne derecede yeterlidir? Malesef bu kavramlar nesneye yönelik tasarımlarda atomik birimlerdir. Herhangi bir yazılım sisteminin nitelikli bir tasarıma sahip olması için daha üst düzeyde ve geniş kapsamda yapılara ve prensiplere ihtiyaç duyulmaktadır. Nesneye yönelik tasarım prensiplerinden en önde geleni “açık-kapalı” prensibidir. Bu prensibe göre yazılım birimleri, genişlemeye açık, fakat değişikliklere kapalı olmalıdır. Eğer bu birimlerle ilgili yeni birtakım ihtiyaçlar sözkonusu ise bu ihtiyaçlar bu birimlerin genişletilmesi, yeni yapıların ilavesi ile karşılanmalı, mevcut birimlerin, yapıların kendilerinde herhangi bir değişikliğe gidilmemelidir. Diğer bir prensip ise her sınıfın tek bir görevinin olmasıdır. Herhangi bir sınıfta bir değişiklik yapmak için birden fazla değişik sebep ortaya çıkmamalıdır. Bir diğer önemli prensip ise sınıflar arasındaki bağımlılıkların yönü ile ilgilidir. Soyut sınıflar kesinlikle sabit (concrete) sınıflara bağlı olmamalıdır. Soyut sınıflar tasarım olarak genişlemeye açık türden sınıflardır. Bu nedenle bağımlılıkların yönü sabit sınıflardan soyut sınıflara doğru olmalıdır.
Nesneye yönelik programlama belirli ölçüde modüler yazılım sistemleri geliştirmeye yardımcı olmuşlardır. Ancak yazılım sistemlerinde ortaya çıkan bazı fonksiyonalitelerin kendi başlarına tek bir modül içerisinde toparlanması nesneye yönelik programalama ile mümkün olmamaktadır. Bu fonksiyonlar sistem genelinde değişik modüllere yayılmaktadır. Bu noktada ilgiye yönelik (aspect oriented) programlama ortaya çıkmıştır. Kökeni eskilere dayanmasına rağmen ilk olarak Java programa dili üzerine geliştirilen AspectJ programlama dilinin popüler olması ile ilgiye yönelik programlama da güncel yazılım mühendisliği metodları arasında yer almıştır.
Java programlama dili ilk olarak 1994 yılında ortaya çıkmıştır. Önceleri istemci taraflı, görselliği yüksek uygulamaların geliştirilmesinde popüler olmasına rağmen zaman içinde kurumsal, sunucu taraflı sistemlerde de yaygın bir platform olmuştur. Kurumsal Java platformunun gelişimi 1998 yılına kadar uzanmaktadır. İlk dönemlerde katmanlı mimariler, Enterprise Java Beans, RMI, dağıtık transactionlar gibi kavramlar öne çıkmıştır. Kurumsal ölçekli sistemlerin bu ihtiyaçlarını karşılayan, bütün bu kurumsal Java servislerini içlerinde barındırmayı hedefleyen büyük monolitik uygulama sunucuları ortaya çıkmıştır. Zaman içinde klasik kurumsal Java platformunun düştüğü temel problem “her bedene uyacak tek bir elbisenin dikilebileceği” düşüncesidir. Gerçek hayata bakıldığında pek çok proje dağıtık sistemlerin ihtiyaç duyduğu servislere ihtiyaç duymamaktadır. Sıradan veritabanı işlemleri için EJB teknolojisi çok karmaşıktır. Uygulamaları çalıştırmak için mutlaka uygulama sunucularına ihtiyaç duymak özellikle geliştirme ve test süreçlerini olumsuz yönde etkilemektedir. Genel olarak klasik J2EE platformu, spesifikasyonlar tarafından yönlendirilmektedir. Bu yaklaşımın sağladığı başarılar olsa bile, yukarıda bahsedilen noktalarda dezavantajlara da sahiptir. 2000’li yılların başlarında Java geliştircileri kurumsal Java projelerindeki başarısızlıklarından pek çok dersler çıkartmıştır. Bu deneyimler sonucunda monolitik, hantal kurumsal Java platformları yerine, yine spesifikasyonları temel alan ancak daha hafif sıklet ve çevik kurumsal Java platformuna doğru bir dönüşüm söz konusu olmuştur. Bu dönüşümde uygulamaların herhangi bir ortamda çalışabilmesi, sıradan Java sınıflarının kullanılabilmesi, test güdümlü programlamanın etkin biçimde kullanılabilmesi temel hareket noktaları olmuştur.
Bu dönüşüme öncülük eden kurumsal Java çözümlerine kısaca değinirsek, bunlardan en önde geleni Spring Application Framework’tür. Spring’in çıkış noktası J2EE ile yazılım geliştirmeyi çok daha kolay bir hale getirmektir. Daha önce bahsedilen, açık-kapalı, bağımlılıkların sabit sınıflardan soyut sınıflara doğru olması gibi tasarım prensipleri Spring’in temelini oluşturmuştur. Genel olarak Spring çok katmanlı bir kurumsal Java çatısı (framework) sunmaktadır. Bu çatının özünde, uygulamanın nesnelerini oluşturan, nesneler arasındaki ilişkileri yöneten hafif sıklet bir container yer almaktadır. Birbirlerinden kolaylıkla ayrılabilir yazılım bileşenleri kendi başlarına rahatlıkla test edilebilir durumdadır.Spring ilgiye yönelik (aspect oriented) programlama konusunda da kapsamlı bir entegrasyon sunmakta, böylece AOP’u kurumsal Java ugulamalarında rahatlıkla kullanılabilir kılmaktadır.
Diğer bir popüler kurumsal Java çatısı ise nesne ve ilişkisel modeller arasında mapping yapmayı sağlayan Hibernate OR Mapping Framework’tür. Kurumsal uygulamalardaki veriler çoğunlukla ilişkisel veritabanlarında tutulur ve bu verilere SQL aracılığı ile erişilir. Nesneye yönelik geliştirilmiş bir uygulamada nesnelerin o andaki halleri veritabanında saklanıp, daha sonra saklanan bu veriler ile nesneler aynı durumda tekrar yaratılabilir. İlişkisel veritabanları veriyi tabular formda saklamaktadır. Malesef nesne modelini birebir tabular formla eşleştirmek mümkün olmamaktadır. Nesne ve ilişkisel modellerdeki bu uyumsuzluk şu noktalarda yoğunlaşmaktadır.
Nesne modeli ve ilişkisel model farklı ölçekte yapılar üzerine bina edilmişlerdir. İlişkisel modelde iki tablo ile ifade edilen bir veri yapısı, nesne modelinde daha fazla sayıda sınıfın yer aldığı bir modele karşılık gelebilir. Nesne dünyasındaki soyaçekimin (inheritance) ilişkisel modelde tam bir karşılığı yoktur. Bu eksiklik polimorfik sorgularda da karşımıza çıkmaktadır. Nesne dünyasındaki kimlik (identity) kavramı ile ilişkisel modeldeki kimlik kavramı birebir örtüşmemektedir. Nesne modeldeki ilişkilerde yön kavramı söz konusudur, ancak ilişkisel modelde veriler arasındaki ilişkilere bir yön atamak mümkün değildir. Nesneler arası ilişkiler çoka çoklu da olabilirken, ilişkisel modelde sadece bire çoklu ve bire bir ilişkiler desteklenmektedir. Nesneler arasında dolaşırken her bir nesneye birer birer erişilerek hedef bilgiye erişmek sözkonusudur. Bu durumda da ilişkisel modelden verinin o an ihtiyaç duyulduğunda getirilmesi gerekmektedir. Ancak veriye birden fazla erişim maliyeti yüksek bir işlem olduğundan, genellikle veriye erişmeden evvel navigasyon derinliğinin tespit edilmesi söz konusudur. Bu da nesneye dayalı uygulamalarda ya gerektiğinden fazla verinin hafızaya yüklenmesine, ya da veritabanına çok fazla sorgu gönderilmesine neden olmaktadır.
Kurumsal Java platformunda bir diğer katman ise görsel katmandır. Bu katman için ilk dönemlerden itibaren Servlets, JSP gibi teknolojiler ortaya çıkmıştır. Ancak bunlardan daha üst bir seviyede, tekrar kullanılabilir ekran bileşenleri oluşturma, kullanıcı isteklerini ele alma, nesne modeli ekran bileşenleri ile ilişkilendirme, navigasyon yönetimi gibi ihtiyaçlara cevap verecek bir çatıya ihtiyaç duyulmuştur. Zaman içinde bu ihtiyaçlar Struts, Tapestry, Webwork gibi çözümlerle karşılanmıştır. Son dönemde kurumsal Java platformunda görsel katman için Java Server Faces spesifikasyonu bir standart olarak ortaya çıkmıştır. Temelde MVC örüntüsü üzerine kurulu bu teknoloji bahsettiğimiz görsel katman problemlerine çözüm sunmaya çalışmaktadır.
Sonuç olarak, hangi teknoloji, araç vs. tercih edilirse edilsin, bunların büyük yazılım sistemleri geliştirilirken etkin ve verimli biçimde kullanılabilmesi, bu tür yazılım sistemlerinin sağlıklı biçimde geliştirilebilmesi için çok daha temel bir takım yazılım mühendisliği kavram, metod ve pratiklerinin bilinmesi ve yerine göre uygulanması gerekmektedir. Son dönemde güncel hale gelen bazı yazılım mühendisliği metod ve pratiklerinde de kurumsal Java platformu uygun bir geliştirme tezgahı olarak kullanılmıştır. Her iki alan da birbirlerine karşılıklı geri beslemede bulunmuş, bu geri beslemelerin ışığında hem yeni kavram, metod ve pratikler hemde yeni teknoloji ve araçlar ortaya çıkmıştır.
Kenan Sevindik’e bu güzel yazısı için teşekkürler…

Kaynak : http://ksevindik.blogspot.com/2008/05/gncel-yazlm-mhendislii-pratikleri-ve.html
Aşağıdan bu yazı ile ilgili kaynakları PDF halinde indirebilirsiniz.
Note: There is a file embedded within this post, please visit this post to download the file.
Note: There is a file embedded within this post, please visit this post to download the file.
]]>
			http://www.javaci.net/2008/05/08/yazilim-muhendisligi-pratikleri-ve-kurumsal-java-teknolojileri/feed/
		
		
		
		http://www.javaci.net/2008/05/08/java-nedir/
		http://www.javaci.net/2008/05/08/java-nedir/#comments
		Thu, 08 May 2008 06:05:47 +0000
		ekocaman
		
		

		

		

		

		http://www.javaci.net/?p=199
		
			Java Object Oriented bir dildir aynen C++’da olduğu gibi. En önemli farkı ise platform bağımsız olmasıdır. WORA(Write Once and Run Anywhere - Bir kere yaz heryerde çalıştır) prensibini izler. Bunun anlamı Java kodunuzu compile(derleme) ettiğiniz zaman oluşan programı Windows, Linux, Solaris gibi sistemlerde sorunsuz çalıştırabilmenizdir. Eğer programınızı C++’da yazmış olsaydınız kodunuzu her platform için ayrı ayrı derlemeniz gerekecekti.

Java’nın Tarihi

Java James Gosling, Patrick Naughton, Chris Warth, Ed Frank ve Mike Sheridan tarafından 1991 senesinde Sun Microsystems tarafından oluşturulmuştur. Java’nın ilk çalışabilir halinin oluşması için 18 ay geçmiştir. Fakat ilk başta bu dile Oak adı verildi. Patent hakları alınmaya çalışıldığında böyle bir patentin alındığından dolayi 1995 yılında Java adıyla anılmaya başlanmıştır. Oak dili sadece 1992-1995 yılları içerisinde devamlılığını korumuştur. Daha detaylı bilgiye JTPD.org adresinden ulaşabilirsiniz.
Günümüzde Java

Java başlangıcından itibaren çok yol katetmiştir. İlk başlarda daha çok görsel öğeler için ortaya çıkan bu teknoloji sonraları enterprise teknolojilerde kullanılmaya başlanmıştır. Hatta çeşitli embedded ürünlerde Java yaygın olarak kullanılmaktadır.
Java Virtual Machine(JVM)

JVM C dilinde yazılmış küçük bir uygulamadır. Aslında bu küçük uygulama Java programlarının başlangıç noktasıdır. Java kodunuzu derlediğiniz zaman size çıktı olarak BYTE CODE’a dönüştürülmüş dosyayı oluşturacaktır. JVM ise bu Byte Code’u sizin işletim sisteminin anlayacağı makina diline dönüştürür. Oluşturulan Byte Code her işletim sistemi için aynıdır, burada farklı olan ise JVM’dir. Linux için farklı JVM veya Windows için farklı JVM kullanırız. Aşağıdaki resimde bunu daha iyi görebiliriz.

Just In Time Compiler(JIT)

Görüldüğü üzere Java bir çevirim dilidir. Byte Code’u Linux’un, Windows’un veya başka işletim sistemlerinin anlayabileceği biçime çevirir. Bu çevirme işlemini JVM anlık(on the fly) gerçekleştirir. Yani Byte Code’u işlerken sadece ihtiyacı olduğu kısmı makina diline çevirir.
]]>
			http://www.javaci.net/2008/05/08/java-nedir/feed/