MILT STD 498 - SSDD - System/Subsystem Design Document

System/Subsystem Design Document (SSDD)
SSDD içinde genellikle aşağıdakine benzer başlıklar olur.

1. Scope
2. Referenced Documents
3. System-Wide Design Decisions
 3.1 General Design Decisions - Buraya her türlü şey yazılabilir. Kullanılacak dosya formatından, sembolojiye, programlama diline ve metodolojiye kadar ilgili ilgisiz her şey belirtilebilir. 

Aslında genel kararları yazmak önemli olabiliyor. Açıklaması şöyle

Part of maintaining quality architecture requires an understanding of how the current architecture has evolved over time, and what the decisions, assumptions, and constraints at critical points in time.

Örnek 1

Operating System :  System will be based on POSIX API and will run on any POSIX compliant    system.
 Rationale : POSIX provides a general purpose interface between the operating system and the  software.

Örnek 2

 Positional Data : Positional data will be in WGS-84 format
 Rationale : WGS-84 is a widely used standard

Örnek 3

 Logging : System will use multi-level logging.
 Rationale : Multi level logging increases maintainability of the system

Örnek 4

 Fault Management : Fault management and redundancy will be provided.

4. System Architectural Design
 4.1 System Components
  4.1.1 Hardware Architectural Design
  4.1.2 Software Architectural Design
  Yazılımın bir taxonomy içine almak kolay değil. Burada yazılımın uyacağı açık sistem standardını belirtmek faydalı olur. Örnek:

The system shall be based on X (e.g J2EE) architecture.

 Bazı yazılım özellikleri şöyle. Belki bunlar vurgulanabilir.

• Open source vs. proprietary
• Publicly available vs. in-house only
• Extensible API or not?
• Plugin support?
• Platform (i.e. what infrastructure does it depend upon)
• Extent of specific customisation for user / company
• Scriptability (i.e. embeds own programming language for users)
• Client type (web vs. desktop GUI vs. console app vs. REST API etc.)
• Monolithic structure vs. composable components?
• Support for distribution (clustering, redundancy failover etc.)
• Stable vs. experimental (in development)

Failover
Elimizde bir broker olsun. Client A'nın isteklerini Broker MainSubscriber'a versin. O da veri tabanına yazdın. Eğer MainSubscriber istekleri zamanında işleyemiyorsa, Broker isteği FailoverSubscriber'a versin. Şöyle yaparız.

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

Diğer
Eğer herhangi bir referans mimari kullanılmıyorsa, mimarinin modüler ve katmanlı olduğu        yazılabilir. Sebep olarak ta çok katmanlı mimarinin (multi-layered) kohezyonu (cohesion)
 artırdığı ve coupling'i azalttığı, böylece test edilebilir ve idame ettirilebilir bir yazılım olduğu  belirtilebilir. Layered Architecture için açıklama şöyle

The idea of the Layered Architecture is that each layer provides an abstraction to the previous layer, so a layer depends only on the previous layer.

 Yazılım katmanları bir şekil ile gösterilebilir. Örneğin şekilde en alta ara katman/iletişim katmanı        konulur. Üstüne "ortak işlevler", daha üste "ortak servisler", en üste ise modüller konulur.

 4.2 Concept of Execution
Concept of Execution sistemin ana bileşenleri arasındaki etkileşimi göstermek amacıyla UML Sequence Diagram'ları ile gösterilebilir. Bu kısma alternatif akışları koymak gereksizdir.
 4.3 Interface Design
5. Requirements Traceability (SSS -> SSDD arasındaki izlenebilirlik)
6. Notes