Bağımlılık Yapı Matrisleri ile Yazılım Mimarisi İncelenmesi

Transkript

1 Bağımlılık Yapı Matrisleri ile Yazılım Mimarisi İncelenmesi Analyzing Software Architecture Using Dependency Structure Matrices Ömer, Karaduman Mikroelektronik, Güdüm ve Elektro-Optik (MGEO) Grubu ASELSAN, Ankara Özet Bu makalede, yazılım sistemlerinin mimari yapılarının Bağımlılık Yapı Matrisi (BYM) oluşturularak incelenmesi ve bu incelemenin sonuçları kullanılarak yazılım kaynak kodlarının ve/veya mimari yapısının nasıl geliştirilebileceği anlatılmaktadır. Anlatılacak olan bu süreçte, kodların durağan olarak incelenmesiyle oluşturulan BYM ler incelenerek yazılım dâhilindeki parçaların birbirlerine olan bağımlılıkları gözlemlenmekte ve bu bağımlılıkların arzu edilen mimari yapıya uygunluğu değerlendirilmektedir. Bu inceleme neticesinde elde edilen sonuçlar mimari yapının doğrulanmasında, düzeltilmesinde ve/veya değiştirilmesinde kullanılarak, denetlenen yazılımın kalitesinin arttırılması sağlanmaktadır. BYM lerin oluşturulması ve incelenmesi ile ilgili temel bir açıklama yapıldıktan sonra ASELSAN MGEO Grubu bünyesinde geliştirilmiş bir projeye ait BYM oluşturma, inceleme ve geliştirme süreci adım adım anlatılacaktır. Abstract In this article, a method for examining architectural structures of software systems by using Dependency Structure Matrix (DSM) and improving the quality of the source code and/or architecture using the DSM is given. In this process, the DSMs which are generated via static analysis of the source code are examined in order to detect the dependencies between modules and these dependencies are evaluated with respect to the architectural structure. The results of these examinations are used in verification, fixing and/or changing the architecture and the quality of the software under examination is thus increased. After giving a brief explanation about creating and examining the DSMs, the process of DSM creation, examination and architecture improvement for a project which had been developed by ASELSAN, Microelectronics, Guidance and Electro-Optic Division, will be given. 1. Giriş Bağımlılık Yapı Matrisleri (BYM), ilk olarak üretim sektörü için oluşturulmuş bu kavramdır [1]. Bir üretim hattında, üretilecek olan bir parçanın diğer hangi parçaları etkileyeceği veya bir parçanın üretilebilmesi için diğer hangi aşamaların daha önce bitirilmesi gerektiği gibi bilgileri gösteren bu matris, üretim hattının o anki verimliliği ve üretimin nasıl daha verimli hale getirilebileceği hakkında ipuçları vermektedir [2]. BYM ler yazılım projelerinde de kullanılabilir. Bir yazılım projesinde bu yöntemle incelenenler temel olarak nesne oluşturma sırası ve veri akışıdır. Bilindiği üzere ideal bir sistemde veri akışı tek yönlü olmalı ve yazılım parçaları kendinden daha üst seviye hiçbir parçaya bağımlı olmamalıdır. Tasarlanan mimari yapı, alt seviyeden üst seviyeye bağımlılığı kabul ediyor veya gerektiriyor olsa bile bu tür bağımlılıkların çoğalması ile sistemin hem anlaşılması hem de üzerinde değişiklik yapılması zorlaşmakta, bu da iş gücü kaybı ile sonuçlanmaktadır. Çoğu projenin başlangıç aşamasında bir mimari yapı belirlense de bu projelerin pek azında, oluşturulan yazılımın tasarlanan mimariye uygunluğu kontrol edilmektedir. Yani yazılım mimarisi, kâğıt üzerinde çizilen şekiller, yalnızca göstermelik olarak hazırlanmış şemalar ve modüllerin isimlendirilmesinde kullanılan etiketler olarak kalmakta, dolayısıyla da yazılım kalitesine bir katkı sağlamamaktadır. Bunun neticesinde kod karmaşıklaşmakta, modüller arası döngüsel bağımlılıklar artmakta ve istenildiği gibi çalışan bir proje hazırlansa bile üretilen yazılım yeniden kullanılabilirlik, değiştirilebilirlik, esneklik gibi kavramlardan uzak olmaktadır. ASELSAN MGEO grubu bünyesinde yazılım mimarisinin doğrulanması ve/veya kontrol edilmesi ihtiyacı ilk olarak elektro-optik termal görüntüleme

