Cumhuriyet Üniversitesi Yazılım Mühendisliği Dersi Bölüm 4 TASARIM-1 Halil ARSLAN Abdulkadir ŞEKER

Bölümün hedefleri Üst-düzey tasarım Amaç Cevaplanması gereken sorular Donanım, Güvenlik, Veritabanı, Mimariler … UML Yapısal Diyagramlar Davranış Diyagramları Etkileşim Diyagramları

Üst-düzey Tasarım Üst-düzey tasarımın amacı nedir? Büyük Resim Üst-düzey tasarım sistemin soyut bir seviyeden görüntülenmesini sağlar. Bitmiş bir uygulamanın parçalarının bir bütün içerisinde nasıl durduğunu ve nasıl etkileşime girdiğini gösterir. Uygulamanın çalışacağı ortamı tanımlar, Uygulamayı geliştirmek için kullanılacak yazılım ve donanım bileşenlerini tanımlar, Üst-düzey tasarım modüllerin ayrıntılarıyla ilgilenmez, Büyük Resim Yazılım geliştirmeyi, bir uygulamanın uygulanabilecek (kullanılabilecek) en küçük parçasına ayırma işlemi olarak görebilirsiniz. Bu ayırma işleminin ilk adımı üst-düzey tasarımla başlar. Amaç, kendi kendine yeterli ve ayrı ekiplerce uygulanabilir sistem bileşenlerini belirlemektir. KİŞİ EKLEME Mevcut bir görevi daha küçük parçalara ayırarak insanları bir projeye ekleyebilir ve gelişimi hızlandırabilirsiniz. Oysa, eski görevlere yeni insanlar eklemek genellikle işe yaramaz. Genellikle yeni insanlar birbirlerinin yoluna girdikçe gelişmeyi yavaşlatırlar. Ancak, büyük bir görevi daha küçük parçalara ayırabilir ve bu parçaları farklı insanlara atayabilirseniz. Bu durum bazı şeyleri hızlandırabilirsiniz.

Üst-düzey Tasarım Büyük Resim Bazı projelerde, projenin birden fazla parçasını tek bir takıma atamak isteyebilirsiniz. Özellikle parçalar birbirine yakınsa. Bu parçaları geliştiren insanlar birbirleriyle yakın bir şekilde çalışması gerekiyorsa faydalı olacaktır. Bu tür yakın işbirliğinin yararlı olduğu diğer bir durum, uygulamanın birkaç parçasının aynı veri yapısıyla veya aynı veritabanı tablolarıyla çalıştığı durumlardır. Veri yapısını veya tabloları tek bir ekibin kontrolü altında tutmak, ilgili parçaların senkronizasyonunu kolaylaştırır.

Üst-düzey Tasarım TANIMLANMASI GEREKENLER Her yazılım projesi özelinde üst-düzey tasarımda belirtilmesi gerekenler farklılıklar içerse de genel olarak aşağıdaki tanımlar yapılmalıdır. Güvenlik Donanım Kullanıcı arayüzü, Dahili arayüzler, Harici arayüzler Mimari (Monolitic, istemci/sunucu, Bileşen tabanlı, Servis tabanlı vb.) Raporlar ve diğer çıktılar Veri tabanları Yapılandırma verileri Veri akışı ve durumlar Eğitim

