4+1 View ve UML

Giriş

Bu yazıda artık pek kullanılmayan 4+1 View ve bunları göstermek için kullanılan UML çizelgeleri anlatılıyor. 

Modern Yorumu Nasıl?

4 + 1 View modası geçmiş gibi görünse de, çözümü/sistemi bir anlamda kağıda döktüğü için bence faydalı yönleri var. 4+1 View Rational Rose şirketindeki Philippe Kruchten tarafından ortaya konulmuştu. Alternatif olarak Simon Brown tarafından geliştirilen C4 Model kullanılabilir.

Modern kullanımı şuna benzer bir hale geldi :

- Scenarios View altındaki maddeler çevik süreçlerle birlikte projenin her döngüsünde yapılmaya başlandı

- Logical View altındaki Sequence Diagram, Activity Diagram artık çevik süreçlerde üretilen User Story/Use Case belgelerinin içine gömülmeye başlandılar. Ya da yanında ek olarak veriliyorlar.

- Development View altındaki Class Diagram, Package Diagram, Component Diagram artık çizilmiyor. Bunları IDE'ler zaten istenildiği anda üretebiliyor. Dolayısıyla çizmeye yok.

- Physical View altındaki Deployment Diagram bence halen lazım. Her ne kadar bir sürü altyapı Dashboard gibi şeyler verse de sistemdeki bilgisayarları, ağ yapısı vs. kuşbakışı görmek için gerekiyor.

Peki Ne Kaybettik?

- Aslında, en büyük kayıp bir anlamda mühendislik kültürünün erozyona uğraması oldu. Bir işe başlamadan önce etraflıca düşünüp taşınma alışkanlığı kalktı. Tabii ki bunlar benim gördüğüm örnekler.

- Ayrıca eskiden kod ile bu 4 +1 View çizelgelerinin senkron veya tutarlı gitmesine özen gösterilirdi. Ve hatta bu modellerden kod üretildiği için mecburen bu iş yapılırdı. 

Şu anda benim gördüğüm örneklerde kod ile üretilen belgeler arasında farklılıklar/kopukluklar olsa bile bunlar düzeltilmiyor.

UML
UML yazılımın tasarımını belirtmek için kullanılır. Tüm modellerde (CMMI gibi) olduğu gibi UML de geliştirme sürecinin (development process) nasıl olması gerektiğini belirtmez!

UML 2.0 ile Telekom dünyasında kullanılan SDL'de standarda dahil edilmiştir. Şu anda UML 2.5 mevcut ancak bir çok kitap yenilenmedi ve halen UML 2.0 sürümünü anlatıyor.

4+1 View
Neden lazım sorusunu cevabı şöyle

No solution is better then the other if you cannot present it well.

4+1 view bir çok kişi tarafından farklı UML çizelgelerini içerecek şekilde tarifleniyor. Özellikle Logical View kimin tariflediğine göre epeyce farklılıklar gösterebilir. 

4+1 View modelini ilk tarifleyen Philippe Krutchen makalesinde UML gösterimini kullanmadığı için her tarifleme doğru sayılabilir.

View'lar şeklen şöyle

Kullanım yerleri şöyle

1. Scenarios View       -> Requirements Gathering Phase
2. Logical View          -> Requirements Gathering Phase
3. Development View ->  Development/Implementation Phase
4. Process View          ->  Development/Implementation Phase
5. Physical View         ->  Development/Implementation Phase

Bu view'lardan Scenarios View ve Logical View projenin Requirements Gathering Phase denilen safhasında kullanılır deniliyor.

Process View, Development View, Physical View ise projenin Development/Implementation Phase denilen safhasında kullanılır deniliyor.

Aslında 4 +1 View eski bir yöntem olduğu için günümüzde pek uymuyor ve biraz eski bir anlayışı yansıtıyor.

Modern çevik (agile) süreçlerle birlikte projenin bu birbirini takip eden safhaları kalktı ve artırımsal (incremental) olarak yapılmaya başlandı.

1.Scenarios View aka Use Case View
Bu view'da sistemin son kullanıcı açısından ne iş göreceği anlatılıyor. Bu iş için :

1. Use Case Diagram veya

2. Scrum'daki gibi Kullanım Durumu (User Story) 

tercih edilebilir.

Use Case Diagram
Bir projeye başlarken ilk tasarlanan UML görünümü Kullanım Durumlarıdır. Gerekçesi ise Kullanım Durumlarının sistemi tanımlamasıdır. Kullanım Durumları bazen bir özellik  (feature) geliştirmek için de kullanılır.

