İyi yazılım mimarisini nasıl tanıyorsunuz?
Bugün iyi yazılım mimarisi yapan şeyle ilgilenen Alexander Eisenhuth'un konuk katkısını sunmak istiyorum. Alexander, 1996'dan beri yazılımın mühendisliğinde bağımsız olarak çalışmaktadır. On yıldan fazla bir süredir, yazılım mimarından yazılım mimarisinin çalışmasındaki geliştirme ekiplerini bir yazılım mimarı olarak desteklemektedir. Alexander tutkusu hakkında yazıyor: iyi yazılım mimarisi.
Rainer Grimm yıllardır yazılım mimarı, ekip ve eğitim müdürü olarak çalıştı. C ++ programlama dilleri, Python ve Haskell hakkında makaleler yazmayı seviyor, ancak uzman konferanslarla konuşmayı da seviyor. Modern C ++ blogunda, C ++ tutkusuyla yoğun bir şekilde ilgileniyor.
“İyi yazılım mimarisini nasıl tanıyorsunuz?” Bu, web seminerinin sonunda “Agile yazılım mimarisi” konusundaki soru buydu. O zamandan önce katılımcı bu hikayeyi söyledi: “Yapılan yazılımımızla, artık genişletemeyeceğimiz noktaya ulaşıyoruz. Yazılım, cihazlarımızın ailelerini on yılı aşkın bir süredir desteklemektedir. Bir ürünün değişikliklerinden sonra, diğer ürünlerde beklenmedik davranışlar meydana gelir“.
Hiç böyle bir hikayeyi duydun mu? Bu nedenle yazılımın durumu “tarihsel olarak ekili” veya “büyük çamur topu” olarak da adlandırılır.
Kalite özellikleri cevaptır
Yazılımın iyi mimarisi ile ilgili soru basitçe bir cevaptır: iyi yazılım mimarisi, gerekli kalitenin özelliklerini uygularken tanınabilir. Yukarıdaki hikaye söz konusu olduğunda, yazılım bakımının kalitesinin bir parçasıdır. Prensip olarak, “tarihsel olarak ekili” yazılım bekliyor, sadece istenen ve profesyonel olarak doğru koşullara aktarmak pahalıdır. Sonuç her durumda tatmin edici değil:
Kalite özellikleri ISO 25010 kalite modelinde ayrıntılı olarak açıklanmaktadır. Kalite özelliklerinin yazılım yaşam döngüsünün farklı aşamalarını etkilediğini görebilirsiniz.
Kalite özelliklerinin önceliğinin önemli bir yönü vardır. Önemli, kritik ve ilgili olmayan niteliklerin özelliklerine ayrılabilirler.
Yazılımın veya sistemin kullanımı ve satışı olmadan kabul edilemez olduğu için kritik kalite özellikleri garanti edilmelidir. Bu kalite özelliklerine uyumu garanti etmek gerekir.
Yazılım mimarisi çalışmalarında önemli kalite özellikleri de gözlemlenmelidir, ancak derhal eleştirileri yoktur.
Sürdürülebilirlik genellikle önemli bir kalite özelliktir. Kötü bakımın etkisi, örneğimizin başlangıçtan itibaren gösterildiği gibi yıllar içinde belirgin hale gelmiştir.
Kalite özelliklerinin bakımı
Kalite özelliği, süreyi tüketen bakım faaliyetlerine sahip kalitenin yazılım üzerinde yapılabileceği anlamına gelir.
Bakım faaliyetleri:
Böylece bir ekip yukarıda listelenen faaliyetleri verimli bir şekilde yerine getirebilir, kaynak kodunun temelde uygun bir yapılandırmaya sahip olması özellikle önemlidir. Ekip, kaynak kodundaki işlevlerin nerede bulunduğunu ve yazılımın nasıl geliştirildiğini ve böylece yazılımın iyi beklemeye devam etmesi gerektiği açık olmalıdır. Bu yaklaşık olarak yazılım mimarisinin çalışmasının sonucudur:
Bakımı destekleyen kavramlar
Tipik teknik kavramlar, yazılımın bakımına ulaşmak için aşağıdaki tabloda listelenmiştir:
Tıbbi termometre örneğini kullanarak mimari ve mimari modeli stili
Tasarım çalışmasının başında, yazılımın temel organizasyonu belirlenir. Mimari bir stil bu temel yapıyı tanımlar. Mimarlık modelleri, mimari tarzın teknik olarak somut tasarımıdır.
Mimarlık modelini seçerken hangi yönlerin rol oynadığını göstermek için, tıbbi bir termometre kullanarak ona bakmak istiyorum.
Dijital tıbbi termometre, hiyerarşik bir sistemin mimari tarzında düzenlenen birleştirilmiş bir sistemdir. Daha yüksek seviyede, aşağıdaki donanımı kullanan yazılımdır. Yazılımın kendisi de hiyerarşik olarak bölünmüştür. Bu, yazılımın en düşük seviyesinde donanımın kontrol edildiği donanım soyutlamasının olması gerçeğinden kaynaklanır.
Mimarlık modelinin seçimi bir mimarlık kararıdır. Bir geliştirme projesinin arka planına dayanarak, mimarlık kararları, teknik ve örgütsel kontur koşulları ile kararın çerçevesini oluşturan bir şirkette alınır.
İki mimari kalıbı sunacağım ve bakımla ilgili hususları tanımlayacağım. İki mimari modelin yapısını, aşağıdaki diyagramlarda bağımlılık temsili olmadan bloklarla çok basitleştirilmiş bir biçimde gösterdim.
Seviyede mimari
Yazılımın katmanlardaki yapısı yıllardır dolaşımda. Temel kavram, işlevleri düzenlemek için soyutlama seviyeleri oluşturmaktır. Katmanlarda, üst katmanlar sadece altta yatan katmanlara erişebilir. Bu, döngüsel bağımlılıkların bulunmadığını içermez. Seviyeler değiştirilebilir ve genel işlevsellik kalır. İnşaat sistemleri ile aşağıdaki mimari modeli yaygındır:
Baktığımda, termometre yazılımı üç katmana ayrıldı:
Notlar:
Bileşenler, sunulan arayüzler aracılığıyla sistem için belirli arayüzler sağlar. İşlevlerinde, bileşenler gerekli arayüzler aracılığıyla elde edilen daha fazla özelliğe ihtiyaç duyar.
Gerekirse bileşenler birbirinden bağımsız olarak geliştirilebilir. Ayrıca, bileşenler programlama dilinin çalışma zamanı kitaplıkları gibi teknik özellikler gerektirir. İşletim sistemi olmayan dahil edilen sistemlerle, bileşenler statik kitaplıklar olarak uygulanır.
Yeniden kullanılabilirlik, bileşenlerden yazılım oluştururken itici güçtür.
Burada gösterilen bileşen mimarisi aynı zamanda hiyerarşik bir mimari tarzdır. Uygulama seviyesi üst düzeydir ve gösterilen bileşenleri kullanır. Bileşenlerin bir hizmet düzeyi ve bir HAL vardır.
Bileşenlerin seviyesi ve mimarisinde mimarinin bakımının karşılaştırılması
En şaşırtıcı fark, birinci seviyedeki bileşen mimari yazılımının altıya ve mimarinin üç blokta seviyedeki olarak bölünmesidir. Bileşen mimarisi durumunda, yazılımın daha iyi bir bölümüne sahipsiniz.
Başka bir fark, bileşen mimarisinin işlevsel bloklar oluşturmasıdır. Kohezyon bir blok içindeki dayanışmayı tanımlar. Bileşenin işlevselliği belirtilir.
Kilit ADC, bileşenlerin mimarisinde birkaç kez meydana gelir.
Tıbbi bir termometrenin yazılımının bakımının karşılaştırılması
Farklılıkların değerlendirilmesi
Bileşen mimarisinin potansiyel avantajları, bileşenlerin arayüzleri uygulanırken daha fazla çaba ile satın alınır. Bakımın kalite özelliği sadece mimari modelin seçimi için belirleyici değildir. Daha önce de belirtildiği gibi, bir geliştirme projesinin arka planına bağlıdır.
Termometre gibi çok basit bir sistemle, yazılımı bileşenlere bölme çabası buna değmeyecektir. Ancak daha fazla karmaşık olan sistemler için veya ürünler veya cihazlardaki varyantlar söz konusu olduğunda, bileşenlerin bir mimarisi de basit sistemlerle mantıklı olabilir.
Her durumda, yazılım mimarisi çalışması bir geliştirme projesinin önemli bir parçasıdır. Kalite işlevselliğinin daha sonra uygulanması, başlangıçta dikkate alınmaktan daha pahalıdır.
Özet
Bir sonraki makalemde mimariyi mimari, borular ve filtreler, brokerler, model görünüm denetleyicisi ve reaktör açısından derinleştireceğim.
(RME)
Ne yazık ki, bu bağlantı artık geçerli değil.
Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.
Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!
İyi yazılım mimarisini nasıl tanıyorsunuz?
Bugün iyi yazılım mimarisi yapan şeyle ilgilenen Alexander Eisenhuth'un konuk katkısını sunmak istiyorum. Alexander, 1996'dan beri yazılımın mühendisliğinde bağımsız olarak çalışmaktadır. On yıldan fazla bir süredir, yazılım mimarından yazılım mimarisinin çalışmasındaki geliştirme ekiplerini bir yazılım mimarı olarak desteklemektedir. Alexander tutkusu hakkında yazıyor: iyi yazılım mimarisi.
Rainer Grimm yıllardır yazılım mimarı, ekip ve eğitim müdürü olarak çalıştı. C ++ programlama dilleri, Python ve Haskell hakkında makaleler yazmayı seviyor, ancak uzman konferanslarla konuşmayı da seviyor. Modern C ++ blogunda, C ++ tutkusuyla yoğun bir şekilde ilgileniyor.
“İyi yazılım mimarisini nasıl tanıyorsunuz?” Bu, web seminerinin sonunda “Agile yazılım mimarisi” konusundaki soru buydu. O zamandan önce katılımcı bu hikayeyi söyledi: “Yapılan yazılımımızla, artık genişletemeyeceğimiz noktaya ulaşıyoruz. Yazılım, cihazlarımızın ailelerini on yılı aşkın bir süredir desteklemektedir. Bir ürünün değişikliklerinden sonra, diğer ürünlerde beklenmedik davranışlar meydana gelir“.
Hiç böyle bir hikayeyi duydun mu? Bu nedenle yazılımın durumu “tarihsel olarak ekili” veya “büyük çamur topu” olarak da adlandırılır.
Kalite özellikleri cevaptır
Yazılımın iyi mimarisi ile ilgili soru basitçe bir cevaptır: iyi yazılım mimarisi, gerekli kalitenin özelliklerini uygularken tanınabilir. Yukarıdaki hikaye söz konusu olduğunda, yazılım bakımının kalitesinin bir parçasıdır. Prensip olarak, “tarihsel olarak ekili” yazılım bekliyor, sadece istenen ve profesyonel olarak doğru koşullara aktarmak pahalıdır. Sonuç her durumda tatmin edici değil:
- Yüksek çaba e
- İşlevselliğe ilişkin gerekli uzantılar muhtemelen birçok yazılım yerde dağıtılmaktadır.
Kalite özellikleri ISO 25010 kalite modelinde ayrıntılı olarak açıklanmaktadır. Kalite özelliklerinin yazılım yaşam döngüsünün farklı aşamalarını etkilediğini görebilirsiniz.
Kalite özelliklerinin önceliğinin önemli bir yönü vardır. Önemli, kritik ve ilgili olmayan niteliklerin özelliklerine ayrılabilirler.
Yazılımın veya sistemin kullanımı ve satışı olmadan kabul edilemez olduğu için kritik kalite özellikleri garanti edilmelidir. Bu kalite özelliklerine uyumu garanti etmek gerekir.
Yazılım mimarisi çalışmalarında önemli kalite özellikleri de gözlemlenmelidir, ancak derhal eleştirileri yoktur.
Sürdürülebilirlik genellikle önemli bir kalite özelliktir. Kötü bakımın etkisi, örneğimizin başlangıçtan itibaren gösterildiği gibi yıllar içinde belirgin hale gelmiştir.
Kalite özelliklerinin bakımı
Kalite özelliği, süreyi tüketen bakım faaliyetlerine sahip kalitenin yazılım üzerinde yapılabileceği anlamına gelir.
Bakım faaliyetleri:
- İşlevselliği genişletin: Yeni işlevsel gereksinimleri uygulayın,
- Analiz yapın: Hataların analizini veya statik kodun analizini gerçekleştirin veya yorumlayın,
- Programlama hatalarını ortadan kaldır
- Doğrulamayı gerçekleştirin: Değişikliklerden sonra hataların hariç tutulması.
Böylece bir ekip yukarıda listelenen faaliyetleri verimli bir şekilde yerine getirebilir, kaynak kodunun temelde uygun bir yapılandırmaya sahip olması özellikle önemlidir. Ekip, kaynak kodundaki işlevlerin nerede bulunduğunu ve yazılımın nasıl geliştirildiğini ve böylece yazılımın iyi beklemeye devam etmesi gerektiği açık olmalıdır. Bu yaklaşık olarak yazılım mimarisinin çalışmasının sonucudur:
- Mimarlık kararları
- Tasarım İşleri
- Kavramsal çalışma
Bakımı destekleyen kavramlar
Tipik teknik kavramlar, yazılımın bakımına ulaşmak için aşağıdaki tabloda listelenmiştir:
Tıbbi termometre örneğini kullanarak mimari ve mimari modeli stili
Tasarım çalışmasının başında, yazılımın temel organizasyonu belirlenir. Mimari bir stil bu temel yapıyı tanımlar. Mimarlık modelleri, mimari tarzın teknik olarak somut tasarımıdır.
Mimarlık modelini seçerken hangi yönlerin rol oynadığını göstermek için, tıbbi bir termometre kullanarak ona bakmak istiyorum.
Dijital tıbbi termometre, hiyerarşik bir sistemin mimari tarzında düzenlenen birleştirilmiş bir sistemdir. Daha yüksek seviyede, aşağıdaki donanımı kullanan yazılımdır. Yazılımın kendisi de hiyerarşik olarak bölünmüştür. Bu, yazılımın en düşük seviyesinde donanımın kontrol edildiği donanım soyutlamasının olması gerçeğinden kaynaklanır.
Mimarlık modelinin seçimi bir mimarlık kararıdır. Bir geliştirme projesinin arka planına dayanarak, mimarlık kararları, teknik ve örgütsel kontur koşulları ile kararın çerçevesini oluşturan bir şirkette alınır.
İki mimari kalıbı sunacağım ve bakımla ilgili hususları tanımlayacağım. İki mimari modelin yapısını, aşağıdaki diyagramlarda bağımlılık temsili olmadan bloklarla çok basitleştirilmiş bir biçimde gösterdim.
Seviyede mimari
Yazılımın katmanlardaki yapısı yıllardır dolaşımda. Temel kavram, işlevleri düzenlemek için soyutlama seviyeleri oluşturmaktır. Katmanlarda, üst katmanlar sadece altta yatan katmanlara erişebilir. Bu, döngüsel bağımlılıkların bulunmadığını içermez. Seviyeler değiştirilebilir ve genel işlevsellik kalır. İnşaat sistemleri ile aşağıdaki mimari modeli yaygındır:
Baktığımda, termometre yazılımı üç katmana ayrıldı:
- başvuru: Sistem uygulamalarını içerir. Bu durumda, pil tükendiğinde ateşin ölçümü ve davranışı.
- hizmet vermek: Uygulamaların uygulanabileceği profesyonel soyutlamalara erişim sağlar. Burada sıcaklıkları ölçme, bunları sunma ve raporlama için bir ses üretme yeteneği. Burada soyutlama seviyesinin gözlemlenmesi ve uygulama için donanım erişiminin türü hakkında hiçbir bilginin gerekli olmaması önemlidir.
- Donanım soyutlama seviyesi: Donanımı kontrol etmek için bir arayüz sunar
Notlar:
- ADC: Gerginlik ölçümü
- LCD: Reklam Kontrolü
- HAL: Donanım Soyutlama Seviyesi
Bileşenler, sunulan arayüzler aracılığıyla sistem için belirli arayüzler sağlar. İşlevlerinde, bileşenler gerekli arayüzler aracılığıyla elde edilen daha fazla özelliğe ihtiyaç duyar.
Gerekirse bileşenler birbirinden bağımsız olarak geliştirilebilir. Ayrıca, bileşenler programlama dilinin çalışma zamanı kitaplıkları gibi teknik özellikler gerektirir. İşletim sistemi olmayan dahil edilen sistemlerle, bileşenler statik kitaplıklar olarak uygulanır.
Yeniden kullanılabilirlik, bileşenlerden yazılım oluştururken itici güçtür.
Burada gösterilen bileşen mimarisi aynı zamanda hiyerarşik bir mimari tarzdır. Uygulama seviyesi üst düzeydir ve gösterilen bileşenleri kullanır. Bileşenlerin bir hizmet düzeyi ve bir HAL vardır.
Bileşenlerin seviyesi ve mimarisinde mimarinin bakımının karşılaştırılması
En şaşırtıcı fark, birinci seviyedeki bileşen mimari yazılımının altıya ve mimarinin üç blokta seviyedeki olarak bölünmesidir. Bileşen mimarisi durumunda, yazılımın daha iyi bir bölümüne sahipsiniz.
Başka bir fark, bileşen mimarisinin işlevsel bloklar oluşturmasıdır. Kohezyon bir blok içindeki dayanışmayı tanımlar. Bileşenin işlevselliği belirtilir.
Kilit ADC, bileşenlerin mimarisinde birkaç kez meydana gelir.
Tıbbi bir termometrenin yazılımının bakımının karşılaştırılması
Farklılıkların değerlendirilmesi
Bileşen mimarisinin potansiyel avantajları, bileşenlerin arayüzleri uygulanırken daha fazla çaba ile satın alınır. Bakımın kalite özelliği sadece mimari modelin seçimi için belirleyici değildir. Daha önce de belirtildiği gibi, bir geliştirme projesinin arka planına bağlıdır.
Termometre gibi çok basit bir sistemle, yazılımı bileşenlere bölme çabası buna değmeyecektir. Ancak daha fazla karmaşık olan sistemler için veya ürünler veya cihazlardaki varyantlar söz konusu olduğunda, bileşenlerin bir mimarisi de basit sistemlerle mantıklı olabilir.
Her durumda, yazılım mimarisi çalışması bir geliştirme projesinin önemli bir parçasıdır. Kalite işlevselliğinin daha sonra uygulanması, başlangıçta dikkate alınmaktan daha pahalıdır.
Özet
- Bakım, yazılım kalitesinin bir özelliğidir,
- En iyi yazılım bekliyor, bakım faaliyetleri için zamansal harcamalar (analiz, genişleme, doğrulama) e e e
- Yazılım mimarisi tarzının seçimi, olağanüstü bir alana sahip önemli bir mimari karardır.
- uygun bir yazılım mimarisi,
- Bakım için iyi teknik kavramlar e
- Uygun tasarım işleri.
Bir sonraki makalemde mimariyi mimari, borular ve filtreler, brokerler, model görünüm denetleyicisi ve reaktör açısından derinleştireceğim.
(RME)
Ne yazık ki, bu bağlantı artık geçerli değil.
Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.
Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!