SDD Nedir?
Software Design Document. Yazılım modüllerinin anlatıldığı doküman.
SDD Yukarıdan-aşağıya (Top-Down) yaklaşımı göstermeli. Yukarıdan-Aşağıya yaklaşımda bütün daha küçük anlamlı parçalara bölünür. Küçük parçalar için soyut kavramlar ve iletişim için arayüzler kullanılır.
İçeriği Nasıldır?
SDD içinde aşağıdakine benzer başlıklar olur. Başlıklıları aynen aldım ve bazı örnekler yazdım.
1. Scope
1.1 Identification
Project Name : XYZ Program
Project Abbreviation :
Project Code :
alanları yazılır
1.2 Definitions
Tanımlar yazılır.
1.3 Document Overview
Bu alana tablo koyulur ve section'lar açıklanır
Section 2 : Lists documents referenced by this SDD
Section 3 : Defines system level architectural design decisions
Section 7 : Contains the acronyms used in this SDD
Overview kelimesi Summary veya Abstract kelimeleri gibi kısa dokümanlarda kullanılır. Foreword (Önsöz) ise kitap benzeri uzun dokümanlarda kullanılır.
2. Referenced Documents
2.1 Project Documents
2.2 Other Documents
3. CSCI-Wide Design Decisions
Genel kararlar ve sebepleri (rationale) açıklanır. Genel kararlara örnekler:
3.1. Design Methodology (Object Oriented Analysis and Design seçilmiştir)
3.2 Programming Language
Bir çok platformda çalışması için Java seçilmiştir. Embedded C++ seçilmiştir.
3.3 Operating System
Unix seçilmiştir veya Mission Critical bir sistem olduğu için Real Time OS seçilmiştir.
3.4 Abstraction Layers
Genel katmanlar anlatılır. OS specific çağrılar yerine örneğin I/O için X kütüphanesi/API'si kullanılacaktır.
3.5 Reused SW
Eğer daha önceden geliştirilmiş bir yazılım yeniden kullanılacaksa belirtilir.
3.6 Architectural Patterns
Örnek: Sistem publish/subscribe mimari örüntüsü üzerine kurgulanmıştır.
Notlar : CSCI-Wide Design Decision altında Planned Computer Resource Utilization başlığıyla kaynak kullanımının yazıldığı belgeler olabiliyor. Böyle bir başlık SDD'ye bence dahil edilmemeli, çünkü faklı platformlara yapılan kurumlara göre sonuç değişir. Sadece gerçek zamanlı aviyonik projelerde bu başlık bir anlam ifade edebilir.
4. CSCI Architectural Design
Mimari belli bir fikirden (idea) yola çıkar. Fikir genelleştirilmiş ve soyutlanmış kavramlara (concept) dönüştürülür. Kavramlar ise mimariye dönüşür. Kavram ve fikirleri SDD içinde Wikipedia gibi açıklamaya genelde ihtiyaç duyulmaz. Okuyan kişinin bunları bildiği farz edilir.
Çok Katmanlı Mimari
Genellikle monolitik bir uygulama sunucusu üzerinde tüm uygulama çalışır. Uygulama sunucusu dışında veritabanı, e-posta sunucusu gibi ana bileşenleri gösteren bir şekil çizilir.
Domain/Partition Mimarisi
CSCI içindeki domain/partition gibi mantıksal bölümlenmeler anlatılır. Sistemin etkileşimde bulunduğu dış arayüzlerden bahsedilir. Her bir domain/partition içinde çalışacak componentleri gösteren bir şekil çizilebilir. Veya domain/partition'lar arasındaki veri akışını gösteren bir Data Flow çizilebilir.
Stacked Mimari
Aşağıdaki gibi bir şekil çizilir ve bileşenlerin yukarıdan aşağı iletişimi belirtilir.
Micro Servici Mimari
Bir çok küçük servisin bir araya getirilmesi ile kurulan dağıtık yapı. İlk burada gördüm Amazon tarafından kullanılıyor.
4.1 CSCI Components
Milt STD 498 terminolojisinde componentler CSC'ye denk gelir. Component deyince ortak bir arayüzden türeyen sınıflar akla geliyor. CSC ise kalıtım yerine daha çok composition kullanan yazılım parçalarıdır.
Her bir CSC'ye Unit ID verilir. Bu ID Proje Kodu + Proje İsmi + Bileşen İsmi şeklinde olabilir.
Bu bileşenler CSC olarak açıklanabilir.
4.2 Concept of Execution
Bu kısımda yazılımın nasıl çalışacağı anlatılır.
State Transition Bakış Açısı:
A number of Software Units use Finite State Machine to control processing and protocols.
Each FMS has a list of states, events and actions....
Bir State Transition Diagram verilerek her state açıklanabilir. Örnek:
Initialization
Sistem açılışta OFF durumunda başlar. İlk olarak BIT işlemlerini gerçekleştirir. Önemli bir hata varsa FAILURE durumuna geçer. Yoksa ayarlı yükler. İşlem başarılı ise OPERATIONAL duruma geçer.
OFF
Sistem X sinyalini alınca kapanır.
Multi-Thread Bakış Açısı:
Initialization
Sistem N tane thread açar.
Sistem Kaynakları Bakış Açısı:
Initialization
Yazılım X portunu veya connection kanallarını açar.
A major design decision is to not use dynamic allocation/deallocation, processes, tasks during steady state operation of X.
Data Flow Bakış Açısı :
The major data flows and interaction between the Software Units is shown in the following sections.
X Transmission Data Flows
...
X Reception Data Flows
...
4.3 Interface Design
Dış arayüzün bit/byte seviyesinde belirtildiği belgeye atıfta bulunan bir cümle yazılır
5 CSCI Detailed Design
Detaylı tasarım genelde bir UML aracına girildiği için, bu araca atıfta bulunan bir cümle yazılır.
6 Requirements Traceability
7. Notes
7.1 Acronyms : Kısaltmalar açıklanır
7.2 Glossary of Terms : Kavramlar açıklanır
SDD Gözden Geçirilirken Nelere Dikkat Edilir?
SDD Kontrol Listesi - CheckList yazısına taşıdım.
Software Design Document. Yazılım modüllerinin anlatıldığı doküman.
SDD Yukarıdan-aşağıya (Top-Down) yaklaşımı göstermeli. Yukarıdan-Aşağıya yaklaşımda bütün daha küçük anlamlı parçalara bölünür. Küçük parçalar için soyut kavramlar ve iletişim için arayüzler kullanılır.
İçeriği Nasıldır?
SDD içinde aşağıdakine benzer başlıklar olur. Başlıklıları aynen aldım ve bazı örnekler yazdım.
1. Scope
1.1 Identification
Project Name : XYZ Program
Project Abbreviation :
Project Code :
alanları yazılır
1.2 Definitions
Tanımlar yazılır.
1.3 Document Overview
Bu alana tablo koyulur ve section'lar açıklanır
Section 2 : Lists documents referenced by this SDD
Section 3 : Defines system level architectural design decisions
Section 7 : Contains the acronyms used in this SDD
Overview kelimesi Summary veya Abstract kelimeleri gibi kısa dokümanlarda kullanılır. Foreword (Önsöz) ise kitap benzeri uzun dokümanlarda kullanılır.
2. Referenced Documents
2.1 Project Documents
2.2 Other Documents
3. CSCI-Wide Design Decisions
Genel kararlar ve sebepleri (rationale) açıklanır. Genel kararlara örnekler:
3.1. Design Methodology (Object Oriented Analysis and Design seçilmiştir)
3.2 Programming Language
Bir çok platformda çalışması için Java seçilmiştir. Embedded C++ seçilmiştir.
3.3 Operating System
Unix seçilmiştir veya Mission Critical bir sistem olduğu için Real Time OS seçilmiştir.
3.4 Abstraction Layers
Genel katmanlar anlatılır. OS specific çağrılar yerine örneğin I/O için X kütüphanesi/API'si kullanılacaktır.
3.5 Reused SW
Eğer daha önceden geliştirilmiş bir yazılım yeniden kullanılacaksa belirtilir.
3.6 Architectural Patterns
Örnek: Sistem publish/subscribe mimari örüntüsü üzerine kurgulanmıştır.
Notlar : CSCI-Wide Design Decision altında Planned Computer Resource Utilization başlığıyla kaynak kullanımının yazıldığı belgeler olabiliyor. Böyle bir başlık SDD'ye bence dahil edilmemeli, çünkü faklı platformlara yapılan kurumlara göre sonuç değişir. Sadece gerçek zamanlı aviyonik projelerde bu başlık bir anlam ifade edebilir.
4. CSCI Architectural Design
Mimari belli bir fikirden (idea) yola çıkar. Fikir genelleştirilmiş ve soyutlanmış kavramlara (concept) dönüştürülür. Kavramlar ise mimariye dönüşür. Kavram ve fikirleri SDD içinde Wikipedia gibi açıklamaya genelde ihtiyaç duyulmaz. Okuyan kişinin bunları bildiği farz edilir.
Çok Katmanlı Mimari
Genellikle monolitik bir uygulama sunucusu üzerinde tüm uygulama çalışır. Uygulama sunucusu dışında veritabanı, e-posta sunucusu gibi ana bileşenleri gösteren bir şekil çizilir.
Domain/Partition Mimarisi
CSCI içindeki domain/partition gibi mantıksal bölümlenmeler anlatılır. Sistemin etkileşimde bulunduğu dış arayüzlerden bahsedilir. Her bir domain/partition içinde çalışacak componentleri gösteren bir şekil çizilebilir. Veya domain/partition'lar arasındaki veri akışını gösteren bir Data Flow çizilebilir.
Stacked Mimari
Aşağıdaki gibi bir şekil çizilir ve bileşenlerin yukarıdan aşağı iletişimi belirtilir.
Bir çok küçük servisin bir araya getirilmesi ile kurulan dağıtık yapı. İlk burada gördüm Amazon tarafından kullanılıyor.
4.1 CSCI Components
Milt STD 498 terminolojisinde componentler CSC'ye denk gelir. Component deyince ortak bir arayüzden türeyen sınıflar akla geliyor. CSC ise kalıtım yerine daha çok composition kullanan yazılım parçalarıdır.
Her bir CSC'ye Unit ID verilir. Bu ID Proje Kodu + Proje İsmi + Bileşen İsmi şeklinde olabilir.
Bu kısımda aşağıdaki sorular cevaplar verilir.
What are the components of the system.How are the components connected.What are each components responsibilities
Her CSC daha da alt parçalara kırılabilir. Alt parçalara "Software Unit", "Component" gibi isimler verdildiğini gördüm. Bence CSC zaten component olduğu için component içinde component kullanılması doğru değil. En güzeli CSC'nin alt kırımlarına hiç girmemek diye düşünüyorum.
Klasik bir CSCI içindeki CSC yani Component'ler
Bir CSCI genellikle birden fazla başka sistemle iletişim içinde olurlar. Örneğin iki farklı cihazla konuşuyor olalım. Her cihaz için gerçekleştirilen arayüz birer bileşendir. Yazılımın dış dünya ile iletişim kurduğu her bir arayüz bir CSC olarak düşünülebilir. Ayrıca tüm bileşenlerin aldığı verdiği mesajları işleyen bir çekirdek te bileşen olarak tasarlanabilir.Bu bileşenler CSC olarak açıklanabilir.
4.2 Concept of Execution
Bu kısımda yazılımın nasıl çalışacağı anlatılır.
State Transition Bakış Açısı:
A number of Software Units use Finite State Machine to control processing and protocols.
Each FMS has a list of states, events and actions....
Bir State Transition Diagram verilerek her state açıklanabilir. Örnek:
Initialization
Sistem açılışta OFF durumunda başlar. İlk olarak BIT işlemlerini gerçekleştirir. Önemli bir hata varsa FAILURE durumuna geçer. Yoksa ayarlı yükler. İşlem başarılı ise OPERATIONAL duruma geçer.
OFF
Sistem X sinyalini alınca kapanır.
Multi-Thread Bakış Açısı:
Initialization
Sistem N tane thread açar.
Sistem Kaynakları Bakış Açısı:
Initialization
Yazılım X portunu veya connection kanallarını açar.
A major design decision is to not use dynamic allocation/deallocation, processes, tasks during steady state operation of X.
Data Flow Bakış Açısı :
The major data flows and interaction between the Software Units is shown in the following sections.
X Transmission Data Flows
...
X Reception Data Flows
...
4.3 Interface Design
Dış arayüzün bit/byte seviyesinde belirtildiği belgeye atıfta bulunan bir cümle yazılır
5 CSCI Detailed Design
Detaylı tasarım genelde bir UML aracına girildiği için, bu araca atıfta bulunan bir cümle yazılır.
6 Requirements Traceability
7. Notes
7.1 Acronyms : Kısaltmalar açıklanır
7.2 Glossary of Terms : Kavramlar açıklanır
SDD Gözden Geçirilirken Nelere Dikkat Edilir?
SDD Kontrol Listesi - CheckList yazısına taşıdım.
Hiç yorum yok:
Yorum Gönder