Kullanım Durumları çizildikten sonra genellikle her bir Kullanım Durumunu detaylandıran  bir Sequence Diagram çizilir.

Bu aşama da geçildikten sonra Sınıf Çizelgeleri çizilirler.

Aktörler
Primary aktör sistemin onsuz yapamayacağı şeydir
Secondary aktör yardımcıdır.

Bir aktör farklı işleri yapsa dahi aynı kişiyse genel bir isim kullanmak en iyisi. Örneğin kullanıcı hem Buyer hem de Seller olabiliyorsa iki tane farklı aktör yaratmak yerine Person diye bir aktör yaratılmalı.

Use Case (Kullanım Durumu)
Sistemin gerçekleştirdiği işlevi belirtir.

Sistem

Sistem geliştirilen şeyin ne olduğunu belirtir. Aktörler sistemi kullanırlar ve belirtilen faaliyetleri gerçekleştirirler.

 Bir örnek şöyle

Tüm Kullanım Durumları

Tüm kullanım durumlarının (use case) seviyesel olarak beraber gösterimini ilk defa burada gördüm.

inlude ve extend
--> ile gösterilir. A includes B demek A yapılırken B'nin de yapıldığı anlamına gelir. A extends B demek A yapılırken B'nin yapılabileceği anlamına gelir.

2. Logical View

Bileşenler yönünden gösterilebilir. Bir örnek şöyle

Akışlar yönünden gösterilebilir. Açıklaması şöyle. Sistemin sağlayacağı işlevi son kullanıcıya akışlar şeklinde gösterir. Akışlar için Sequence Diagram ve Activity Diagram kullanılabilir.

Denotes the functionality a system provides to the end-user. The view defines and documents systems, stakeholders, interfaces, and their relationships. It provides a big picture view of how the solution fits in the enterprise architecture. 

This view helps you to convince enterprise architects that the solution architecture fits well within the enterprise architecture and goals. 

The logical view can be documented easily using the sequence diagrams and activity diagrams.  For integration projects sequence diagrams makes sense as it clearly depicts the flow of information between systems e.g. communication between a computer and a server:

Sequence Diagram
UML Sequence Diagram yazısına taşıdım.

Activity Diagram
UML Activity Diagram yazısına taşıdım.

3. Development View
Açıklaması şöyle. Kodun yapısıyla ilgili çizelgeler bulunur.

This view is about document how to code the 'solution', this documents the code and the packages involved in the project. For an integration solution, this view would generally contain the drag and drop flow or class interaction diagram between different components. Sometimes this view can be extended to show the branching/merging strategies as well. 

Class Diagram

UML Class Diagram yazısına taşıdım.

Package Diagram
UML Package Diagram yazısına taşıdım.

Component Diagram
Yazılımın mimarisini en üst seviyeden anlatan çizelgedir. Kimin kimle konuştuğunu gösterir. Bu çizelgede "kim" çizime göre değişir. Bazen birbiri ile konuşan sınıflar, bazen web servisleri, bazen UI ve veri tabanı gösterilir. Component Diagram'da bir bileşenin bağımlılıklarının gösterildiğini de gördüm.

4.Process View
Açıklaması şöyle. Eski anlayışa göre Development/Implementation Phase başladığı için bu aşamada da yine Sequence Diagram ve Activity Diagram çiziliyor ancak, Requirements Gathering Phase safhasına göre daha detaylı çiziliyorlar.

Talks about the process the integration facilitates/enables between the end systems. This view is typically very important as it is the link between the business problem and the technical solution. 

Sequence Diagrams and Activity Diagrams represent the process view:

Bir örnek şöyle

5. Physical View aka Deployment View
Açıklaması şöyle. Genellikle Deployment Diagram ile gösterilir.

Also known as the deployment view, this view is for a systems engineer or a DevOps person showing different aspects of the system involved.  Usually, for an integration project, the physical view can be used in conjunction with the deployment view where different 'physical aspects' of the system are shown and how they interact with each other.

Target audience: DevOps Team, Enterprise Support Team, System Engineers. 

Bir örnek şöyle

Deployment Diagram

Bu çizelgede sistemin fiziksel şekil gösterilir. Donanım, işletim sistemi, ağ, arayüzler belirtilir.

"In a deployment model the physical architecture of the system is defined. Try to start capturing early the physical deployment characteristics, the hardware, operating system, network, interfaces and the support software of the new system for the need of a disaster recovering."

Deployment Diagram'da Node'lar kendi başına çalışan cihaz veya bilgisayarları temsil eder. Node'ların içinde Package, bunların içinde ise Component'ler bulunabilir.