Yazılım Mimarisi (Software Arhitecture)

   Yazılım geliştirme sürecinin ilk adımlarında problem analizi yapılarak  sistemde nelerin yapılması gerektiği ortaya konur. İhtiyaçların nasıl karşılanacağı , nasıl çözümler geliştirileceği ise dizayn disiplinin konusudur. Dizayn geliştirme boyunca çözümler için alınan kararlar öncelikle üst seviyede alınır ve giderek detaylandırılır.

  

   Yazılım mimarisi ; dizayn disiplininin ilk aşamalarında ortaya çıkar.Yazılım Mimarisi deneyimli yazılımcılar tarafından kolaylıkla anlaşılabilse de , tarifi oldukça zor bir kavramdır.Yazılım dizaynı ile yazılım mimarisi sıklıkla birbirine karıştırılmaktadır.Dizayn sistemin tüm ayrıntılarını içerdiği halde mimari bize sistemin ne olduğunu hakkında bilgi verir.Başka bir deyişle mimari ; dizaynın belli özellikleri öne çıkarılmış bir alt kümesidir.

  

   Ancak bu tanımdan mimarinin , dizayndan sonra hazırlandığı gibi bir sonuca ulaşılmamalıdır.Aksine mimari öncelikle hazırlanan bir kavramdır.Dizayn daha sonra mimaride belirtilen parçaların detaylandırılmasını kapsar.

  Yazılım Mimarisi “ sistemi tanımlayan en üst seviye kavramlar”  olarak nitelendirilebilir.

Yazılım mimarisi şunları içerir :

• Sistemin organizasyonu hakkında önemli kararlar
• Sistemin önemli yapısal elementleri ve bunların arayüzleri ile birbirleri arasındaki etkileşim
• Sistemin önemli yapısal ve davranışal elemanlarının altsistem’lere dağılımı

  Yazılım mimarisi yapı ve davranışların yanı sıra kullanılabilirlik , fonksiyonalite , performans , esnekllik , yeniden kullanım , anlaşılırlık , ekonomik ve teknolojik kısıtlar gibi özellikleri de yansıtır.

Tüm bu özellikleri ile “Yazılım Mimarisi” sistemin anayasasıdır.Tüm yazılım geliştirme sürecinin merkezinde durur ve her türlü faliyete kılavuzluk eder.

   Yazılım mimarisi pek çok sebepten dolayı önemlidir :

• Sistemin karmaşıklığını yönetmek ve bütünlüğünü korumak için , kontrol edilebilir bir yapı sunar

   Karmaşık sistemler kendini oluşturan parçaların bütününden daha fazla şey ifade ederler.Böyle sistemler kendini oluşturan parçaların nasıl bir araya geldiğini ve çalıştıklarını düzenledikleri gibi ,  gerektiğinde sistemin nasıl büyüyeceğini de tariflemelidir.Mimarisi tarif edilmemiş sistemde yapılacak her türlü değişiklik tam bir kaos olacaktır.Mimari ortak bir referans ve sözlük sunarak sistemin anlaşılırlığını ve iletişimi iyileştirir.

   Bundan başka mimari tüm ana parçaları belirlediğinden bundan sonraki tüm çalışmalar için bir adresleme sağlar.Hangi parçanın nerede ele alınacağı , hangi kavramın nereye oturtulacağı mimari ile belirlenir.Tüm parçaların görevleri ve kapsamı belirlendiğinden kaos ortadan kalkar.

• Yeniden kullanımı arttıran kullanışlı bir yapı sunar

   Sistem bileşenlerinin  ve bunların arabirimlerinin mimaride tariflenmesi ; bileşenlerin   hem sistem içinde hem de başka sistemler içerisinde yeniden kullanımını önemli ölçüde arttırır.Sistem içinde ortak bileşenlerin adresleri belirlendiğinden kullanımları artar .Örneğin aynı çözümün sistem içerisinde birden fazla geliştirilmesi gibi problemlerin önüne geçilmiş olur.Dış sistemler de (örneğin geliştirilen diğer projeler ) ise kendi çözümleri içerisinde bu bileşenleri kullanabilirler.

   Daha geniş ölçekte  mimarinin kendisi de  farklı çözümlerde yeniden kullanım olanağı bulabilecektir.

• Proje yönetimi için temel teşkil eder

     

   Projenin planlama ve kaynak yönetimi organizasyonu ana bileşenler etrafında oluşturulurlar.Temel yapısal kararlar mimari takımı tarafından bütünlük içerisinde yaratılırlar.Geliştirme aktiviteleri küçük takımlar halinde bileşenler etrafında yapılırlar.

       Yazılım geliştirme süreci oldukça karmaşık ve  zor bir süreçtir.Bu süreçte dağılmamanızı sağlıyacak şey , sürecin merkezinde duran şey yazılımınızın mimarisi olmalıdır..

Altsistemler (Subsystems)

Bileşen sistem içerisinde bulunan , iyi tanımlanmış arabirim ve davranışlarıyla içeriği hakkında güçlü bir kapsulleme sunan , aynı zamanda değiştirilebilir , kaynak ya da çalışabilir durumda ki bir gurup koda verilen isimdir.

