Yönelimli Yazılım Gelitirme çin Süreç Modeli Vedat BAYAR Havelsan A.. Eskiehir yolu 7.km ANKARA vbayar@havelsan.com.tr Özet Yönelimli Yazılım Mühendislii (BYYM) yaklaımı için bir süreç modeli gelitirildi. Gelitirilen bu süreç modeli, bileen tabanlı yazılım gelitirme için bir yol gösterici nitelii taımaktadır. Süreç, sistem spesifikasyonlarının ayrıtırımı ile balayıp, ayrıtırılan sistemin yazılım bileenlerine dönütürülmesi ile devam edip, bileenlerin entegre edilip hedeflenen sistemin oluturulması ile sonuçlanmaktadır. Abstract A process model is developed for Component Oriented Software Engineering (COSE) paradigm. The model presents a guide for component-based software development. The process starts with the decomposition of a system specification and continues with represention of the decomposed system parts with software components and ends up with the system by the integration of these software components. 1. Giri Yazılım sistemlerinin zaman içerisinde daha büyük ve daha kompleks hale gelmeleri ile yazılım sistemlerinin gelitirilmesinde yazılım bileen teknolojisinin önemi de artmıtır. Yazılım bileenlerinin neredeyse yazılım gelitirme sürecinin baından beri biliniyor olmasına ramen pratik kullanımı ve geliimi zaman içerisinde olmutur [1]. Yazılım teknolojisinin balangıcından itibaren, yazılım gelitiren kurulular, tasarım tekniklerini iyiletirerek, daha uygun süreç modelleri ve metodolojileri ve mevcut sistemlerin kullanılabilir parçacıklarını kullanarak, yazılım gelitirme süreçlerini iyiletirme çabası içerisinde olmulardır. Günümüzde, yazılım sistemlerinin, mevcut yazılım bileenlerinin uygun bir yazılım mühendislii yaklaımı ile entegre edilerek gelitirilmesi ihtiyacı, sıfırdan gelitirilmesine göre kaçınılmaz bir hal almıtır.yazılımın yeniden kullanımı (reusability) sadece yazılım gelitirme sürecini hızlandırmakla kalmaz aynı zamanda yazılım kalitesini ve üretkenlii de artırır [2]. Fakat yazılımın yeniden kullanımı çok kolay deildir. Yeniden kullanılabilecek bileenlerin çok iyi tanımlanmı ve baımsız bir ekilde yaygınlatırılabilir (deploy) olmaları gerekir. Yazılım bileenleri ile ilgili çok farklı tanımlamalar mevcuttur, fakat tüm bu tanımlamaların üzerinde mutabakata vardıı nokta, yazılım bileenlerinin yeniden kullanılabilir olması noktasıdır. Yazılım bileeni, bir standarda uygun, yeniden kullanılabilir ve tanımlı bir mimari çerçevesinde gelitirilmi, ilevsel ve deiitirilebilir bir
yazılım parçasıdır. Önceden gelitirilmi, test edilmi ve onaylanmı yazılım bileenlerinin yazılım gelitirmede kullanılması gelitirilecek sistemin kalitesini ve güvenirliliini artırır. tabanlı yazılım gelitirme, gelitirme sürecini, sıfırdan kod yazma ileminden bileenlerin entegrasyonu ilemine dönütürmütür. Hedeflenen sistemin spesifikasyonu belirlenir, bu spesifikasyonlara göre sistem alt bileenlerine ayrıtırılır. Bu ilemden sonra uygun bileenlerin aratırılması ve uyarlanması ilemi gerçekletirilir. htiyaç duyulan bileenlerin salanmasından sonra bileenler entegre edilerek hedeflenen sistem oluturulur [3]. Yapısal (structural) bir bileen yönelimli yazılım gelitirme yapabilmek için bir süreç modeli gelitirildi. Bu süreç modeli BYYM Süreç Modeli olarak isimlendirildi [4]. BYYM Süreç Modeli adım-adım bir sistemin hiyerarik olarak nasıl yapıtalarına ayrıtırılacaını, bu yapıtalarının bileenlere nasıl denk düürüleceini ve bu bileenlerin nasıl entegre edilip hedeflenen sistemin oluturulacaını tanımlar. 2. Yönelimli Yazılım Gelitirme Süreç Modeli Geleneksel metodolojiler büyük oranda sistemin fonksiyonel ayrıtırımı üzerinde younlamılardır. Nesne yönelimli metodolojilerde ise sistemin veri boyutu ön plana çıkar. Öte yandan bileen yönelimli yazılım mühendislii, BYYM, yapı-yönelimli bir metodolojiyi benimserdir. BYYM Süreç Modeli, sistemin yapı talarını ortaya koymak için sistemin yukarıdanaaı bir ayrıtırımı ile balar. Süreç ilerledikçe modüller arasındaki arayüzler tanımlanmı olur. Modüllerin bileenlerle eletirilebilecei düünüldüü bir sevieyede geçici bir aaıdan-yukarıya yaklaıma geçilir. BYYM süreç modeli dört ana aamadan ve sistem test evresinden oluur: Sistem spesifikasyonu, Sistem ayrıtırımı, spesifikasyonu, ve Entegrasyon. BYYM süreç modelinin süreç akıı ekil 1 de gösterildii gibidir. Oval dikdörtgenler belirtilen evredeki üst seviye süreçleri gösterir. Ok yönleri süreç ve veri akıı yönlerini gösterir. Süreçlere kesikli ok çizgileri ile ilitirilmi dokümanlar bilgi akıını gösterir. Ekenar dörtgenler karar durumlarını gösterir. Süreç modelinde kullanılan ve oluturulan dokümanların özet tanımları aaıdaki gibidir: Problem dokümanı: Hedeflenen sistemin tanımını içerir, müteri tarafından salanır. Alan Bilgisi: Alan bilgisini içeren iyi hazırlanmı bir doküman ve/veya alan uzmanları tarafından salanan alan bilgisi. Üst-Seviye fonksiyonel gereksinimler dokümanı: Metin veya use-case model olarak sistemin fonksiyonel gereksinimleri dokümanı. Fonksiyonel olmayan gereksinimler dokümanı: Fonksiyonel olmayan fakat sistemin çalımasını etkileyen kısıtlar; güvenlik, performans, vb. Mevcut bileen spesifikasyonları: ler ve bileenlerin arayüzleri ile ilgi dokümante edilmi bilgiler. Detaylı fonksiyonel gereksinimler (Soyut Spesifikasyonları): Sistem ayrıtırımı safhasında oluturulan gereksinimler dokümanı. Spesifikasyonları: Tanımlanmı bileen arayüzleri dokümanı. ler arasındaki balantı mekanizmalarını açıklar. Entegrasyon Mimarisi: lerin içinde hayat bulacaı birbirleri ile iletiim kuracaı bileen mimarisi spesifikasyonu.
Test Senaryoları: Sistem fonksiyonlarının faaliyet serileri bazında açıklandıı doküman. BYYM Süreç Modeli sistem spesifikasyonu fazı ile balar. Gelitirilecek olan sistem belirlenir ve anlaılır, sistemin üst seviye gereksinimleri belirlenir, sistemin gerçekletiriminde kullanılabilecek bileenler için ön aratırma yapılır. Bu faza problem ve alan bilgisi bilgileri girdi olur. Sistemin üst seviye fonksiyonel ve fonksiyonel olmayan gereksinimleri ve alan ile ilgili mevcut bileen spesifikasyonları dokümanları bu fazın çıktılarını oluturur. Problem Problemin Anlaılması ve Sınırlarının Belirlenmesi Üst-Seviye Fonksiyonel Gereksinimler Alan Bilgisi Üst Seviye Sistem Gereksinimlerinin Belirlenmesi Mevcut ler için Ön Aratırma Fonksiyonel Olmayan Gereksinimler Requirements Mevcut Spesifikasyonları Sistem Sistemin Ayrıtırılması Detaylı Foksiyonel Gereksinimler(Soyut Spes.) Arayüz Sistem Ayrıtırımı Mevcut ler için Aratırma [Yok] [Var] [Evet] in ncelenmesi Ayrıtırmaya Devam mı? [Hayır] [Hayır] Uygun mu? [Evet] Gelitirimi lerin Entegrasyonu Entegrasyon Mimarisi Entegrasyon Test Senaryoları Sistem Testi Test Hedeflenen Sistem ekil 1. Süreç akıı
Sistemin analizi ve alt parçalarına ayrıtırımı, sistem ayrıtırımı fazında gerçekletirilir. Bu fazda fonksiyonel gereksinimler detaylandırılır ve gerekli bileenler ve bu bileenlerin spesifikasyonları ortaya konur. Sistemi gerçekleyecek bileenlerin belirlenmesi ve gelitirilmesi ilemleri bileen spesifikasyonları fazında belirlenir. Sistem ayrıtırımı ve bileen spesifikasyonu fazları birbirinden tamamıyla ayrık fazlar deildirler. Sistem ayrıtırımı belli bir olgunlua geldiinde bileen spesifikasyonu fazı balar. spesifikasyonu fazı, mevcut bileenlerin aratırılması ile balar ve bulunan bileenlerin deerlendirilmesi ile devam eder. Eer ayrıtırım seviyesi, gerekli bileenlerin bulunması ve deerlendirilmesi için yeterli deil ise daha anlamlı bir ayrıtırım olmayacaı görülünceye kadar sistem ayrıtırılmaya devam edilir. Sistem ayrıtırımı ve bileen spesifikasyonu fazlarının çıktıları, bileenler ve bu bileenlerin spesifikasyonlarıdır. BYYM Süreç Modeli, bileenlerin entegrasyonu ve tüm sistemin test edilmesi ile devam eder. Entegrasyon mimari dokümanı entegrasyon fazına girdi tekil eder. Test senaryoları da test fazına girdi olurlar. 2.1 Sistem Yazılım gelitirme perspektifi altında, gelitirilecek sistemin belirlendii ve ortaya konduu aama sistem spesifikasyonu aamasıdır. Bu aama sonucunda ortaya çıkan çıktılar müteri ile sistemi gelitirecek üretici arasında kontrat tekil eder. Bu fazda aaıdaki faaliyetler gerkeletirilir: Problemin, yazılım konseptine uygun olarak analiz edilerek modellenmesi, Hedeflenen sistemin sınırlarının ve içeriinin belirlenmesi, Üst-seviye sistem fonkiyonalitesinin belirlenmesi, Gerçekletirilecek sistemle ilgili olabilecek mevcut aday bileenler için ön aratırmanın yapılması. Bu fazın en önemli zorluu problemden analiz modele geçitir. Yazılım gelitiriciler ile müteri arasındaki yanlı anlaılmalar kaçınılmazdır. Müterilerin büyük bir bölümü yazılım konseptlerine yabancı oldukları için ihtiyaçlarını tam olarak ifade edemeyebilirler ya da yazılım gelitiricilerin problemi yanlı yorumlamalarına neden olabilirler. Bu yanlı anlaılmaları ortadan kaldıracak ya da en aza indirecek bir yönteme ihitiyaç vardır. Use case modelleme bu amaç için kullanılabilecek en etkili ve en basit yöntem olarak görülmektedir [5]. Basit ve etkili bir yöntem olduu için gelitiriciler ile müterinin ortak bir dili konumasına olanak salar. Sistemin genel bir görünümü, sistem sınırları ve kullanıcıları, müteri ile birlikte çalıılarak use case modelleme yöntemi ile modellenir. Üst-seviye sistem fonksiyonaliteleri, use case ve sistem kullanıcıları (actor) ile ifade edilir. Fonksiyonel olmayan gereksinimler, use case modellerine ek olarak belirlenir ve dokümante edilir. Sistemin üst-seviye gereksinimleri ve sınırları belirlendikten sonra aday bileenlerin bulunması için ön bir aratırma yapılır. lerin etkili kullanımı için bileenlerin bulunması, onları gelitirmekten daha kolay olmalıdır. Uygun bileenlerin bulunması demek bire bir tüm ihtiyaçları karılayacak bileenlerin bulunması anlamına gelmemektedir. Sistem detaylı bir ekilde analiz edilmedii için bu aamada aday bileenlerin belirlenmesi yeterli olacaktır. Yapılan bu ön aratırma, gelitiricilerin alan ile ilgili bileenler hakkında fikir sahibi olmalarını salayacaktır. Etkili bir bileen yönelimli gelitirim için bir bileen kütüphanesinin olması faydalı olur. Aday bileenlerin seçiminde göz önünde bulundurulacak kriter, bileenlerin kavramsal olarak
sistemden beklenen servisleri salayabilecek nitelikte olmalarıdır. Bu çalımanın sonucunda aday bileenler ve bu bileenlerin sepsifikasyonları belirlenmi ve anlaılmı olur. 2.2 Sistem Ayrıtırımı Sistemin ayrıtırımı fazı, alan bilgisine sahip uzmanlar ile gelitiricilerin ortak çalıması ile gerçekletirilir. Alan uzmanları, gelitirilecek sistemin alan bilgisine sahip insanlardır. Bu insanlar gelitiricilere alan bilgilerini aktararak, gelitiricilerin sistemi alt parçalara ayrıtırmalarında ve detaylı gereksinimleri ortaya koymalarında yardımcı olurlar. Sistem ayrıtırımı safhasının amacı, sistemi yeniden kullanılabilir bileenlere denk düecek sekilde daha atomik alt parçacıklara bölmektir. Bu fazda aaıdaki faaliyetler gerçekletirilir: Sistemin paketlere, fonksiyonlara ve veri soyutlamalarına ayrıtırılması 1, Paketler arasındaki arayüzlerin belirlenmesi, Paket elemanlarının birbirleri ile olan iletiimlerinin belirlenmesi, Ayrıtırımın alan ile ilgili senaryolara göre deerlendirilmesi. Sistem ayrıtırım fazında, sistem, soyut bir paket olarak ele alınır ve ayrıtırım bu paketin alt paketlere bölünmesi ile balar. Ayrıtırım yukarıdan-aaı yapılır. Sistem, kabiliyetlerine göre üstseviye paketlere bölünür. Sistemin ana kabiliyetleri soyut olarak bu üst-seviye paketlerle ifade edilir. Üst-seviye sistem kabiliyetleri, fonksiyonlara veya alt seviye paketlere bölünür. Bu ilem anlamlı bir bölünmenin yapılamayacaı seviyeye kadar devam eder. ekil 2, personel, stok, satı, müteriler ve muhasebeden olumu küçük ölçekli bir iin ayrıtırımını göstermektedir. E-Satı, satı ilemi altında olup Depo-Satıın özellemi bir halidir. Sistem spesifikasyonu aamasında, modellenen use caseler paketlere dönütürülür. Her bir use case bir veya birden fazla pakete karı gelebilir. Paketler arasındaki arayüzler, use caselerin birbirleri ile olan etkileimlerinden çıkarılabilir. Paketler arasındaki arayüzlerin hepsi, use case modellerinde açıkça görülmeyebilir, bu tür arayüzler bu aamada tanımlanabilir. Arayüzler paketlerin birbirleri ile iletiimlerinde uyulması gereken kontratları belirtirler. Her bir paket bu kontrata uymak durumundadır. Bu ekilde herbir paket paralel bir ekilde daha alt paket, fonksiyon veya veri soyutlamalarına ayrıtırılır. Her bir ayrıtırım seviyesinden sonra paketler arasındaki arayüzler gözden geçirilir ve mutabakata varılır. Ticaret Personnel Stok Satı Müteriler Muhasebe Depo-Satı E-Satı ekil 2. Sistemin ana kabiliyetleri 1 Makale genelinde kullanılan kavram ve sembollerin detaylı açıklamaları 4 nolu kaynakçada verilmitir.
Paket detayları fonksiyon ve veri soyutlamaları ile ifade edilir. Balangıçta her bir use case fonksiyon soyutlamalarına denk düürülür. Use case diagramlarındaki notlar ve ek bilgiler içeriklerine göre veri veya fonksiyon soyutlamalarına denk gelebilir. Veri yapıları gibi ek veri ve fonksiyon soyutlamaları tanımlanabilir. Paketlerin fonksiyon ve veri soyutlamalarına ayrıtırılması ile paketin iç ileyii ve arayüzleri açıkça anlaılır duruma getirilir. ekil 3, Stok paketinin fonksiyon ve veri soyutlamalarına ayrıtırımını göstermektedir. S to k M a nue l ile m le r Stokta n dü m e Stok ta blosu M a nue l D üm e E -Sa tı D üm e ekil 3. Stok paketinin fonksiyon ve veri elemanlarına ayrıtırımı. Fonksiyon ayrıtırmaları sistem seviyesi fonksiyonaliteye denk dümektedir. Eer bir soyutlama paket olacak kadar kompleks bir soyutlama deil ise fonksiyon soyutlaması ile gösterilir. Fonksiyonlar, veri eriimini de kullanarak veri eriiminden fazlasını yerine getirirler. ekil 3 te görüldüü gibi fonksiyon soyutlamaları alt fonksiyon soyutlamalarına sahip olabilirler. Veri eriim metodları veri soyutlamalarına dahil edilirler. Kendilerine has metodları ve alt veri soyutlamalarına sahip olabilirler. Eer bir soyutlama veri veya depolama ile ilgili ise onun veri soyutlaması ile ifade edilmesi anlamlıdır. Ayrıtırım ilemi tamamlanınca, parça-bütün hiyerarisine göre bir gözden geçirme ilemi yapılır. Paketler arasındaki mesaj tarfiini azaltmak ve paketlerin birbirlerine olan baımlılıklarını en aza indirmek için eer gerekiyorsa bazı foksiyonlar ilgili paketlere taınabilir. Ortak yeni fonksiyon ve veri soyutlamaları yaratılabilir. Daha sonra mesajlama mekanizması, belirlenmi senaryolara göre gözden geçirilir. Bu senaryolar sistemin ileyiini gösterir. Paketler arası iletiimi baz alan senaryolar paketlerin arayüzlerinin oturmasını salar. Paketin iç ileyiine yönelik senaryolar ise paketin ayrıtırımının ve paket elemanları arasındaki ilikilerin deerlendirilmesinde kullanılır. Bu senaryolar UML in akı modelleri kullanılarak görsel olarak modellenebilir. 2.3 Ayrıtırılmı sistemin gereksinimlerine uygun bileen aratırması, bileenlerin modifikasyonu ve gelitirilmesi ilemleri bu fazda yapılır. Mantıksal olarak ayrıtırılmı sistem fiziksel elemanlara yani bileenlere bu aamada denk düürülür. Bu fazda aaıdaki faaliyetler gerçekletirilir: Ayrıtırılmı sistemin ihtiyaçlarına göre, bileen aratırmasının yapılması, Bulunan bileenlerin eer gerekiyorsa deitirilmesi, stenen özeliklerdeki bileen bulunamadıysa bilenin gelitirilmesi.
aratırmasına geçilmeden önce ihtiyaç duyulacak bileenlerin arayüzlerinin ve spesifikasyonlarının ayrıtırılan sistemin ihtiyaçlarına göre belirlenmesi gerekir. Her bir paket, fonksiyon ve veri soyutlamaları aday bileenlerdir. Bu soyutlamalar arasındaki ilikiler bileenlerin arayüzlerini belirler. Her bir paketin bir bileen olarak ele alınması iyi bir balangıç olabilir. Bir bileen birden fazla bileeni içerebilir. Eer fonksiyon ve veri soyutlamaları bileenlerin karakteristik özelliklerini taıyorsa bunlarında paket içerisinde bileen olarak ele alınmaları anlamlıdır. Soyut bir öeden fiziksel bileenlere geçi için kesin adımlar tanımlayamıyoruz. Bu yetenek tasarımcıların deneyim ve etkinliine balı olarak geliecektir. Genelde tasarım fazla yönlendirilemeyen insana balı bir süreçtir. CORBA bileen modeli yazılım bileen mantıını en iyi ekilde ifade eden bir model olup bileenlerin oluturulmasında bu model referans alınacaktır [6]. CORBA bileen modelinde bileenin görsel olarak nasıl ifade edildii ekil 4 te gösterilmitir 2. Günümüzde web servisleri popüler olarak kullanılmaktadır. Soyut düzeyde bu tür servisler birer bileen olarak deerlendirildiinde önerdiimiz metodoloji açısından önemli bir fark olumamaktadır. Arayüzü Salanan servisler (Facets) Kullanılan Olaylar (Event sinks) Kullanılan servisler (Receptacles) Oluturulan Olaylar (Event sources) Deikenler (Attributes) ekil 4. CORBA Modeli (CORBA Component Model- CCM) olmaları anlamlı olmayan fonksiyon ve veri soyutlamaları oldukları gibi kalabilirler. Bu tür fonksiyonlar, bileenlerin iç ileyiini olutururlar, veri soyutlamaları ise veri yapılarını temsil edecek ekilde kalırlar. ekil 5, Stok paketinin bileen ve bileen arayüzlerini gösterir. Bu ilemler tamamlandıında taslak bir bileen spesifikasyonu oluturulur ve mevcut bileenlerin aratırılması yapılır. Bulunan bileenler detaylı bir ekilde deerlendirilir. Gerekiyorsa bulunan bileenler deitirilir fakat ideal olanı bileenleri deitirmeden kullanabilmektir. Mevcut bileenlerin deitirilmesi ilemi deiik formasyonlar da yapılabilir: Yeni fonksiyonalite eklemek: gelitirilirken sonradan ortaya çıkmı gereksinimleri yerine getirmiyor olabilir veya bu gereksinimleri gözardı etmi olabilir. Eksik olan bu fonksiyonalitelerin eklenmesi bileeni yeniden yazmaktan daha anlamlı olabilir. Fonksiyonalitenin çıkarılması: ler gerekenden daha fazla fonksiyonalite içeriyor olabilir. Gerekmeyen bu tür fonksiyonalitelerin çıkarılması etkinlik için gerekli olabilir. Genelletirme: ler istenildii ölçüde genel olmayabilir. Bu durumda bileenin daha genel olacak ekilde deitirilmesi gerekebilir. 2 CORBA bileen modeli ile ilgili detaylı bilgi 6 nolu kaynakçada verilmitir.
aratırması ve bulunan bileenlerin deiitirilmesi sonucunda hala karılanamayan sistem fonksiyonaliteleri varsa bu fonksiyonaliteleri yerine getirecek bileenlerin belirlenmesi ve sıfırdan gelitirilmesi ilemi yerine getirilir. StokArayüzü ManuelStokHareketleriArayüzü EStokHareketleriArayüzü Stok StoktanDüümOlayı Stok ekil 5. Stok bileeni ve arayüzleri 2.4 Entegrasyon Bu fazda, sistemi gerçekleyen bileenlerin entegre edilme ilemi yerine getirilir. lerin entegrasyonu seçilen bileen mimarisine göre yapılır. mimarisi, servis salayıcılar ile istemciler arasındaki iletiimi birbirlerinin detaylarını bilmek durumunda kalmadan salar. Nesneyönelimli modellemelerde geni çapta kullanılan UML akı modelleri bileen yönelimli modellemeye de uyarlanabilir. Bu modellerdeki nesneler bileenlerle ve nesne metod çaırmaları da bileen arayüzleriyle deitirilerek, bileenlerin entegrasyonu ileminde kullanılabilir. 3. Sistem Testi ler test edilip onaylandıkları için entegrasyonun ve sistemin bütün olarak testi bu aamada yapılır. Bütün entegrasyon noktaları ayrı ayrı test edilir. Entegrasyon testinde iç ileyii deilde bileenlerin istenilen ekilde birbirleri ile entegre edilip edilmedii test edilir. Entegrasyon noktalarını içerecek ekilde oluturulmu entegrasyon senaryolarına göre entegrasyon testi yapılır. Sistemin bütün olarak hedeflenen fonksiyonaliteyi yerine getirip getirmediini gösterecek olan senaryolar ile sistem testi gerçekletirilir. 4. Sonuç Mevcut bileenlerin entegrasyonu ile yazılım gelitirme, sıfırdan kod yazımı ile yazılım gelitirmeye göre önemli bir deiimdir. Bu nedenle mevcut süreç modellerinden bileen yönelimli yazılım gelitirme için yeni bir süreç modeline geçi kaçınılmazdır. Bu makale ile henüz yeni olan BYYM süreç modeli tanıtıldı. BYYM süreç modeli bileen yönelimli bir süreç modelidir. Bu model sistemi nerdeyse baımsız alt parçalara bölerek yazılım gelitiriminin yönetilebilirliini kolaylatırır ve paralelliini artırır. BYYM süreç modelinin köe taı entegrasyon ile gelitirimdir. Modelin yapıtalarını bileenler oluturur. Model, sistemin nasıl daha atomik alt parçalara bölüneceini ve bu alt parçaların yazılım bileenleri ile nasıl ifade edileceini belirtir. Dolayısı ile yazılım sektöründeki yazılım bileenlerinin belli bir olgunluk seviyesine ulamaları ve kolay eriilebilir olmaları modelin etkinliini artıracaktır.
Kaynakça [1] Jon Hopkins, Component Primer, Communications of the ACM, cilt 43, no. 10, sayfa. 27-30, Ekim. 2000. [2] H. Mili, F. Mili ve A. Mili, Reusing Software: Issues and Research Directions, IEEE Trans. Software Eng., cilt 21, no. 6, sayfa. 528-562, Haziran 1995. [3] Ali H. Dogru, Leon K. Jololian, Franz Kurfess ve Murat M. Tanık, Component based Technology for the Engineering of Virtual Enterprises and Software, TR-98-7, Bilgisayar Mühendislii Bölümü, Orta Dou Teknik Universitesi, ubat 1998. [4] Vedat Bayar, A process model for component oriented software development, Master Tezi, Bilgisayar Mühendislii Bölümü, Orta Dou Teknik Universitesi, Kasım 2001. [5] Kulak Darly, Guiney Eamonn, Use Cases Requirements in Context, Addison-Wesley, New York, 2000. [6] CORBA Components version 3.0, http://www.omg.org, OMG, Haziran 2002.