2 sistemleri için geliştirilen yazılımların modüler hale getirilmesi ihtiyacından doğmuştur. Bilindiği gibi tank, gizli gözetleme araçları, insansız hava araçları, gemi ve füze sistemleri için termal görüntüleme teknolojileri ülkemizde ASELSAN tarafından MGEO grubu bünyesinde geliştirilmektedir. Şahingözü projesinde olduğu gibi bazı projelerde mevcut geliştirilmiş kod tabanının küçük değişiklikler yapılarak farklı platformlar veya görev tipleri için uygun hale getirilmesi ihtiyacı doğmuş, bu sebeple yazılımın modüler hale getirilmesi önem kazanmıştır. yapıya uygun olarak nasıl kullanılacağını bilen, hata yapmayan bireyler olmalarını sağlayarak Geliştirilen yazılımın mimarisini harici uygulamalar vasıtasıyla inceleyip görülen hataları düzelterek. İlk yöntem yeterli eğitim ve uygun uygulama geliştirme araçlarının kullanımı ile gerçekleştirilebilir gibi görülse de tek başına yeterli olmayacak ve yalnızca ortaya çıkan ürünün istenilen mimariye uygunluğu ile ilgili bir güven verecektir. Mimarinin doğrulanması ise ancak yine harici bir uygulamanın kullanılması ile olacaktır. İleriki bölümlerde, mimari yapının incelenmesi ve geliştirilmesi için BYM kullanımından ve bir BYM inceleme aracı ile mevcut bir projenin mimarisinin incelenmesi, mimari hataların bulunması ve bu hataların giderilmesi aşamalarından bahsedilecektir. 2. Bağımlılık Yapı Matrisleri Şekil 1:Şahingözü Sistemi nin sabit uygulamalarda kullanımı ve V. Teknoloji Büyük Ödülü 2.1. Bağımlılık Yapı Matrislerinin Oluşturulması Bağımlılık Yapı Matrisleri (BYM), bir projeye ait bütün modüllerin ve bu modüller arası bağımlılıkların bir arada listelenmesi için tasarlanmış, matris şeklinde bir gösterim biçimidir. Temel olarak, incelenen projedeki bütün modüller enine ve boyuna listelendikten sonra her bir sütün ve satır kesişim noktası için eğer sütundaki modül satırdaki modüle bir bağımlılık içeriyorsa bu noktaya bir işaret konulur. Konulan bu işaret sadece herhangi bir bağımlılığın olduğunu gösteren bir işareti olabileceği gibi, kaç farklı bağımlılığın olduğunu veya o modüller arasındaki bağımlılığını toplam bağımlılık sayısına olan oranını gösteren bir sayı da (Bağımlılık Şiddeti) olabilir[4]. Tablo 1: Basit bir Bağımlılık Yapı Matrisi Şekil 2:Şahingözü Sistemi nin hareketli platformlar için uygulamaları Yukarıda anlatılan sebeplerden dolayı geliştirilen yazılımların, belli bir mimariye uygun olmasının sağlanması gerekmektedir ve bu temel olarak iki şekilde mümkündür: Yazılım geliştiricilerin hepsi mimari yapıya hâkim, kullanılan programlama dilinin seçili mimari A B C D A B C D Tablo 2: Bağımlılık şiddetlerinin gösterildiği bir BYM A B C D A 1 B 1 21 C 4