Sistem dizaynının ilk adımı sistemin ana bileşenlerinin tariflenmesidir.Bu ana bileşenler aynı zamanda altsistem olarak da adlandırılırlar.Altsistemler bir sınıf ya da fonksiyon değildirler.Altsistemler sınıflar , ilişkiler , operasyonlar , olaylar , kurallar gibi birbiriyle ilişkili pek çok kavramı barındıran paketlerdir.Altsistemler genellikle sundukları servis ile tanımlanırlar.Servis ortak bir amaca hizmet eden bir gurup fonksiyon olarak tanımlanabilir.Örneğin işletim sistemleri bünyelerinde  bellek yönetimi , dosya yönetimi gibi alt sistemler bulundururlar.

Her altsistem ; sistemin geri kalanı için bir arabirim sunar.Arabirim ; altsistemin tüm fonksiyonalitesini dışarıya sunar ve altsistemin fonksiyonalitesini belirler.Ancak işlemlerin altsistem içersinde nasıl gerçekleştiğini göstermez.Altsistemler sistemin geri kalanını etkilemeden bağımsız olarak dizayn edilebilirler.

Bir sistem sınırlı sayıda alt sisteme sahip olmalıdır.Örneğin 20 muhtemelen çok sayıda altsistemi işaret etmektedir.Altsistemler de kendi içlerinde altsistemlere ayrılabilirler. Altsistemlerin diğer altsistemlere olan bağımlılıkları mümkün olduğunca kısıtlı tutulmalıdır.Bağımlılıklar tercihan aynı seviyedeki altsistemler yerine barındırdığı altsistemler ile arasıda kurulmalıdır.En alt seviyedeki alt sistemlere modül adı verilmektedir.

İki altsistem arasında kurulacak ilişkiler iki şekilde sınıflandırılmaktadır:

• İstemci – Destekçi (client-supplier) : Bu tür ilişkide istemci , destekçi’nin arabirimini bilmek zorundadır.Bu arabirim üzerinden istediği servisleri alır.Ancak bu tür bir ilişkide destekçi ; istemci hakkında bir bilgiye sahip olmak zorunda değildir.Tek taraflı bir bağımlılık söz konusudur.
• Eşdüzeyli (peer-to-peer) : Bu tür bir ilişkide altsistemler birbirlerini kullanırlar.Bu tür ilişkiler daha karmaşıktır.Her iki altsistem de birbirinin arabirimini bilmek zorundadır.İletişimin dizaynı oldukça karmaşık ve hataya açıktır.

  

   Altsistemler arasında ilişkiler kurulurken mümkün mertebe istemci-destekçi tarzı ilişkiler kurulmaya çalışılmalıdır. Sistemin altsistemlere açılımı yatay olarak katmanlar , dikey olarak bölümler olarak organize edilebilir.

Katmanlar (Layers)

   Katmanlar , sistem içersinde birbiri ardına gelen sanal dünyalar olarak nitelendirilebilir.En üst seviye katmanlar uygulamaya has fonksiyonalite sunarken , alt seviyeler daha çok çalışma ortamına özel bileşenleri içerirler.Genel amaçlı servisler ve iş mantığı servisleri ise genellikle orta seviyeler yer alır. Katmanlar içerisinde birbiriyle benzeşen nesneler olabilir.

  Katmanlar arasında bilgi tek yönlüdür.Her katman daha alt seviyede ki  katmanlar hakkında bilgi sahibi olabilir ancak üst seviyeler hakkında bir bilgisi yoktur.Alt katmanlar ile üst katmanlar arasında istemci-destekçi tarzı ilişki söz konusudur.

  Katmanlanmış Mimariler’de açık ve kapalı olmak üzere iki form söz konusu olabilir.Kapalı mimaride katmanlar sadece takip eden katmanla iletişim kurabilir.Bu katmanlar arasında bağımlılıkları azaltır ve değişiklikler için daha esnek bir sistem sağlar.Çünki katman’ın arabirimleri üzerinde yapılacak değişiklik sadece bir katmanı etkiler.Açık mimaride katman ; alt seviyelerin tümüne erişebilir .Bu operasyonların her seviyede yeniden tanımlanma gereksinimini ortadan kaldırır ve daha verimli ; küçük kodlar sağlar.Ancak değişiklikler pek çok seviyeyi etkileyebilir.Bu yüzden açık mimari , kapalı mimariye göre daha az güvenli bir yapı sunar.

  Katmanların yalnızca en alt ve en üst seviyeleri problem durumuna göre belirlenir.En üst seviye talep edilen seviyedir , en alt seviye ise kaynakları (database , donanım , işletim sistemi vb) yönetir.

  Katmanların sayısı ve komposizyonu hem problemin hem çözümün karmaşıklığına bağlı olarak değişebilir.

