Hai, nama saya Vladimir Ivanov dan saya seorang arsitek perangkat lunak di EPAM. Dalam pekerjaan saya, saya terus-menerus harus mendokumentasikan solusi perangkat lunak yang akan dibuat. Saya memutuskan untuk membagikan beberapa aspek dari kegiatan ini dengan Anda, karena Anda mungkin juga merasa berguna.
Bagaimana Anda menggambar diagram untuk perangkat lunak Anda? Pertanyaan apa yang harus mereka jawab? Mengapa menggambar sesuatu? Mari kita cari tahu.
Salah satu tanggung jawab arsitek solusi adalah mendokumentasikan arsitektur tersebut sehingga dapat diteruskan ke semua pemangku kepentingan proyek: manajer proyek, CTO, sponsor proyek, tim pengembangan, QA, dan lain-lain. Ini diperlukan untuk:
- memahami komponen apa yang terdiri dari sistem;
- bagaimana komponen ini berkomunikasi satu sama lain;
- bagaimana dan di mana letak elemen-elemen yang berbeda;
- apakah sistem secara keseluruhan memenuhi persyaratan.
Kurangnya informasi ini dapat dengan mudah menyebabkan tenggat waktu proyek terlewat, lembur, atau pembatalan.
Foto oleh ThisisEngineering RAEng / Unsplash
Mari pertimbangkan contoh
. , , — - , . , . , - , , . Ghost CMS, MySQL; - Apache. -, http https CMS. CMS , , . GCP . , -, . . , :
- , , :
- . - , .
- . , , : ; ; ; . .
- . . , ? ?
(views) “ ”(viewpoints), " " SEI, . :
- .
- , .
- , , , .
(- -, C4 . .), , . , .
— , ( ):
· ,
· ,
· ,
· -,
· .
:
, : . , :
?
(Context Diagram, C4), , . "". , , , , .
?
Deployment Diagram
, Google, , IAM. , (20-30 ), , . , .
, , .
, . , .
?
, CMS . , - , . , CMS .
, .
, Views. , - , , « ». .