3 D Tablo 1 ve Tablo 2 de temsili bir yazılıma ait Bağımlılık Yapı Matris leri gösterilmiştir. Tablo 1 deki gösterim yalnızca hangi modüller arasında bir bağımlılık olduğunu göstermekte fakat bu bağımlılıkların şiddeti hakkında herhangi bir bilgi vermemektedir. Bu tabloya bakılarak şu çıkarımlar yapılabilir: A modülü, B ve D modüllerine bağımlıdır B modülü, C ve D modüllerine bağımlıdır C modülü, yalnızca D modülüne bağımlıdır D modülü, A ve B modüllerine bağımlıdır Diğer bütün modüllerin bağımlı olduğu D modülü, kendisinden başka modüllere bağımlı olduğu için mimari açıdan sorun teşkil etmektedir. Tablo 2 de ise aynı tablo Bağımlılık Şiddeti değerleri kullanılarak oluşturulmuştur. İlk tablo için yapılan çıkarımlar aynı şekilde bu tablodan da çıkarılabilir. Bunun yanı sıra sayısal değerler, bağımlılığın tasarım hatası mı kodlama hatası mı olduğunu anlamakta yardımcı olabileceği gibi bu bağımlılıkların çözülmesi için bir öncelik sıralaması yapılmasında da kullanılabilir. Örneğin Tablo 2 de, D modülünün A modülüne olan bağımlılığı kabul edilebilir veya öncelik verilmesine gerek olmayan bir bağımlılık olarak ele alınabilirken, D modülünün B modülüne olan bağımlılığının şiddeti, büyük olasılıkla, mimari yapı ile ilgili bir yanlışlık yapıldığını göstermektedir. Kullanılan BYM inceleme aracı, projeyi inceleyip modülleri otomatik olarak oluşturabilir. Örnek projenin incelenmesinde kullanılacak olan Lattix LDM isimli araç ile BYM oluşturulmak istenirse modüller, kullanılan programlama dili göz önünde bulundurularak oluşturulacaktır. Örneğin, C dilinin kullanıldığı bir projede, kaynak dosyaları ve bu dosyaların içerisinde bulunduğu klasör yapısı modül oluşturmada kullanılırken bir JAVA projesi için modüller, tanımlı sınıflar ve paketler olacaktır. İstenildiği takdirde bu modüller ve içerikleri elle değiştirilebilir, yeni üst seviye modüller belirlenip sınıf veya dosyalar bu modüllerin içerisine eklenebilir. Burada dikkat edilmesi gereken nokta, yeni modül oluştururken veya bir alt modül farklı bir üst modülün altına taşınırken mimari yapının dışına çıkılmamasıdır. Bu gerekten dolayı bu tür değişikliklerin sistem mimarisine hâkim bir kişi gözetiminde yapılması yerinde olacaktır BYM lerin Düzenlenmesi BYM oluşturulurken sistemin mimari yapısı dikkate alınmalıdır. Başka modüllerin bağımlı olduğu modüller altta, başka modüllere bağımlı modüller üstte olacak şekilde bir düzenleme yapılırsa, projenin mimari yapısının doğrulanması daha kolay olacaktır. Örneğin, mimari yapısının Şekil 3 deki gibi olması istenen bir projenin incelendiğini ve BYM nin Tablo 3 teki gibi oluşturulduğunu varsayalım. Şekil 3: İstenilen mimari yapı Tablo 3: Düzenlenmemiş Bağımlılık Yapı Matrisi (A) İş Katmanı A B C D (B) Güvenlik (C) Veritabanı (D) Grafik Arayüz Grafik Arayüz Güvenlik İş Katmanı Veritabanı Görülebileceği üzere, BYM deki modüller, hedeflenen sisteme uygun olarak dizilmemiştir. Bu şekilde bir BYM kullanılarak hangi modüllerin hangi modüllere bağımlı olduğu tespit edilebilse bile bağımlılıkların mimariye uygunluğunun tespiti ayrıca bir çaba gerektirecektir. Bu işlemi kolaylaştırmak için BYM, Tablo 4 teki gibi düzenlenebilir. Tablo 4: Düzenlenmiş Bağımlılık Yapı Matrisi