Bölümler (Partititons)

     Bölümler sistemi dikey olarak bölen , her biri bir çeşit servis sunan ,  bağımsız ya da zayıf eşlemeli alt sistemlerdir.Örneğin bir işletim sisteminde dosyalama sistemi , sanal bellek kontrolü , aygıt kontrolü gibi bölümler bulunur.Bölümler birbirleri hakkında büyük bağımlılıklar yaratmayacak kadar bilgi sahibi olabilirler.

   Bir sistem çeşitli kombinasyonlarda hem katmanlara hem de bölümlere parçalanabilir.Katmanlar bölümlere ayrılabilir ya da bölümler katmanlara ayrılabilir.

  

Bileşenler (Components)

   Bileşenler sistem içerisinde modul , paket ya da altsistem gibi kesin sınırları olan ve sorumluluğu belirlenmiş elemanlar olarak da tanımlanabilir.Bileşenler sisteme entegre olabilir ve değiştirebilir yapılardır.Bu aynı zamanda  bileşenlerin başka sistemler içerisine de entegre edilebilir ve yeniden kullanılabilir olduğunu anlatır.

   Moduler bir mimaride bileşenleri bağımsız olarak tanımlar , izole eder , dizayn eder ve geliştirebilirsiniz edebilirsiniz.Daha sonra bileşenler  yine bağımsız olarak test edilip sisteme entegre edilebilirler. Bu bileşenlerden bir kısmı genel çözümler sundukları tesbit edilirse daha geniş alanlarda kullanılabilirler.Bu yeniden kullanılabilir bileşenler organizasyonun genel yazılım verimliliğini ve kalitesini arttırmanın bir yoludur.

    Corba , Active X , Java Bean gibi bileşen altyapıları tüm endüstriye yeniden kullanılabilir bileşenler geliştirmenin yolunu açmıştır.Bu sayede çözümünü beğendiğimiz bileşenleri alıp sistemlerimize entegre edebilmekteyiz.

Çalışma Alanı (Domain) Kavramı

   Sistemimizi yapısal olarak katmanlara ve bölümlere ayırabiliyoruz.Bir üçüncü boyut olarak gelen çalışma alanı (domain ) aslında sistem içerisinde adreslenen çözümlerin genelden özele doğru yeniden kullanılabilir parçalar halinde düzenlenmesidir diyebiliriz.Örneğin muhasebe alt sisteminin genel  , hazırlanan alana özgü (sigorta , bankacılık vb)  ve şirkete özgü parçaları.Çalışma alanlarından  katmanlar ve bölümler gibi yapısal bir parçalanma değil mantıksal bir parçalanma olarak söz edebiliriz.

   Örnek şekil bir uygulama parçalarının nasıl ele alındığını ve içindeki çalışma alanlarının nasıl tesbit edildiğini göstermektedir.Buna göre uygulama içerisindeki iş mantığı içermeyen yeniden kullanılabilir kodlar framework içerisinde toplanmış , işe özel ancak o iş içinde yeniden kullanılabilir kodlar bir başka parçya ayrıldıktan sonra geriye kalan kodlar uygulamaya özel olarak belirlenmiştir.

   Çalışma alanlarının tesbiti sistemdeki genellemelerin ve farklılıkların tesbitini gerektirir.Sistemin daha genel kullanım bulabilecek fonsiyonaliteleri genelden özele doğru parçalara ayrılmalıdır.Bunun en iyi etkisi yeni sistemlerin dizaynı sırasında , üzerinde özelleştirmelerin yapılabileceği sistemlerin hazır halde oluşmuş olmasıdır.

   Çalışma alanı tesbitine problem analizi sırasında başlanmalıdır ve problem bağlamında önceden hazırlanmış çözümler değerlendirilmelidir.Aksi takdirde hazır yapıların değerlendirilememesi ve gereksiz iş gücü kaybının yanı sıra hazırlanacak çözümlerinde yeniden kullanılamaması gibi sakıncalar oluşacaktır.Alttaki şekil uygulama süreçleri ile çalışma alanlarının oluşturulma süreçleri arasındaki ilişkiyi göstermektedir.

  

    

    Yazılım mühendisliğini istekler  doğrultusunda geliştirilen , tek sisteme yönelik bir çalışma olduğunu varsayarsak , çalışma alanı mühendisliği pek çok sisteme uyabilecek yeniden kullanılabilir çözümler sunan bir çalışmadır denilebilir.

   Çalışmalar yapılırken hazırlanan çözümlerin daha geniş alanlara uygulanabilip uygulanamıyacağı sorgulanmalı ve ilerideki projeler için yeniden kullanılabilir çözümler hazırlanmalıdır.Bu işlem bizi yavaşlatır görünse de tüm süreçler içindeki avantajı ve sağlıyacağı katkılar inanılmaz boyutlarda olabilir.   Alan çalışmaları sonucu elimizde yeniden kullanılabilir kod parçalarının yanı sıra çözüm tasarımları da  oluşacaktır.Bu tasarımlar farklı dillerde ve ortamlarda yeniden uyarlanabilir olduğu göz önüne alınırsa , kurumsal bir yapı oluşturulmuş ve farklı çözümler geliştiren firmalara olabilecek katkısı daha iyi anlaşılır.

      Alan çalışmalarına sürecin en başından başlanamasa bile hazır sistemler üzerinde çalışma alanı analizleri yapılarak yeniden kullanılabilir parçaların tesbiti mümkündür.