Tasarım tanımları Güvenlik Üst-düzey tasarımınız, uygulamanın güvenlik gereksinimlerini sağlamalıdır. Bu gereksinimler aşağıdaki gibi olabilir; İşletim sistemi güvenliği: Giriş prosedürlerinin türünü, parola geçerlilik ilkelerini ve parola standartlarını içerir. (Parolanızın en az bir harf, bir rakam, # veya % gibi özel bir karakter içermesi gibi.) Uygulama güvenliği: Bazı uygulamalar işletim sisteminin güvenliği dışında kendi kullanıcı yönetimine ihtiyaç duyar. Uygulama güvenliği, aynı zamanda, farklı kullanıcılara doğru yetki seviyesinde erişim sağlanması anlamına gelir. Örneğin, bazı kullanıcıların sistemin her bölümüne erişmesine izin verilmeyebilir. Veri güvenliği: Müşterilerin kredi kartı bilgilerinin bilgisayar korsanlarının eline geçmediğinden emin olmak gerekir. Ağ güvenliği: Uygulama ve veriler güvenli olsa bile, siber saldırılarla veriler ağdan çalınabilir. Fiziksel güvenlik: Birçok yazılım mühendisi fiziksel güvenliği görmezden gelse de uygulama açıkken dizüstü bilgisayarın çalındığı durumlar olabilir. Şifreleri çok sık sıfırlarsanız kullanıcılar, hatırlaması daha kolay ve muhtemelen bilgisayar korsanlarının tahmin etmesini kolaylaştıracak şifreleri seçecektir. Parola kurallarını çok sıkı hale getirirseniz (kullanıcılar, klavyenin her satırından iki karakter yazabilir) ve parolalarını bulmaları kolay olan bir yere yazabilir. Rutin işlemler için yönetici onayını gerekli kılarsanız, yönetici rutin işlere zaman ayıramayacağı için şifresini yetkisiz personellerle paylaşmak zorunda kalabilir.

Tasarım tanımları Donanım Üst-düzey tasarımınız, uygulamanın kullanılacağı donanımları belirtmesi gerekir. Bunlar; Masaüstü, Dizüstü, Tablet, Telefon, PDA Giyilebilir cihazlar (gözlük, saat, bileklik vb.) Yazıcılar Ağ bileşenleri (kablolar, modemler, ağ geçitleri, yönlendiriciler) Sunucular (Veritabanı, web, uygulama sunucuları) Özel ekipmanlar (GPS, sensör vb) Ses ve video donanımlar (web kamera, kulaklık, VoIP) Çoğunlukla, donanımları belirlemek uygulamanın bir web tarayıcısında çalıştığı durumlarda kolaydır.

Tasarım tanımları Kullanıcı arayüzü Dahili arayüzler Üst-düzey tasarımda, kullanıcı arayüzleri kabaca tanımlanabilir. Örneğin uygulamanın temel navigation (gezinme) mantığı belirlenebilir. Uygulamanın içereceği formlar ve ekranlar tasarlanabilir, Bu tasarımların kullanıcı gereksinimlerine cevap verip vermediği doğrulanabilir, Uygulamanın çalışma şeklini değiştirmek için iyi bir nedeniniz yoksa kullanıcıların alışkanlıklarına uygun arayüzler hazırlayın. Dahili arayüzler Program parçalarının birbirleriyle nasıl haberleşeceği tanımlanmalıdır. Nesne referansı, web servisler, TCP soketler vb. Başlangıçta iki parça için arayüzler kesin olmasa da geçici arayüzler tanımlanabilir. Sahte verilerle dolu JSON dosyası gibi

Tasarım tanımları Harici arayüzler Uygulamanın farklı sistemler ile etkileşime girdiği arayüzler tanımlanmalıdır. Mail server, Veritabanları, Satış Uygulamaları, İnsan Kaynakları Sistemleri, vb. olabilir. Harici arayüzleri tanımlamak kısmen daha kolaydır. Zaten bu uç sistem standartları bellidir. Ancak sizin uygulamanızın başka sistemlere harici arayüz sunması gerektiği durumlar da olabilir. Uygulamanızın başka sistemlere hizmet vermesi gerekebilir. Bu durumda uygulamanın ileriye dönük olarak gereksinim duyabileceği harici arayüzleri tanımlanmalıdır. Rest, Pub/Sub, RPC vb.

Tasarım tanımları / Mimari Uygulama mimarisi, yüksek seviyede tasarlanan parçların birbirleriyle nasıl birleştirileceğini ifade eder. Uygulama mimarilerindeki temel yaklaşım parçalar arası etkileşimi azaltarak, bileşenlerin geliştirme süreceni basitleştirmektir. Monolitic Mimari Bu mimaride program tek bir parçadan oluşur. En önemli dezavantajı uygulama parçaları birbirlerine sıkı sıkıya bağlı olduğundan, esneklik zordur. Ayrıca sistemin tüm parçaları başta belirlenmelidir. Yanlış alınan kararlar sistemin tümünü etkileyebilir. En önemli avantajı ise tüm bileşenler tek bir yapı üzerinde olduğu için bileşenler arasında karmaşık bir iletişim olmaz. Küçük uygulamalarda ve bir programcının çalıştığı yapılar için uygundur.

Tasarım tanımları / Mimari İstemci/Sunucu (client/server) Mimari Bu model, belirli işlevlerin (istemci) bu işlevleri sunan sistem parçalarından (sunucu) ayrılmasını temel almaktadır. Böylece geliştiricilerin, sistemin sunucu ve istemci bileşenlerinde ayrı ayrı çalışabilmelerine olanak sağlanır. Katman sayısı 3’ten fazlaysa n-tier olarak anılır. Three-tier 1- Veritabanını doğrudan uygulamaya entegre edilebilir. Sorun, birden fazla arayüzün aynı verileri kullanamamasıdır. 2- İstemcinin (kullanıcı arabiriminin) sunucudan (veritabanı) ayrıldığı iki katmanlı bir mimaridir. İstemciler ve sunucu, LAN, WAN veya Internet üzerinden iletişim kurabilir. İstemci sunucu bağımlılığı yüksektir. 3- İstemci ve sunucu arasına başka bir katman eklenir. İstemciler ve sunucu arasındaki ayrım kolaylaşır. Orta katman istemcilerle veritabanını yalıtır. Veritabanı değişirse sadece orta katman değiştirilmelidir. Terminolojide; Kullanıcı katmanı, presentation tier; Orta katman, logic tier; Veritabanı katmanı, data tier olarak adlandırılır. Two-tier One-tier

Tasarım tanımları / Mimari Bileşen tabanlı (component-based) Mimari Bileşen tabanlı mimari, gevşek şekilde bağlanmış, birbirleri için hizmet sağlayan bileşenler topluluğudur. Örneğin çalışanların iş saatlerini planlamak için yazılan bir sistemde; The Assign Employee Hours kullanıcı arayüz bileşeni, boş çalışma saatlerini öğrenmek için Shift Hours Available bileşeni, bir çalışanın hangi saatlerde çalıştığını öğrenmek için Employee Hours Available bileşenini kullanabilir. Bileşen tabanlı mimari, çok katmanlı mimarinin yaptığı gibi kod parçalarını ayırır fakat bu bileşenler aynı program içerisinde yer alır. İletişim bir ağ arayüzü yerine, doğrudan gerçekleşir.

Tasarım tanımları / Mimari Servis Tabanlı Mimari (SOA) Servis tabanlı mimari (SOA), sistem parçalarının servis olarak tanımlandığında bileşen tabanlı bir mimariye benzer. Bir servis, kendi başına çalışan ve istemciler için bir çeşit hizmet sunan programlardır. Hizmetler çoğunlukla web servisi olarak tanımlanır. Hizmetler belirli standartları sunan programlardır ve kolayca çağırılabilirler. Veri-merkezli Mimari (Data‐Centric) Veri merkezli yada veritabanı merkezli mimari, tüm verileri merkezi bir şekilde kullanan çeşitli araçlar sunar. İş mantığını uygulamak için veritabanında stored procedure’ler kullanmak bu yapılara örnek verilebilir. Verileri diğer mimarilerde kullanmak için basit/ara teknik olarak düşünülebilir.

Tasarım tanımları / Mimari Olay Tabanlı Mimari (Event‐Driven) Bu mimaride sistem bileşenleri ortaya çıkan olaylara cevap vermek üzere kurgulanır. Örneğin, sipariş sevk edildiğinde bir faturalandırma modülü faturayı yazdırabilir. Müşteri faturasının 30 gün sonunda ödemediğinde sistem icra çıkarabilir. Rol Tabanlı Mimari (Rule-Based) Kural tabanlı mimari sistemin ne yapacağına karar vermesi için bir dizi kural çıkarılır. Bazen bu sistemlere uzman sistemler de denir. Bu sistemler WhatIf senaryolarıyla çalışır. Sistemde kurallar net değilse önemli sorunlar oluşabilir.

Tasarım tanımları / Mimari Dağıtık Mimari (Distributed) Dağıtık mimaride uygulama bileşenleri farklı işlemcilerde aynı zamanda çalışabilir. İşlemciler, ağda dağıtılmış farklı bilgisayarlar yada bir işlemcinin farklı çekirdekleri olabilir. Genel olarak dağıtık uygulamalar karışık ve hata ayıklaması zor sistemlerdir. Dağıtılmış mimarilerde Yarış Durumu (Race Condition) ve diğer potansiyel paralel hesaplama sorunlarının dikkatlice planlanması gerekir. Karma (Mix) Mimariler Bir uygulamanın tek bir mimariye bağlı geliştirilmesi gerekmez. Sistemin bir parçası bir mimariyle başka bir parçası da başka bir mimariyle geliştirilebilir. Ancak genel yaklaşım, genel bir mimari temelinde küçük alt mimarilerdir.

Tasarım tanımları Raporlar Diğer Çıktılar Büyük bir uygulama düzinelerce rapor içerebilir. Müşteriler mevcut sistemde kullandıkları raporları yeni sistemde de isteyebilir. Yeni sisteme özgü yeni raporlar da isteyebilir. Basit bir uygulamada dahi kullanıcı rapor istemese de uygulamayı kim, nerede, ne zaman, ne kadar kullanmış gibi raporları uygulamanızı iyileştirmek için isteyebilirsiniz. Üst-düzey kullanıcı arayüzü tasarımında olduğu gibi her bir rapor için tüm ayrıntının verilmesine gerek yoktur. Hangi rapora ihtiyaç duyulduğuna karar verip, ayrıntıları alt-seviye tasarıma ve geliştirme sürecine bırakmalıyız. Diğer Çıktılar Uygulama normal raporlara ek olarak web sayfaları, ses ve görüntü dosyaları, e-posta ve kısa mesaj gibi çıktılar gerektirebilir.

Tasarım tanımları Veritabanı Veritabanı tasarımı çoğu uygulamanın önemli bir parçasıdır. Veritabanı tasarımının ilk kısmı uygulamanın ne tür bir veritabanına ihtiyaç duyduğunun belirlenmesidir. Uygulamanın verileri XML, metin dosyası, ilişkisel veritabanı yada geçici veritabanları gibi ne tür bir yapıda tutacağının kararlaştırılması gerekir. Herhangi bir veritabanına ihtiyaç duymayan uygulamalar dahi bir takım verileri array, list veya başkaca diğer veri yapılarında saklayabilir. Harici bir veritabanı kullanmaya karar verildiğinde hangi tür bir veritabanı kullanılacağı belirtilmelidir. SQL Server, MySql, Oracle vb. İlişkisel bir veritabanı kullanıldığında ilgili tabloları ve tablo ilişkileri oluşturulabilir. Üst-düzey tasarımda veritabanı noktasında ele alınması gereken 3 temel sorun; Denetim (Audit), Kullanıcı Erişimi ve Bakımdır.

Tasarım tanımları / Veritabanı Denetim izleri (Audit Trails) Bir denetim izleri herhangi bir veriyi değiştiren her işlemin ve kullanıcının kaydını tutar. Bu izler bir geçmiş (log) tablosu şeklinde olabileceği gibi bir tablo içerisine değiştirilen kayıtların aktifliğini kaldırıp değişikliği yeni kayıt şeklinde tanımlayarak da yapılabilir. Bu kayıtlar taranarak kullanıcılara ait işlemler takip edilebilir. Kullanıcı erişimi (User Access) Birçok uygulama türü farklı veri türlerine farklı seviyelerde erişim sağlar. Örneğin sıradan bir çalışanın başka çalışanların maaşlarını görmesi istenmez. Bunun bir yolu kullanıcı yetkilerini (privileges) düzenleyen bir tablo olabilir. Bu yetkilendirme tablo bazında olabileceği gibi bazı tabloların bazı alanlarına özgü de olabilir.

Tasarım tanımları / Veritabanı Veritabanı bakımı (Maintenance) Veritabanları zamanla dağınıklaşır ve çöplerle dolar. Veritabanı zamanla Audit Log’larla şişer. Bu durumda kullanılmayan verileri depolama birimlerine taşımanız gerekebilir. Eski verilere erişim durumlarını da modellemeniz gerekebilir. Bir daha ihtiyaç duyulmayacak veriler tamamen silinebilir. Eski verileri silmek veri boyutunu azaltarak yanıt sürelerini hızlandırsa da veritabanı index’lerini verimsizleştirerek performansa zarar verebilir. Bu nedenle index tablolarının periyodik olarak yeniden organize edilmesi gerekir. Bu tür gürevler sistemin boş olduğu 02.00’da yapılması tercih edilir. Ayrıca veritabanını yedeklemek ve kurtarmak için senaryolar hazırlanmalıdır. Her gece backup almak vb. Bu tür veritabanı bakım süreçleri çoğunlukla programlama gerektirmeyen ve VTYS’lerinin sunduğu araçlarla halledilebilecek niteliklerdir. VTYS: Veri Tabanı Yönetim Sistemi.

Tasarım tanımları Yapılandırma Verileri (Configuration Data) Eğitimler Uygulamanın kullandığı bir takım değerleri kişiye yada sisteme özgü yapılandırılabilir yapmak uygulama bakımını kolaylaştırır. Örneğin bir ödeme uygulamasının 30 günde ödemesini yapmayan kullanıcıya uyarı veren bir durumunun istenildiğinde değiştirilebilir olması bakımı kolaylaştırır. Burada önemli olan bazı parametreleri sadece belli yetki seviyesine sahip kullanıcıların yapabilmesine olanak sunulmalıdır. Sadece yöneticiler gibi. Eğitimler Eğitim için üst-düzey tasarım erken olsa da tasarım başlamalıdır. En azından eğitim süreçleri temel anlamda tasarlanabilir. Eğitim tasarımları uygulamanın üst-düzey amacını içerecek şekilde başlar ve proje geliştikçe içerik sonradan doldurulabilir.

Tasarım tanımları Veri Geçişleri ve Durum Diagramı Birçok uygulama farklı süreçler arasında akan verileri kullanır. Örneğin bir müşteri siparişi Sipariş Oluşturma işleminden başlar, Siparişin Paketlenmesine gider ve daha sonra Gönderime geçer. Veriler daha sonra Nakliyeye ve son olarak Faturalandırma sürecine gidir. Veri akışında geçişler bir durumla ifade edilebilir. Müşteri siparişinde durumlar; Oluşturulmuş, Paketlenmiş, Gönderilmiş ve Faturalandırılmış olarak tanımlanır. Bu tür diyagramlar sistemin ve süreçlerin veriyle etkileşimde bulunuş biçimini tanımlar.

Tasarım tanımları Created: Oluşturma Assembled: Paketleme Shipped: Gönderme Billed: Faturalandırma Late: Geçikme Paid: Ödeme Delinquent: Borcunu ödemeyen Closed: Kapatıldı

UML Unified Modeling Language (UML) (Birleştirilmiş Modelleme Dili), sistemin farklı parçalarını temsil etmek için kullanılan diyagramlardır. Kar amacı gütmeyen uluslararası bir organizasyon olan Object Management Group UML standartlarını tanımlar (www.uml.org). UML 2.0, 3 kategoride (biri alt kategori) 13 farklı diagram tipini tanımlar.

UML

UML Yapısal Diyagramlar (Structure) Bu diyagramlar sistemde varolan tüm nesneleri tanımlar. Örneği Class (sınıf) diyagramı, sistemdeki nesneleri temsil edecek sınıfları ve sınıflar arası ilişkileri tanımlar. Class Diagram: Sınıflar, metodlar ve özellikleri tanımlanır. Object Diagram: Belirli bir zamanda belirli bir nesne kümesi ve ilişkileri tanımlanır. Component Diagram: Sistem parçalarını oluşturan component’lerin nasıl birleştiği ve ilişkilerini tanımlar Composite Structure Diagram: Sınıfın iç yapısını ve izin verdiği işbirliklerini tanımlar Package Diagram: Sistemi oluşturan paketler arası ilişkileri tanımlar. Deployment Diagram: Dosya vb. nesnelerin, düğümlerde dağıtımını tanımlar

UML Sınıf Diyagramları (Class) Yapısal diyagramlarının en temeli sınıf (class) diyagramlarıdır. Bir sınıf diyagramı dikdörtgenle temsil edelir. Sınıfın adı en üste, ortalı ve kalındır. Altındaki iki bölümde, sınıfın özellikleri ve metotları tanımlanır. Sınıfın özelliklerinin görünürlüğünü de ifade etmek için; Public (+), private (-), protected (#) karakterleri özelliğin soluna belirtilir. Sınıf siyagramlarında sınıflar arası ilişkilerde gösterilir. İlişkilerde, ilişkinin yönünü gösteren bir ok ve ilişkide kaç tane nesnenin yer aldığını ifade etmek için semboller kullanılır. Sembol Anlamı 1 Sadece 1 0..1 0 veya 1 0..* 0 veya fazla * 1..* 1 veya fazla

UML Sınıf Diyagramları (Class) Bir diğer önemli sınıf diyagram tipi kalıtımdır. Nesne yönelimli programlamada bir sınıf başka bir sınıfın özellik ve yöntemlerini devralabililir. Örneğin, bir onur öğrencisi bir öğrencidir. İçi boş bir ok ile tanımlanır. Karmaşık uygulamalarda sınıf diyagramları için her şeyi tek bir diyagrama koyarsanız, dağınık ve zor okunur. Karmaşıklığı azaltmak için, geliştiriciler genellikle sistemin parçalarını gösteren çok sayıda sınıf diyagramı çizerler. Özellikle, kalıtım ve diğer ilişkileri göstermek için genellikle ayrı diyagramlar yapılır. GPA: Not ortalaması

UML Davranış Diyagramları (Behavior) UML temelde 3 çeşit davranış diyagramı tanımlar: Activity diyagram, use case diyagramları ve state machine diyagramları. (alt grup etkileşim diy.) Activity Diyagramları Aktiviteler için iş akışlarının tanımlandığı diyagramdır. İş akışının yönünü gösteren ok çeşitleri vardır. Diktörgen (olay yada görev), Baklava (karar), Kalın çizgi (Eşzamanlı aktivitelerin başlangıcı yada sonu), Siyah Daire (Başlangıç), Siyah Çizgili Daire (Aktivite sonu)

UML Activity Diyagramları İlk kalın çubuk üç paralel aktiviteyi başlatır: Fırını başlat, kuru malzemeleri karıştır ve ıslak malzemeleri karıştır. Eğer yardımcı aşcılar varsa, bu adımlar aynı anda paralel olarak ilerleyebilir. Üç paralel aktivite tamamlandığında, ikinci kalın bardan sonra iş akışı devam eder. Bir sonraki adım tüm malzemeleri birleştirmektir. Bir testle hamurun kıvamı kontrol edelir. Hamur çok yapışkan ise, daha fazla un eklenip tekrar kontrol edilir. Hamur doğru kıvama sahip olana kadar bu döngü tekrarlanır. Hamur doğru kıvamda olduğunda, kurabiyeleri yuvarla, fırın hazır olana kadar bekle ve kurabiyeleri sekiz dakika pişir. Sekiz dakika sonra, kurabiyeler kontrol edelir. Kurabiyeler pişmemişse bir dakika daha pişir. Kurabiyeler pişmediği sürece bir dakika kontrol et ve pişmesini sağla. Kurabiyeler piştiğinde, daire içine alınmış siyah daireyle aktivite tamamlanır.

UML Use Case Diyagramları Kullanım durum diyagramı şeklinde de ifade edilebilir. Elipslerle ifade edilen görevlere bağlı aktörleri tanımlar. Örnekte müşteri sitede arama yapar, eğer beğendiği bişey varsa satın alabilir <<extend>>. Satın alım yapmak için siteye giriş zorunludur <<include>>. Arama yapıldığında «Find matching products» eşleşen ürünleri bul aktivitesi çalışır. Search etkinliği Find etkinliği olmadan çalışamaz <<include>>. Bir alt görev yalnızca bazı durumlarda gerçekleşebilirse, <<extend>> Bir görev, alt görev olmaksızın gerçekleşemezse <<include>>

UML State Machine (Durum Makinesi) Diyagramları Durum makinesi diyagramları bir nesnenin olaylara yanıt olarak ürettiği durumları tanımlar. Durumlar diktörtgenle tanımlanır. Oklar durum geçişini gösterir. Ok üzerlerine açıklama yapılabilir. Örnekte program başlar ve + yada – bir sayı girebilir. Kullanıcı + yada – girerse «Digit before decimal» durumuna geçer, sayı okursa «Digit or decimal» durumuna geçer. Sayının tam kısmını okur. Enter tuşuna basarsa makine sonlanır (37 Enter) Kullanıcı bir ondalık nokta (.) girerse «Digit after decimal» durumuna geçer. Ondalık sayıları okur. Enter tuşuna basarsa makine sonlanır.

UML Etkileşim Diyagramları (Interaction) Etkileşim diyagramları Aktivite diyagramlarının bir alt grubudur. Sıralama (sequence), İletişim (communication), Zamanlama (timing) ve Etkileşim Genel Bakış (interaction overview) diyagramlarını içerir. Sıralama (Sequence) Diyagramları Nesnelerin belirli bir senaryoda nasıl işbirliği yaptığını tanımlar. İki nokta üst üste (:) sınıf olduğunu belirtir. Düz çizgili oklar senkronize mesajları, kesik çizgi oklar asenkron mesajları temsil eder. Açık uclu kesik çizgili oklar, isteğe üretilen cevabı tanımlayabilir. Müşteri tezgahtardan bir film ister. Tezgahtar, bileti Film sınıfına sorar. Film sınıfı cevap verir. Sınıfın cevabı olumsuzsa, etkileşim sona erer (bu örnek sadece olumlu yanıt için). Eğer yanıt olumluysa, film sınıfının bir koltuk seçmesini ister. Film sınıfı müşteriden mevcut koltuklarda bir koltuk seçmesini ister. Müşteri bir koltuk seçtikten sonra, Film sınıfı Tezgahtara bir bilet verir. Tezgahtar, bileti müşteriye teslim eder.

UML İletişim (Communication) Diyagramları Bir işbirliği durumunda nesneler arası iletişimi gösterir. Sıralama diyagramları mesaj sırasına odaklanırken iletişim diyagramları işbirliğine dahil olan nesnelere odaklanır. Mesajlar mesaj sırasını takip edebilmek için numaralandırılır. Zamanlama (timing) Diyagramları: Sıralama diyagramlarının bir varyansıdır. Nesnelerin zaman içerisindeki değişimini gösterir. Etkileşim Genel Bakış (interaction overview) Diyagramları: Sıralama, iletişim ve zamanlama gibi etkileşim diyagramlarını birlikte ele alan UML diyagramlarıdır. Daha fazla ayrıntıya odaklanır

Bölüm sonu Neler öğrendik? Üst-düzey tasarım, sonraki yazılım geliştirme aşamalarını tanımlar. Bir takım önemli sorulara cevap aranır: Hangi donanım platformunun kullanılacağı? Ne tür bir veritabanının kullanılacağı? Hangi sistemlerle etkileşime girileceği? Ne tür raporlara ihtiyaç duyulabileceği? Temel tanımlamalar yapıldıktan sonra gereksinimler geliştirme aşaması için hazırlanır. Bu aşamada kullanılan UML standartlarının neler olduğu. Sınıf, modül, arayüz ve uygulamanın diğer bileşenlerinin tanımlanması için alt-düzey tasarıma geçebilirsiniz.