4 (A) Grafik Arayüz A B C D (B) Güvenlik (C) İş Katmanı (D) Veritabanı Bu düzenleme işlemi, mimari yapı ve projenin isterleri ile ilgili bir bilgi birikimi gerektirdiğinden dolayı bahsi geçen konularda bilgili kişilerin kontrolünde yapılmalıdır. Aksi takdirde alınan sonuçlar ve bu sonuçlara göre yapılan yorumlar gerçeği yansıtmayabilecektir BYM lerin Yorumlanması BYM ler kullanılarak yalnızca kodun mimariye uygunluğunun değil, mevcut mimarinin istenilen mimariye uygunluğunun da kontrol edilebileceği daha önce belirtilmişti. Eğer, oluşturulan BYM nin incelenmesi neticesinde hâlihazırdaki mimarinin beklenileni karşılamadığı tespit edilirse yeni modüller oluşturularak mimari yapı yeniden düzenlenebilir. Tablo 5 te gösterilen tablo, Tablo 4 te gösterilmiş tablonun yeniden düzenlenmiş biçimidir. İlgili senaryoya göre, normalde Güvenlik Katmanı ndan bağımsız olması planlanan İş Katmanı nın güvenlik katmanına bağımlı olduğu görülmüş, gerekli incelemeler yapıldığında ise bunun sebebinin, veritabanına gönderilen verilerin doğrulanması ile ilgili işlemlerin de güvenlik katmanında yapılıyor olması olduğu görülmüştür. Bu tespitin neticesinde güvenlik katmanı kullanıcı yetkilendirme ve veri doğrulama olarak ikiye ayrılmış ve gerekli mimari düzenleme yapılmıştır. Tablo 5: Düzenlenmiş Bağımlılık Yapı Matrisi Grafik Arayüz Kullanıcı Yetkilendirme İş Katmanı Veri Doğrulama Veritabanı Şekil 4: Yeniden düzenlenmiş mimari yapı 3. Bir Projeye Mimari Yapının BYM İnceleme Aracı Kullanılarak İncelenmesi Bu bölüm, ASELSAN tarafından geliştirilmiş bir projenin modülerleştirilmesi amacıyla yapılan değişiklikler neticesinde istenilen modülerliğin sağlanıp sağlanamadığını görmek amacıyla yapılmış olan incelemeleri içermektedir. Bu incelemeler esnasında referans alınan bir mimari model bulunmadığı için bir mimari modele uygunluk yerine modüller arasındaki bağımlılıkların listelenmesi amaçlanmış ve BYM inceleme aracının mimari uyumluluğu denetleyebilmesinin nasıl mümkün olabileceğini göstermek amacıyla temsili bir mimari model kullanılmıştır. Mimari incelemenin yapılmasının yanı sıra, bu inceleme sonuçları kullanılarak bağımlılık sorunu içeren modüllerin tespiti ve bu bağımlılıkların giderilmesi için yapılan işlemlerden de bahsedilecektir 3.1. Bağımlılık Yapı Matrisinin Oluşturulması ve Düzenlenmesi Proje ilk yüklendiğinde BYM, Şekil 5 deki gibi gösterilecektir. (A) Grafik Arayüz (B) Kullanıcı Yetkilendirme (C) İş Katmanı A B C D E (D) Veri Doğrulama (E) Veritabanı Görülebildiği üzere, projeye ait BYM nin incelenmesi ile yalnızca kodlama hataları değil mimari hataları da tespit edilebilmekte ve giderilebilmektedir. Şekil 4 te aynı projenin düzenlenmiş mimarisi gösterilmektedir. Şekil 5: Harici bir yazılımla oluşturulmuş bir BYM

5 Projede programlama dili olarak C kullanıldığı için modüller kaynak dosyalarının klasörleme düzenine göre oluşturulmuş ve bu modüller harf sırasına göre dizilmiştir. Modüllerin, otomatik oluşturulandan farklı olduğuna kanaat getirilirse gerekli düzenlemeler yine BYM oluşturma aracı ile yapılabilir. Sayılar, o sütundaki modülün o satırdaki modüle kaç farklı bağımlılığı olduğunu göstermektedir. Örneğin 8. satır ve 2. kolonun kesişimindeki 99 sayısı, bit modülünün include modülüne 99 ayrı bağımlılığı olduğunu göstermektedir. Bu bağımlılıkların kaynağı include modülünde tanımlanmış ve bit modülünde kullanılan her şey (fonksiyonlar, değişkenler, sınıf tanımları...) olabilir. Şekil 5 teki matriste modüller yapısal bir düzene göre değil alfabetik olarak sıralanmışlardır. Sistem mimarisi ile ilgili bir yorum yapmadan önce bu modüllerin uygun şekilde sıralanması uygun olacaktır. Eğer kullanılacak olan mimari yapı önceden belirlenmişse sıralama bunu yansıtacak şekilde yapılabilir ve sonuçlar bu mimari yapı ele alınarak incelenebilir[3]. Bu şekilde bir mimari mevcut değilse BYM inceleme aracının düzenlemeyi otomatik olarak yapması sağlanabilir. Kullanılan aracın bu özelliği incelenen projede uygulandığında Şekil 6 daki tablo elde edilmektedir. sayısını en aza indirgemeyi hedeflemektedir. Bu durum, olması gereken mimari sıralama uygulandığında görülebilecek olan bazı bağımlılık sorunlarının gözden kaçmasına sebep olabilir. Öte yandan, otomatik oluşturulan bu mimari ile uyulması düşünülen mimari karşılaştırılarak, mimari yapıda değişiklik yapılması gerekip gerekmediği ile ilgili bir karar verilebilir Bağımlılıkların İncelenmesi Daha önce belirtildiği üzere, sütun ve satırların kesişimindeki sayılar o sütun ve satırın temsil ettiği modüller arasında bir bağımlılık olduğunu gösterir. Bu yüzden, birbirlerinden tamamen bağımsız modüller incelenirken matrisin hiçbir satır veya sütununda bir sayı bulunmaması gerekmektedir. Yukarıdan aşağıya doğru bağımlılığın olduğu fakat aşağıdan yukarıya bir bağımlılığın olmadığı katmanlı mimarilerde ise bağımlılık matrisinin üst üçgeninde herhangi bir sayı olmaması gerekirken köşegenin altında kalan üçgende sayılar bulunabilir[3]. Örnek projenin incelenmesi sürecinde de projenin mimarisinin buna benzer bir yapıda olduğu varsayılmıştır. Diğer mimari yapılar da benzer şekilde ele alınarak incelenebilir. Şekil 6 ya bakıldığında, ortadaki büyük kareyi oluşturan modüllerin arasında yoğun bir bağımlılık olduğu görülebilir. BYM inceleme aracı kullanılarak bu bağımlılıkların hangi dosyalar arasında ve hangi sebepten olduğu görülebilir. Örneğin, 4. satır ve 10. kolonun kesişim noktası seçiliyken bağımlılıklar incelenecek olursa Şekil 7 deki sonuçlar görülecektir. Şekil 6: Otomatik olarak düzenlenmiş bir BYM Tahmin edilebileceği üzere, bu projede en çok bağımlılık, başlık dosyalarının bulunduğu include modülünedir ve bu modül BYM inceleme aracı tarafından Şekil 6 da görülebildiği üzere en alt katman olarak atanmıştır. BYM aracı tarafından otomatik olarak oluşturulan mimari yapının gerçeği yansıtmayabileceği unutulmamalıdır. BYM aracı bu sıralamayı yaparken aşağı katmanlardan yukarı katmanlara olan bağımlılık Şekil 7: Bağımlılık kaynaklarının tespit edilmesi Görülebileceği üzere seçili bağımlılığın sebebi ccdaytvcommon.c dosyasının testinterface modülü altındaki cctestcommon.c ve cctestdtv.c dosyalarını kullanıyor olmasıdır. Bahsi geçen dosyalar incelendiğinde, ccdaytvcommon.c dosyasının cctestcommon.c dosyasında tanımlanmış olan send_scanner_cmd ve send_test_ack fonksiyonları ile cctestdtv.c soyasında tanımlanmış olan send_dtv_status_to_te fonksiyonunu kullandığı görülebilir. BYM aracında oluşturulmuş olan modül

6 sıralaması referans alınan mimariye göre doğru kabul edilmiş ise alt seviyedeki bir modülün üst seviyedeki bir modülü kullandığı bu durumun kaldırılması gerekmekte veya mimaride bu durumu geçerli kılacak değişiklikler yapılması gerekmektedir. Modül sıralamasının değiştirilmesi, mimari yapıda değişiklik yapılmasının tek yolu değildir. Farklı olarak, modüller arası kullanım kuralları da belirtilebilir. Örneğin, kullanılan örnekteki gibi bir projede, bir alt seviye modülün kendisinden daha üstteki bir modülü kullanmasına izin verilmek istenirse bu şekilde bir kural belirlenebilir. Benzer şekilde, üst seviyedeki bir modülün alt seviyedeki bir modülü kullanamaması için de benzer bir kural tanımlanabilir. Bir diğer yöntem ise modül içeriklerinin yeniden düzenlenmesidir. Örneğin, yukarıdaki örnekte, dtv modülünün testinterface e olan bağımlılıkları, testinterface modülü altındaki cctestcommon.c ve cctestdtv.c dosyalarından kaynaklanmaktadır. Mimari yapıya daha uygun olacağı düşünülürse bu dosyalar dtv modülünün altına taşınabilir. Bu işlem yapılırken, taşınan dosyaların yeni bağımlılıklar oluşturmamasına dikkat edilmelidir. Örnek üzerinden devam edersek, eğer cctestcommon.c dosyası, testinterface ve dtv modülleri arasında kalan bir modüle de (örneğin comm modülü) bağımlılık içeriyorsa, bu dosya dtv modülüne taşındığı zaman dtv modülü comm modülüne de bağımlı hale gelecek ve bir bağımlılık giderilirken yeni bir bağımlılık oluşmuş olacaktır. Kullanılan BYM aracı, bu tür taşıma işlemleri ile ilgili ipuçları sağlayabilir. Şekil 8 da, BYM aracının sağladığı ipuçları ile yeniden düzenlenmiş sistem gösterilmiştir. Görülebileceği üzere, matris köşegeninin üstünde kalan bağımlılıkların bir kısmı, dosyaların farklı modüllere taşınmaları sayesinde çözülmüştür. Kalan bağımlılıklar ise bu şekilde çözümlenemeyen bağımlılıkları göstermektedir. Bu tür bir bağımlılığın oluşması durumunda bütün dosyayı taşımak yerine, bu dosyalardaki bağımlılığa sebep olan kod parçalarının taşınması da düşünülebilir. Daha önce de belirtildiği üzere bu tür kararlar sistem mimarisine ve kod yapısına hâkim kişiler tarafından verilmelidir Mimari Yapının İncelenmesi Kullanılan BYM aracı, mimari yapının yalnızca BYM gösterimiyle değil, Şekil 9 da görüldüğü gibi modül blokları ve veri akış okları ile de gösterilmesine olanak sağlayabilir. Bu gösterim BYM kadar detaylı olmasa da kimi zaman görsel olarak daha anlaşılır olabilir ve hedeflenen mimari çizimi ile karşılaştırma yapılması daha kolay olabilir. Şekil 9: Bağımlılıkların blok olarak gösterimi Bu şemadaki modüllerin dizilimi kullanıcı tarafından değiştirilebilir. Bağımlılığı gösteren oklar ise modüllerin yer ve boyutlarından bağımsız olarak korunur. Bu sayede hedeflenen mimari şema hazırlanıp sistemin şu anki haline ait yanlışlıklar rahatlıkla tespit edilebilir. Örnek olarak, incelediğimiz projenin mimarisinin Şekil 10 daki gibi şeffaf-katmanlı bir yapıda olmasını istediğimizi varsayacağız. Şekil 8: Dosyaların taşınması ile modülerliğin arttırılması

7 Şekil 12: Gruplama sonrası mimari görünüm Şekil 10: Mimari yapının düzenlenmesi Şeffaf-katmanlı mimarilerde üst modüller alt modülleri kullanabilirken bunun tersi geçerli değildir. Sistemin şeffaf-katmanlı mimariye olan uygunluğunu görmek için modülleri uygun şekilde yerleştirdikten sonra yukarıya doğru giden (mimariye uygun veri akışını gösteren) oklar ayrılarak, kaldırılması gereken bağımlılıkların hangi modüller arasında olduğu görülebilir. Bu şekilde bir gruplama ile üst seviyede bir modülerlik sağlanabilir. Bu durumda, mimari olarak bağımlılık sorunları aynen devam ediyor olsa da üst seviyede katmanlı bir yapı oluşturulduğu için bu üst seviye modüller daha bağımsız bir şekilde incelenebilir ve değiştirilebilir[4]. Alt seviyede ise, Şekil 13 te görülebileceği üzere bağımlılıklar devam etmektedir. Daha önceki bölümlerde anlatıldığı şekilde, kod içerisinde veya mimaride değişiklikler yapılarak bu bağımlılıkların giderilmesi sağlanabilir Mimari Yapının Düzenlenmesi Bahsi geçen incelemelerden görülebileceği üzere bu projede bağımlılıkların çoğu belli başlı modüller (bit, testinterface, comm, exdat, ocm, hekos, symbology, dtv, pt) arasında yoğunlaşmıştır. İstenirse, incelemeyi kolaylaştırmak ve/veya üst seviye bir modülerlik yakalamak için birbirine bağımlı olan bu modüller tek bir grup altında toplanabilir. Şekil 13: Gruplama sayesinde bağımlılıkların tek bir modül altında toplanması Şekil 11: Üst seviyede modülerlik sağlanması için modüllerin yeniden gruplanması 3. Sonuç Özellikle büyük boyutlu projelerde yazılım mimarisi büyük önem taşımaktadır. Yapılacak olan projeye uygun olarak hazırlanmış bir mimari yapı, bir yol gösterici olarak kullanılmanın yanında proje parçalarının yeniden kullanılabilirliğinin ve projenin esnekliğinin arttırılmasını, dolayısıyla da toplamdaki iş gücü azaltılırken yazılımın kalitesinin arttırılmasını sağlayacaktır. Anlatılan BYM yöntemi ise, özellikle harici araçlar kullanılarak uygulandığında, tamamen yazılım

8 geliştirme sürecine paralel sürdürülebilecek yani bu süreci sekteye uğratmadan mimari incelemelerin yapılabilmesini sağlayacak bir yöntemdir. BYM gösterimi, hazırlanışının kolay olmasının yanı sıra bağımlılıkların kolaylıkla tespit edilebilmesini de sağladığı için yazılım mimarilerinin incelenmesi ve geliştirilmesi aşamalarında kullanılması tercih edilebilecek bir gösterim çeşididir. 4. Kaynaklar [1] Browning, T. R., Applying the DesignStructure Matrix to System Decomposition and Integration Problems: A Review and New Directions, 2001 [2] Eppinger, S. D., "Innovation at the Speed of Information", Harvard Business Review, [3] Hinsman, C., Sangal, N., Stafford, J. Large Scale Refactoring through Architecture Visibility, 2007 [4] Sangal, N., Jordan, E., Sinha, V., Jackson, D., Using Dependency Models to Manage Complex Software Architecture, Conference on Object Oriented Programming Systems Languages and Applications, San Diego, California, 2005