T.C
SELÇUK ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ
XP VE UML'NİN YAZILIM GELİŞTİRME SÜRECİNE ETKİLERİ Havva Gül KOÇER
YÜKSEK LİSANS TEZİ
BİLGİSAYAR MÜHENDİSLİĞİ ANABİLİM DALI
ii
FEN BİLİMLERİ ENSTİTÜSÜ
XP VE UML'NİN YAZILIM GELİŞTİRME SÜRECİNE ETKİLERİ
Havva Gül KOÇER YÜKSEK LİSANS TEZİ
BİLGİSAYAR MÜHENDİSLİĞİ ANABİLİM DALI
Bu tez 30.01.2007 tarihinde aşağıdaki jüri tarafından oybirliği / oyçokluğu ile kabul edilmiştir.
Prof. Dr. Şirzat KAHRAMANLI Prof. Dr. Ahmet ARSLAN Doç.Dr.Hakan IŞIK (Danışman) (Üye) (Üye)
İ
ÇİNDEKİLER
1. GİRİŞ ... - 3 -
2. LİTERATÜR ARAŞTIRMASI... - 4 -
3. MATERYAL VE METOD ... - 7 -
3.1. Yazılım Geliştirme... - 8 -
3.1.1. Yazılım Geliştirme Tarihçesi... - 8 -
3.1.2.Yazılım Geliştirme Adımları ... - 9 -
3.1.3.Yazılım Geliştirme Süreci ... - 10 -
3.1.3.1.Yazılım üretim nedeni ... - 10 -
3.1.3.2.Hedef sektörün incelenmesi... - 11 -
3.1.3.3. Hedef sektörde kullanılan diğer yazılımlar... - 12 -
3.1.3.4. Yazılım analizinin yapılması ... - 12 -
3.1.3.5. Analize uygun tasarımın yapılması ... - 13 -
3.1.3.6. Tasarımın bilgisayar ortamına aktarılması (kodlama)... - 15 -
3.1.3.7. Yazılımın test edilmesi ... - 15 -
3.1.3.8. Eğitim ve İşe Alıştırma materyallerinin hazırlanması... - 16 -
4. YAZILIM GELİŞTİRME SÜREÇ METODOLOJİLERİ... - 17 -
4.1. Yazılım Mühendisliği Metodolojileri ... - 17 -
4.1.1. Şelale modeli... - 17 -
4.1.2. Prototip modeli... - 18 -
4.1.3. Artımsal model... - 19 -
4.1.4. Spiral model ... - 20 -
4.1.5.Tekrar kullanım modeli ... - 21 -
4.2. Çevik Metodolojiler ... - 22 -
4.3. Metodolojilerinin Karşılaştırılması... - 23 -
5. UML... - 25 -
5.1. UML’nin Olumlu Yanları... - 27 -
5.2. UML’nin Olumsuz Yanları ... - 28 -
5.3. Uml Diyagramları ... - 30 -
5.4. Uml Örnek Uygulama ... - 33 -
5.4.2. Sınıf Diyagramları... - 37 -
5.4.3. Ardıl Etkileşim Diyagramları (Sequence Diagrams) ... - 39 -
5.4.4. Durum Makinesi Diyagramları ... - 41 -
5.4.5. Aktivite Diyagramları(Actıvıty Diagrams)... - 42 -
5.5. Yazılım Camiasına Göre UML... - 44 -
6. EXTREME PROGRAMMING ( XP ) ... - 49 -
6.1. Xp’nin Getirdiği Yenilikler ... - 50 -
6.2. XP Prensipleri... - 52 - 6.2.1. Basitlik... - 52 - 6.1.2. İletişim ... - 52 - 6.2.3. Geribildirim... - 53 - 6.2.4.Cesaret ... - 53 - 6.2.5. Saygı ... - 53 - 6.3. XP Pratikleri ... - 54 - 6.3.1. Planlama Oyunu ... - 55 - 6.3.2. Kısa Sürümler ... - 55 - 6.3.3. Basit Tasarım ... - 56 - 6.3.4. Test ... - 56 - 6.3.5. Yeniden Yapılandırma………...-56-
6.3.6. Çiftli (Eşli) Programlama ... - 57 -
6.3.7. Ortak Sahiplenme... - 57 -
6.3.8. Sürekli Entegrasyon ... - 58 -
6.3.9. Müşteri (Kullanıcı) ile İç içe Olmak ... - 58 -
6.3.10.Kodlama Standardı ... - 59 -
6.4. UML ve XP ... - 59 -
6.5. XP İşletimi... - 60 -
7. RUP(RATIONAL UNIFIED PROCESS)... - 63 -
7.1. RUP ve XP Karşılaştırması ... - 64 -
7.1.1.Benzerlikleri... - 65 -
7.1.2. Farkları... - 66 -
8. SONUÇ ... - 67 -
1. GİRİŞ
Yazılım uygulamalarının gerçekleştirilmesi esnasında izlenecek yol “süreç” olarak tanımlanır. Bir ürün veya sistem üretileceği zaman, belirli adımları takip etmek, gerekli safhaları tamamlamak çok önemlidir. İzlenecek süreç bir yol haritasına benzetilebilir. Bir yerden başka bir yere gitmenin birden fazla yolu olabilir. Ama elde iyi bir yol haritası varsa, en uygun şekilde hedefe ulaşılır.
Yazılım geliştirme süreçlerinde takip edilen metodolojiler, yazılım mühendisliği metodolojileri veya çevik metodolojilerdir. Yazılım mühendisliği metodolojileri süreç güdümlüdür ve adımları, disiplinleri katı bir şekilde belirlenip yazılım geliştirme sürecinde bu kurallara sıkı bir bağlılık gerektirir. Planlara ve belgelere dayanan bir işleyişi vardır. Çevik metodolojiler ise internet ortamının getirdiği, piyasaya çok çabuk ürün çıkarabilme ve ürünleri anlık değiştirebilme isteğinin bir sonucu olarak ortaya çıkan ve yazılım mühendisliği metodolojilerindeki ağır işleyişi hızlandırma amacında olan metodolojilerdir.
Yazılım geliştirme sürecinde tasarımın ne zaman ne kadar yapılacağı her zaman tartışma konusu olmuştur. Yazılım mühendisliği metodolojileri veya süreç güdümlü metodolojiler genellikle tasarımın kodlamadan önce ve ayrıntılı bir şekilde yapılmasını savunurlar. Süreç güdümlü metodolojilerde tasarım aşamasında modelleme ve dokumantasyon için çokça tercih edilen bir yöntem olan UML(Unified Modelling Language) dili ve tasarımında grafik çizimi veya modellemeye fazla vakit ayrılmaması taraftarı olan çevik metodolojilerin en popüler olanı Extreme Programming(XP) incelenmiştir.
2. LİTERATÜR ARAŞTIRMASI
Bu yayın yazılım geliştirme camiasında UML’nin kullanımı ve adaptasyonu hakkında bir araştırmanın bulgularını anlatmaktadır. Web tabanlı araştırma dünya çapında kullanıcıların cevapları tarafından yönetilmiştir. Sonuçlar gösteriyor ki UML’yi destekleyen fikirlerin çeşitliliği etkinliği üzerine yapılan tartışmalar teknolojinin göreceli olgunlaşmamışlığını da yansıtmaktadır. Bu yayın araştırmanın sonuçlarını tartışır ve UML kullanımı üzerine yapılacak gelecek araştırmalar için yol haritası çıkarır.( Grossmana ve ark. 2004 )
Yazılım proje yönetiminin ana hedefi bir yazılım ürününün fiyat limitleri içinde ve uygun kalitede ve zamanında tamamlanmasını temin etmektir. Özgün dizayn gerçekleştirmek için çevrenin geliştirilmesi kaynakların yeterli ve etkili paylaşımının yapılması gerekmektedir. Uygun bir proje planı iyi ve optimal kişisel geliştirme görev planlamasına sahip olmalıdır. Sonuç olarak bir proje yönetim metedolojisi proje boyunca gelişebilecek risklerle başa çıkabilmelidir. Bu proje yönetim aktiviteleri teslim tarihini korumak için proje geliştirme sürecinin ilk aşamalarında başlamalıdır ve sürekli geliştirme süreç işlemi ile uyum içinde olmalıdır. UML yazılım ürünlerinde dizayn uygulamalarında artarak kullanılmaktadır. UML’nin bir dizayn dili olarak kullanmanın ana faydalarından biri başlangıç aşamalarından uygulamaya kadar baştan sona kullanılabilmesidir. UML nin özelliklerini kullanarak bir sistemin dinamik davranışları modellenebilir iş akışları değerlendirilebilir bu yolla geliştirme süreci kendiliğinden tanımlanmış olmaktadır. (Doban ve Pataricza 2003)
UML her uygulama alanı için dertlere deva mı? Tüm yazılım problemlerimizi çözmede tek ve yalnız yaklaşım mıdır? Diğer OO metotları çabucak uzaklaştırılmalı mı?Bu yayın UML’nin avantaj,dezavantajlarını,UML ye duyulan memnuniyet ve eksikleri nedeniyle öfkeyi tartışır.(Hruschka 1997)
Gelişen yazılım sektöründe, yazılım geliştirme süreçleri içersinde kaliteye ne denli önem verildiği ve mevcut kalite kriterlerinin nasıl değerlendirildiği deneysel olarak anlatılmaya çalışılmış ve Yazılım Mühendisliği Kalite Kriterlerine UML (Unified Modelling Language) Katkısı deneysel olarak görülmeye çalışılmıştır. Sonuç olarak üretilen yazılımında bir tüketim maddesi olduğu fikrine dayanarak üretici ve tüketici arasındaki gereksinim ilişkileri ve bu ilişkilerin oluşmasında iletişimin sağlanmasının kaliteye etkisi, çalışma ortamlarının ve proje bağlı olarak çalışan kişi sayısının ve UML’nin kaliteye etkisi deneysel olarak görülmeye çalışılmıştır.(Kurnaz ve ark. 2003)
UML dizayn ve analizde bir standart olmasına rağmen apaçık eksikleri bulunmaktadır: UML tanımlaması yetersizdir, sonuç tipleri kümesi oldukça geniş ve karmaşıktır ve tool desteği memnun edici değildir. Eğer bu durum doğruysa insanlar UML’nin nasıl üstesinden geliyor? sd&m(Almanya Münih’te orta ölçekli bir yazılım şirketi) ‘de analiz evreleri merkezinde en uygun pratikleri içeren bir çalışma yönettik. Amaç tipik analiz dökümantasyonlarındaki benzer nitelikleri ve UML’nin kullanılıp kullanılmadığını ortaya çıkarmaktı. Şaşırtıcı bir sonuçla karşılaştık: Bu yayında tipik bir analiz dökümantasyonunun içerdiği 17 modülü tanımladık ve kısaca özetledik. Bu 17 modülden sadece 3 tanesi UML kullanmaktaydı. Bu yayında UML’nin neden gerçek projelerin ihtiyaçları için tatmin edici olmadığını ve hala yapılacak birçok işin kaldığını açığa kavuşturmaya çalıştık( Stutz ve ark. 2002 )
Son yıllarda UML yazılım gereksinim belirleme ve dizayn modellemede standart bir dil haline gelmiştir. Bu yayında UML’nin sistem gereksinim belirleme dili olarak uygunluğunu araştırdık. UML’nin özellikle kullanım senaryosu ve sistem çözümleme ile ilgili çeşitli problem ve eksiklerini tanımladık ve bu eksiklerin nasıl giderilebileceğini ve potansiyel alternatifleri inceledik.(Glinz 2000)
Sıradışı Programlama(Extreme Programming), büyük yazılım sistemlerinin geliştirilmesinde sağlam bir yaklaşım olduğunu hesaba kattığımız kabüllenilmiş yazılım mühendisliği pratiklerinin birçoğunu ihlal etmesiyle dikkat çekmiştir. XP yazılım geliştirmede yeni bir yol olarak deklare edilmiştir: etkili, riski düşük, esnek pratik, bilimsel, diğer metodolojilerden ayırt edilebilir hafifsiklet bir metodoloji. Bu yayın kavramsal modelleme ve kod oluşturmadaki rolleride hesaba katılarak XP pratiklerini inceler ve RUP ile XP arasındaki benzerlikleri sıralar.(Juric 2000)
XP gibi çevik metodolojiler yazılım geliştirmedeki potansiyel faydaları ile tanınmışlardır. XP sürecine adaptasyon süresince yazılım grupları XP prensiplerini içeriğini önemsemeden harfiharfine uygulamaya çalışarak yanlış kullabilirler. Bu yayın içeriğini tanıdıkça değişen XP prensiplerinin acemi uygulamalarındaki deneyimlerimizi anlatmaktadır. Takımların problemi XP ye uydurmaktan çok XP’yi probleme uydurmaya başlamaları ve geribildirim kuralları üzerindeki izlenimlerimizi detaylandırdık.(Jackson ve ark. 2004)
2004 te iki yazılım mühendisliği kursu verdik: biri süreç güdümlü metodolojiler diğeri çevik motodolojiler üzerine. Bu kurslarda 14 ila 16 öğrencilik gruplar ya takım yazılım sürecini yada XP’yi seçerek büyük projelerde görev aldılar. Sonuçta öğrenci deneyimlerine göre yaptığımız karşılaştırmada süreç güdümlü çalışanlarla çevik metodolojiye göre çalışan takımın biri aynı problem durumu ile karşılaşmasına rağmen sonuçta yapılan ölçümlerde XP takımının daha verimli olduğu süreç güdümlü takımın sağlam bir tasarımı olduğu ve kod yazmaya başladıklarında umdukları dizaynı sağlamaya çalıştıkları için daha çok kod yazdıkları görülmüştür(Wellington ve ark. 2005)
3. MATERYAL VE METOD
XP ve UML’nin yazılım sürecindeki rolü ve etkilerini aktarabilmek için tez bölümler halinde sunulmuştur:
Birinci bölüm “yazılım geliştirme” kavramını üzerinde odaklanmıştır. Yazılım kavramının tanımı yapılmış ve dünden bugüne yazılım geliştirme evriminden bahsedilmiştir. Yazılım geliştirme sürecinde yapılması gerekenler adım adım belirtilmiş ve açıklanmıştır.
İkinci bölümde yazılım mühendisliği metodolojileri incelenmiş ve genel kabül görmüş yazılım süreçleri açıklanmıştır. Bu süreçlere alternatif olarak ortaya çıkan çevik metodolojilere değinilmiş ve yazılım mühendisliği metodolojileri ile karşılaştırılaştırması yapılmıştır.
Üçüncü bölüm UML’nin anlatıldığı kısımdır. Tanımı, ortaya çıkışı, faydaları, diyagramları olumlu ve olumsuz özellikleriyle UML irdelenmiştir.
Dördüncü bölüm çevik metodolojilerinden en popüler olan Extreme Programming yaklaşımının temelleri ve pratikleri anlatılarak açıklanmasına ayrılmıştır.
Son bölümde ise UML nin de bünyesinde kullanıldığı RUP yazılım sürecine değinilmiş ve XP ile karşılaştırılaştırılması yapılmıştır.
3.1. Yazılım Geliştirme
3.1.1. Yazılım Geliştirme Tarihçesi
Yazılım bilgisayarınızın belli görevleri yerine getirmesini sağlayan ve komutları insanların anlayacağı dilden bilgisayarın anlayacağı dile çeviren kod bütünüdür.
Dünden bugüne yazılım geliştirme evrimine kısaca değinelim;
1950’lerde bilgisayar yazılımlarında öncelik arzu edilen işin yapılmasıydı bu da genellikle özel hesap makineleri ile yapılan ağır matematiksel işlemlerin bilgisayar ile yapılmasının sağlanmasıydı. İşler toplu olarak verilir ekrandan veya yazıcıdan çıktı alınırdı. Yazılımlar ürün tarzında değil de kendisi için yapılan kuruluşa özel biçimde geliştirilmekteydi.
1960’lı yıllarda özellikle askeri amaçlı ve gerçek zamanlı sistemler için yazılım geliştirilmiş ve veri tabanı yönetim sistemlerinin ilk temelleri atılmıştır.
1970’li yıllarda bilgisayar sektöründe yeni bir bilgisayar türü ortaya çıkmıştır. Kişisel bilgisayarların yani PC’lerin ucuzlaması insanların evlerine bilgisayar almasına ve kalabalık bir kitlenin yazılım gereksinimi duymasına neden olmuştur. Kitleler için yazılım yapmak yepyeni bir kavram olarak ortaya çıkmıştır.
1980’li yıllarda bilgisayar kullanımının oldukça yaygın hale gelmesiyle bilgisayar ağ altyapısı da güçlenmiş ve dağıtık yazılım sistemleri geliştirilmeye başlanmıştır. Programlama tekniklerinin ilerlemesi insan gibi düşünebilen sistemler yaratmak üzere yapay zekâ tekniklerinin gerçekleşmesini ve “akıllı uygulama yazılım”larının üretilmeye başlamasını sağlamıştır.
1990’lı yıllarda yazılım hayatın vazgeçilmez bir parçası haline gelmiştir. Uzman sistem, yazılımları oldukça geliştirmiş ve yaygınlaştırmıştır. Yazılım kalite olgusu önem kazanmaya başlamıştır. Yazılım ile ilgili standartlar olgunlaşmış ve yazılım üretimi ve ürünlerinin değerlendirilmesi amacıyla kurumlar oluşmaya başlamıştır.
2000’li yıllara gelindiğinde artık yazılım geliştirmenin bir “süreç” olduğu ve yazılımın kendisinin de büyük ölçekli bir “sistem” olduğu kabul edilmiş durumdadır. Bu iki sözcük(süreç ve sistem) çok önemli anlamları olan sözcüklerdir ve yazılım sektörünün bu iki sözcüğü kabul etmesinin de ciddi sonuçları olmuştur. Bunlardan beklide en önemlisi “Yazılım Mühendisliği” kavramıdır.
3.1.2.Yazılım Geliştirme Adımları
Yazılım geliştirme dediğimiz şey aslında bir sorunun çözülebilmesi için bilgisayarı yeniden ayarlanabilir bir araç olarak kullanmaktan ibarettir. Bir bilgisayar programı, programın çözeceği problem için belli durumlar tanımlayan ve bu durumlar arasındaki gezintiyi tarif eden bir turist rehberi gibidir.
Yazılım geliştirmenin çağdaş uygulamasında, programlama etkinliği oldukça karmaşık aşamalara sahiptir. Ancak aslında bir problemi çözmenin temel adımları yüzlerce yıldır aynıdır.
Analitik düşünceye göre herhangi bir problemi genel bazı adımları dikkatlice izleyerek çözebiliriz.
Problemin saptanması ve ifade edilmesi
Problemin doğasının anlaşılması için çevresinden soyutlanması Problemi simgeleyen soyut bir kavramsal modelin oluşturulması
Bu modelin çözümlenmesi ve bu modelin sunduğu probleme bir çözüm getirilmesi
3.1.3.Yazılım Geliştirme Süreci
Günümüzde birçok kuruluş rekabet güçlerini arttırmak, ayakta kalabilmek için, bilişim teknolojilerinden yararlanmaktadır. Donanımsal ve yazılımsal yatırımlar yaparak var olma yarışında bir adım önde olmak için çalışmaktadırlar. Bilişim teknolojilerinden maksimum fayda sağlamak için hızla büyüyen bir pazara sahip yazılım sektöründe, hem yazılım üreticileri, hem de hedef sektörler açısından uyulması gereken, adı konulmuş ürün geliştirme süreçlerinin oluşturulması gerekmektedir. Yazılım uygulamalarının gerçekleştirilmesi esnasında izlenecek yol “süreç” olarak tanımlanır. Bir ürün veya sistem üreteceğiniz zaman, belirli adımları takip etmek, gerekli safhaları tamamlamak çok önemlidir. İzlenecek süreç bir yol haritasına benzetilebilir. Bir yerden başka bir yere gitmenin birden fazla yolu olabilir. Ama sizin elinizde iyi bir yol haritası varsa, siz en uygun şekilde hedefe ulaşırsınız.
Süreç ile tanımlanmış yazılım mühendisliği aktiviteleri sonucunda ortaya ürün olarak sadece program çıkmaz, bunun yanında dokümanlar ve yazılıma ilişkin veriler çıkar. Siz bu ürünler ile daha sağlıklı yönetim kararları verebilir ve programın kullanıcı isteklerini tamamen sağladığından emin olabilirsiniz. Son ürüne ulaşmanın kısa yolarlıda vardır, ama bunların güvenilmezliği, başarısızlık riskinin büyüklüğünü belirtmek ve vurgulamak gerekir.
3.1.3.1.Yazılım üretim nedeni
Bir yazılımın üretimine başlanması için ya sektör kuruluşlarından bir talep gelmesi ya da sektörün böyle bir ürüne ihtiyaç duyduğunun firma tarafından belirlenip ihtiyaç oluşturulması gerekir.
Yazılım firmasının yazılım üretme süreci, daha çok, sektörden gelen talep üzerine başlar. Bunun nedeni ise yazılım üreticisinin en azından bir satışı garanti altına alarak zarar etmek istememesidir. Her şekilde izlenecek yol aynıdır.
3.1.3.2.Hedef sektörün incelenmesi
İlk adım sektördeki satış potansiyelinin belirlenmesi olmalıdır. Yazılım sektörünün bu süreçte harcadığı emeğin karşılığını ne kadar alabileceği en başta ortaya konulmalıdır.
Üretilecek yazılım için hedef sektörün incelenmesi sürecinde, sektöre ilişkin dikkat edilecek noktaların belli başlıları şunlardır:
Yoğunluk
Ekonomik imkânlar
Yönetici ve işletme sahiplerinin bilgi sistemlerine ilgisi Çalışanların bilgisayar kültürü
Yönetim organizasyon yapısı
Sektör araştırılırken, var olan kuruluşların sayısal çoğunluğu göz önüne alınmalıdır. Çok az sayıdaki işletmenin faaliyet gösterdiği bir sektöre yönelik yazılım geliştirilmesi, sektör için maliyeti çok yüksek bir hal alabilir. Böyle bir durumda da, yazılımın geliştirilmesi sürecine hiç girilmeyebilir.
Diğer yandan önemli bir konu da yazılımı kullanacak kişilerin bilgisayar kültürüdür. Yazılımın kullanıcı açısından oldukça kolay ara yüzlere sahip olma zorunluluğunun yanında, kullanıcılara geliştirilecek yazılım için ne derecede eğitim verilmesi gerekliliği de bu aşamada planlanmalıdır. Uygulamanın, gereksinim duyduğu donanımsal ihtiyaçlar ve yetişmiş personel ihtiyacı, analiz aşamasında mutlaka değerlendirilmelidir.
3.1.3.3. Hedef sektörde kullanılan diğer yazılımlar
Yazılım üretimine başlamadan önce sektörde kullanılan diğer yazılım ürünlerini araştırıp, ürünlerin iyi ve kötü yönlerini tespit ederek daha üstün bir yazılım ortaya çıkartmak mümkündür.
Sektörde birden fazla ürün kullanılıyor olabilir. Bu durumda, rekabetin boyutları, ürünler arası farklılıklar, pazar payları, üretici firmaların bölgesel yoğunlukları ve müşterilerin düşünceleri mutlaka incelenmeli, yazılıma başlamadan önce değerlendirilmeye alınmalıdır.
Bilinmesi gereken faktörler:
Diğer üreticilerin faaliyetleri
Üreticilerin bölgesel konumu ve teknolojik gücü Üreticilerin diğer bölgelerdeki faaliyetleri Ürünlerin pazar payları
Ürünlerin üstün özellikleri
Yazılım firmaları belli bölgelerde pazara tamamen hakim olabilirler. Bu gibi durumlarda boşluk olan bölgeler seçilmeli ve bu bölge üzerinde araştırmalar yapılmalıdır. Bayi alt yapısı, ulaşım ve ilgili diğer konular yoğunlaşılan bölge için değerlendirilmelidir.
3.1.3.4. Yazılım analizinin yapılması
Ön araştırmaların tamamlanmasının ardından firma üretime başlama kararı alabilir. Alınan bu karar, ön çalışmalar ışığında olmalı, olası riskler önceden belirlenmelidir. Analiz aşamasında, firma belirleyeceği bir ya da daha çok müşteri üzerinde çalışmalıdır. Ancak, analiz araştırmalarında birden çok müşteri ile çalışmak, sektörün tanınması ve daha kapsamlı analiz yapma olanağı sağlar.
Analize kaynak olan unsurlar:
Yazılıma ihtiyaç duyulmasının nedenleri
Faaliyetlerin, başlangıçtan bitişe doğru aşamaları
Kullanılan, tüm belgeler, formlar, resmi ve diğer evraklar Varsa kullanılan uygulama yazılımları ve kullanım amaçları İş gören personelin görüş ve düşünceleri
Müşteri tarafından ihtiyaç duyulan, saklanacak veriler Elde edilmesi gereken, yararlı bilgiler, rapor ve formlar
Sektörde lider kuruluşlar araştırılarak, daha sonra karşılaşılabilecek sorunlar ve çözümlerin tespiti ile elde edilen bilgiler
Sektör bünyesinde yer alan küçük, orta ve büyük ölçekteki tüm işletmeler göz önüne alınarak, yazılımın işletmelerin gelişim süreçlerine uyum sağlayabilmesi de dikkate alınmalıdır. Gelişim süreçlerinde işletmelerin karşılaştıkları sorunların çözümleri geliştirilen yazılım kapsamında değerlendirilmelidir.
Analiz çalışmasının tüm bu kriterler çerçevesinde yapılmalı ve elde edilen tüm bilgiler düzenli olarak kağıda dökülmeli ve saklanmalıdır.
3.1.3.5. Analize uygun tasarımın yapılması
Geliştirilen yazılımın kullanıcı arayüzünün kolay ve kullanışlı olması tamamen profesyonel bir ekip işidir. Yazılımı kullanacak kişilerin yazılımı zorlanmadan kullanabilmeleri ve kullanırken de sıkılmamaları önemli unsurlardır. Tasarım aşaması, yazılımın hem kullanıcı arayüzünü, hem de programın omurgasını ortaya koymaktadır.
Tasarım aşaması iki ana bölümden oluşmaktadır: yazılımın alt yapısı olarak adlandırılan veri tabanı tasarımı ve görsel kanadı oluşturan ara yüz tasarımı ve araçların seçimi.
Veri tabanı seçimi ve tasarımı
Birçok yazılım ürünü, çok iyi görsel araçlara sahip olmasına rağmen, ne yazık ki zamanla yok olup gitmiştir. Bunun nedeni ise, çok kullanıcılı ortamlara aktarılamaması ya da aşırı veri yoğunluğunu destekleyememesi gibi nedenlerdir. Veri tabanı tasarımı ve seçiminde, tasarım ekibi, analizden gelen bilgiler doğrultusunda maksimum değerleri göz önüne almalıdır. Örneğin; yazılımın kullanılması ile müşterinin bir yıl sonra milyonlarca kayda ulaşması bekleniyorsa, veri tabanı bu desteği verebilecek şekilde seçilmeli ve tasarlanmalıdır.
Veri tablolarının belirlenmesi Sahaların belirlenmesi (Kayıt deseni) İndeks ve anahtar alanların belirlenmesi
Tablolar arası ilişkilerin kurulması (İlişkisel veri tabanı tasarımı) Tetikleyici ve prosedür kodlarının tasarımı
Veri tabanı seçimi
Ara yüz tasarımı ve geliştirme aracı seçimi
İyi tasarlanmış arayüze sahip uygulamalarda hem kullanıcı kolaylık yaşar, hem de firmanın destek ekibi rahat olur. Ayrıca, programcıların hakim olduğu ya da destekleyebilecekleri kodlama araçları ile çalışılmalıdır.
Tasarımın sadece müşteri için değil, firmanın destek birimi de düşünülerek yapılmalıdır. Hiçbir müşteri, yeterli destek alamayacağını bildiği bir uygulama yazılımını satın almak istemez.
Yazılımın adı, Ikon tasarımı Kapak resmi (Ya da açılış resmi)
Kullanılacak derleyici ya da yorumlayıcı tespiti Kodlama ve iş akış diyagramlarının hazırlanması Veri giriş ekranlarının tasarlanması
Sorgulama (Ya da arama) ekranlarının tasarlanması Yazıcı ve ekran raporlarının tasarlanması
3.1.3.6. Tasarımın bilgisayar ortamına aktarılması (kodlama)
Gelişen teknoloji, kodlamayı daha az kullandırıyor, araçlar kullanmayı öneriyor. Ancak bu yöntem, iyi kod yazma gerekliliğini ortadan kaldırmıyor.
Tasarımı tamamlanmış bir uygulama programcıya ulaştığında, programcının yapacağı ilk iş modülü iyi anlamak olmalıdır. Yazılacak modülü zihninde canlandıramayan programcı kodlamayı yapamaz.
Tasarımda hazırlanan kodlama detayları, iş akış diyagramları, tablolar ve tetikleyici kodların programcıya yazılı olarak verilmesi ve yapılan işin anlatılması gereklidir.
Kodlamanın unsurları şunlardır:
Sağlam ve anlaşılır olmalıdır. Şekil (Yazım) kurallarına uymalıdır.
Yardımcı fonksiyonlar ve özel kitaplıklarla sadeleştirilmelidir. Desteklenebilir olmalıdır.
Bir yazılım ürününün kodlaması hiçbir zaman bitmez. Yapılan eklemelerle kod sürekli yenilenir. Bu durumun istisnası yoktur. Ancak zamanla gelen taleplere destek verebilen yazılımlar ayakta kalabilir. Tüm bu anlatılanlar, kodun sağlam ve anlaşılır yazılması gerekliliğini ortaya koyar.
3.1.3.7. Yazılımın test edilmesi
Test, üretimin son aşaması olmasına rağmen, aynı zamanda süreklilik arz eden bir diğer süreçtir. Yazılım üretiminde ilk testler geliştirme sürecinde programcı tarafından yapılır. Bununla birlikte, asıl hata ayıklama ve geribildirim (FeedBack) hizmeti test ekipleri tarafından yapılır. Testler ve geribildirim müşteri yazılımı kullandığı sürece devam eder. Programcıların yaptığı testler ağırlıklı olarak iş akışı değil, teknik testlerdir. Bu nedenle iş akışı yönünden yazılım testi, özel bir ekip tarafından yapılır.
Yazılım test süreci:
Programcı testleri Test ekibinin testleri Kullanıcı grubu testleri
Test sürecinde en faydalı geribildirimler son kullanıcı test gruplarından gelir. Yazılımın beta testlerinde mutlaka müşteriden test grupları oluşturması istenmelidir. Bu sayede müşterinin yeni yazılıma adaptasyonu da sağlanmış olur. Testlerin sonunda ilgili birimlerle birlikte değerlendirme toplantıları yapılmalıdır. Bazen hataların kaynağı analizde ya da tasarımda olabilir. Kullanıcıdan gelen yeni bir istek var ise, bu talep doğrudan analiz ekibine iletilmelidir. Çünkü yazılımın mimarisinin temelleri analizciler tarafından hazırlanmıştır.
3.1.3.8. Eğitim ve İşe Alıştırma materyallerinin hazırlanması
Müşteri için kullanıma hazır hale getirilen yazılım, tamamlayıcı öğelerin de sağlanmasıyla bitmiş demektir. Ortaya çıkarılan uygulamanın eğitiminin ve dokümantasyonunun sağlanması tamamlayıcı öğeler olarak düşünülmelidir.
Satış ve destek aşamalarında kullanılan en önemli malzeme dokümanlardır. Altyapı gereksinimleri, kurulum, ayarlar ve bunlara ilişkin çeşitli eğitsel dokümanlar, uzman kişilerce hazırlanmalıdır.
Satış öncesi yapılacak hazırlıklar;
Kurulum ve ayarlama dokümanları
Uygulama eğitim programlarının oluşturulması Uygulama kullanım kılavuzu hazırlanması Sıkça sorulan soruların cevaplanması Bayiler için eğitim programı oluşturulması Destek birimi eğitim programı oluşturulması
4. YAZILIM GELİŞTİRME SÜREÇ METODOLOJİLERİ
4.1. Yazılım Mühendisliği Metodolojileri
Organizasyonlarda temel olarak, yazılım sistemlerinin gereklerinin belirlenmesi, tasarlanması, kodlanması, test vb. aktivitelerinin gerçekleştirilmesi amacı ile çeşitli süreçler uygulanmaktadır.
4.1.1. Şelale modeli
En çok ismi geçen yazılım geliştirme süreç modeli şelale(waterfall)dır. Bu model gereklerin analiz edilmesi ve belirlenmesi, tasarım, kodlama ve ünite testi, entegrasyon ve sistem testi, işletme ve bakım onarım safhalarından oluşmaktadır.
En önemli dezavantajı, bir safhanın tamamlandığına karar verildikten sonra o safhaya geri dönmenin zor olmasıdır. Örnek olarak, gerekler safhası tamamlanıp tasarım safhasına geçildiği zaman, yazılım gereklerinin tamamen belirlendiği kabul edilmekte ve gerekler sabitlenmektedir. İlk seferde gereklerin tam, doğru ve eksiksiz olarak belirlendiğini düşünmek genelde gerçeği yansıtmamaktadır. Projeyi bu modelde olduğu gibi esnek olmayan safhalara ayırmak doğru değildir. Bu nedenlerden dolayı, sadece gereklerin tam ve kesin olarak belirlendiği projelerde (ki böyle müşteri isteklerinin ve gereklerin başlangıçta sabitlenebildiği projeler pek görülmez) bu model kullanılabilmektedir. Bu model kullanıp, ilk versiyon teslimat safhasına geldiğinizde yeni bir yazılım gereğine cevap vermeniz pek mümkün olamayabilir çünkü bütçenin tamamına yakınını sarf etmiş olabilirsiniz.
4.1.2. Prototip modeli
Yazılım geliştiren organizasyonlar için şüphesiz en zor noktalardan bir tanesi, kullanıcı gereklerinin tam olarak belirlenmesidir. Çoğu zaman müşteriye kullanıp, üzerinde değerlendirme yapabileceği bir prototip sağlanana kadar, müşterinin gerçek gereksinimlerini ortaya çıkarmak zor olmaktadır.
Yazılım geliştirmekteki temel amacımız gerçek ihtiyaçları karşılamak ve gerçek problemleri çözmektir. Bunun tek yolu, ihtiyaç sahipleri ile iletişimin yoğun olmasıdır. Eğer gerçek gereksinimleri ortaya çıkaramaz isek, ortaya çıkardığımız kaliteli yazılım ürünümüz yanlış ve/veya gereksiz çözümler sunar. Günümüzde popülerliği sürekli artmakta olan yeni yazılım geliştirme modellerinde de “müşterinin süreçte etkili biçimde yer alması” öne çıkmaktadır.
Prototip modelinde de müşterinin isteklerini ve gereksinimleri öğrenmek için geçici bir model yazılım üretilmesi söz konusudur. Temel olarak, iki tip yazılım prototipi mevcuttur, ilki “At-Gitsin” diğeri ise “Evrimsel”dir. At-Gitsin prototipler, kullanıcı gereksinimlerinin açık olmadığı durumlarda hızlıca geliştirilerek kullanılırlar. Temel amaç müşteri gereklerini açığa çıkarabilmektir. Ortaya çıkacak ürünün kalitesi hakkında kaygılanmamak, herhangi bir doküman yazmadan, kaynakları mümkün olduğunca az kullanarak, ortaya müşterinin kolayca
değerlendirebileceği ürünler çıkarmak esastır. Müşteri gereklerinin belirlenmesi ile artırımsal metotlara dönerek geliştirme sürecini devam ettirmek uygun olacaktır. Eğer müşterinin temel gerekleri belli ve detay gerekler belirsiz ise “Evrimsel” prototip kullanılabilir. Bu prototip bir kenara atılmayarak, üzerine sürekli yeni fonksiyonel birimler eklenerek geliştirilir. Prototip kullanımında temel sorunlar, kullanıcının tatminsizliği ve kaliteden verilen büyük ödündür. Müşterinin sürekli yeni gerekler öne sürerek proje başarısını olumsuz etkilememesi için, süreç başlangıcında, bitiş kriterlerinin tam olarak belirlenmesi gerekmektedir.
4.1.3. Artımsal model
Artımsal modelde, tek teslimatta tüm sistemi teslim etmektense, sistemi fonksiyonel birimlere ayırtıp, teslimatları artımsal fonksiyonel birimler halinde yapmak tercih edilir. Bu modellemede, kullanıcı gerekleri önceliklendirilir ve önceliği yüksek olan gerekler ilk versiyon teslimatlarda müşteriye sunulur. Bir artımın geliştirilmesine başlandığında bir sonraki artıma kadar kullanıcı gereklerinin donduğu (değişmediği) kabul edilir. Bu model ile, her yeni gelecek kullanıcı isteği artımsal olarak sisteme eklenebilmektedir.
Artımsal modelin en büyük avantajı, müşterinin süreç içerisinde daha fazla yer almasının sağlanabilmesidir. Kullanıcı, sistemin gereklerinin tek tek yerine getirildiğini gözlemleyebilmekte, varsa değişiklik önerisini hemen verebilmektedir. Örneğin şelale modelinde, müşteri son safhaya kadar sistemi görememekte, sürece katılımı minimum düzeyde kalmakta idi. Doğru yazılım ürünlerinin geliştirilebilmesi için müşterinin yeterli düzeyde süreç içerinde yerini alması ve sürece katılması gerekmektedir. Bu kural prototip modelinde bir ölçüde yerine getirilebilmekte, bununla beraber evrimsel süreçlerde tam anlamı ile gerçekleştirilebilmektedir. Müşterinin süreç içerisinde yerini alması projenin başarısızlık riskini azaltan bir olaydır. Bu modelin bir diğer avantajı ise, yüksek öncelikli gereklerin erken geliştirilerek, daha fazla test edilebilmesine olanak sağlanmasıdır.
4.1.4. Spiral model
Süreç içerisinde yer alan aktivitelerin zincirleme olarak gelişmesinden farklı olarak SPİRAL şeklinde de gerçekleşmesi mümkündür. Spiral modelin her bir turu, süreçte yer alan herhangi bir safhayı temsil edebilmektedir.
Şekildeki numaraların açıklamaları şöyledir.
0. Yaşam Döngüsü Planı 1. Gerek Planı 2. Geliştirme Planı 3. Entegrasyon ve Test Planı 4. Kapsam 5. Gereklerin Belirlenmesi ve Geçerlilenmesi 6. Tasarım ve Geçerlileme 7. Entegrasyon, Ünite Testleri ve Kabul Testleri 8. Son Ürün
Özellikleri sabitlenmiş hiçbir tur yoktur. Turun başında yapılan risk analizi ve bir önceki tur sonunda yapılan değerlendirme sonucunda, turun safhası (özellikleri) ortaya çıkmaktadır. Süreç içerisinde o an neye ihtiyaç duyuluyorsa, ihtiyacı karşılamak üzere tur atılır. Her bir tur için çeşitli hedefler konulmakta ve gerçekleştirilmeye çalışılmaktadır. Turun başlarında yapılan risk analizi ile projenin başarısızlık riski azaltılmaktadır.
4.1.5.Tekrar kullanım modeli
Organizasyon tarafından daha önce hazırlanmış veya dışarıdan temin edilmiş yazılımların veya yazılım parçalarının kullanılması ile geliştirme yapılması son yıllarda popülaritesi artan bir yaklaşımdır. Organizasyonların olgunlukları arttıkça, bu tür uygulamalar yapabilmek için alt yapı kurulmuş olmaktadır.
4.2. Çevik Metodolojiler
Yazılım geliştirmede günümüzde sıklıkla kullanılan yöntemlerden biri "kodla ve düzelt" yöntemidir. Bu metot da yazılım, ihtiyaçlar çok iyi anlaşılmadan üretilmekte ve müşteriye sunulmaktadır. Müşteri eksikleri, hataları geri bildirmekte ve yazılım gerekli şekilde değiştirilerek müşterinin ihtiyacını karşılayacak hale getirilmektedir.
Yazılım geliştirmede kullanılan yöntemlerden bir diğeri de yazılım mühendisliği metodolojileridir. Önce sistem iyice analiz edilir ve ihtiyaçlar net bir şekilde ortaya konur ardından tasarım yapılır, kodlanır ve test tamamlandıktan sonra yazılım teslim edilir.
Çevik metodolojiler bu iki metodolojiden de farklı olup her iki grup için de ideal olabilir. Yöntemi aslında "yöntemsizlik" olan ilk grup için adaptasyonu kolay ve esnek bir yapı sunarken, genellikle bürokratik ve hantal olmasıyla eleştirilen mühendislik metodolojileri kullanıcılarına alternatif bir yöntem olabilir.
Çevik metot taraftarlarına göre belgelere ve planlara uyumun önemini kaybetmesi, buna karşılık uzman kişilerin kararlarının öne çıkması, bir başıbozukluk anlamına gelmemelidir. Çevik metotlar kuralsızlık demek değildir. Süreç güdümlü metotlar gibi öğrenilmesi ve uygulanması gereken kurallar içerirler. Yazılım üreten bir grup bir çevik metodolojiye geçme kararı verdiğinde yine kurallara, disipline, planlamaya ve eğitime ihtiyaç duyacaktır.
Çevik metotlar internet ortamının getirdiği, piyasaya çok çabuk ürün çıkarabilme ve ürünleri anlık değiştirebilme isteğinin bir sonucudur. Genellikle 1990’lı yılların sonlarına doğru ortaya çıkan bu metotlar, değişen isteklere hızla yanıt verme ve en kısa zamanda bir yazılım ürününü müşteri hizmetine sunmayı amaçlamaktadırlar.
Çalışma biçimlerinde farklılıklar gösterseler de çevik metodolojilerin ortak özellikleri şöyle özetlenebilir:
Süreçler ve araçlar yerine kişiler ve etkileşimler Kapsamlı belgeler yerine çalışan yazılım
Sözleşme görüşmeleri yerine sürekli müşteri (kullanıcı) etkileşimi Plana bağlı kalmak yerine değişikliğe yanıt verebilme
Çevik Metodolojilere örnek olarak Adaptive Software Development (ASD), Agile Modelling, Crystal Methods, Dynamic System Development Methodology (DSDM), Extreme Programming (XP), Feature Driven Development, Lean Development, ve Scrum verilebilir ancak bu çevik metotlar arasında belki de en duyulanı Extreme Programming veya XP olmuştur.
4.3. Metodolojilerinin Karşılaştırılması
Çevik metodolojiler ile yazılım mühendisliği metodolojileri yani süreç güdümlü metotlar karşılaştırıldığında her iki grup için de olumlu ve olumsuz görüşler ifade edilmektedir.
Çevik metotlar için “insan merkezli” denmekte, insan faktörü çok önemle öne çıkmaktadır. Yazılımcıların yetenekli, bilgili, deneyimli ve çok iyi iletişim kurabilen kişiler olması beklenir. Bilginin, usta yazılımcıların deneyiminde ve aklında saklı olduğu kabul edilerek onların kararlarına fazla sorgulamadan güvenilir.
Yazılım mühendisliği metodolojilerinde ise bilgi, yazılı belgelerde ve eğitimdedir. Güven, işi yapanın dışındaki kontrol ve onaylarda aranır. Kişisel yetenekleri fazla yüksek düzeyde olmasa da bir yazılımcı için “kurallara uyduğunda iyi yazılım çıkarır” varsayımı vardır.
Yazılım mühendisliği metodolojileri süreçlerini olgunlaştırmakla ve kurumsallaştırmakla kişilerden bağımsız hale getirmeye çalışırlar. Fakat bunu yaparken değişimlere ayak uyduramama riski taşırlar. Çevik metotlar ise uzun vadeli planlara fazla bağlılık taşımamakla esneklik sağlar ve değişimlere daha rahat uyum gösterirler. Müşteri davranışının yazılım projelerinin başarısını etkilediği bilinmektedir. Yazılım mühendisliği metodolojilerinde müşteri ile geliştiricinin üzerinde anlaştığı bir sözleşme iki tarafı da bağlar. Ara sıra gözden geçirme toplantıları olsa da sonuçta geliştirici sözleşmede istenenleri yapmakla sorumluluğunu yerine getirir. Sözleşmeye uyuldukça sorun yoktur. Ancak bu yaklaşım çok kez sorunlara neden olur. Müşteri istekleri tam olarak belgelenemeyebilir, başlangıçta tam bilinmeyebilir, istekler değişebilir, yorum farklılıkları olabilir, veya teknoloji değişebilir. İş teslim edilirken müşterinin “ben tam böyle istememiştim” sözü çok duyulmuştur.
Çevik metotlar ise müşterinin veya kullanıcının mutlaka geliştirici ile sıkı işbirliğini ve beraberliğini öngörür. Çevik metotlarda müşterinin özellikle geliştirme aşamasında aktif olarak işin içinde bulunması istenir. Bu nedenle bu metotların kullanımında bilgili, işbirlikçi, temsil yeteneği ve yetkisi olan müşteri gereklidir.
İsterlerin değişkenliği yazılım mühendisliği metodolojilerinde bazen sorun yaratabilir. İsterlerin en azından belirli sürelerde kararlı kalması istenir. Başarı şansı, isterlerin yeterince kararlı bir duruma gelmesi ile yükselir. Küçük değişikliklere elbette yer vardır. Değişiklik istekleri büyüdükçe bunların yeni versiyonlarda yer alması planlanabilir. Ancak süreç güdümlü metotlarda anlık tepki esnekliği yoktur. Çevik metotların ise özellikle, isterlerin baştan iyi tanımlanamadığı, sürekli yenilerinin ortaya çıktığı ve değişimin kaçınılmaz olduğu durumlarda daha uygun olduğu söylenmektedir. Geliştirmenin son aşamalarında bile yeni isterlerin ortaya çıkmasına hoşgörü ile bakmak, çevik metotların ilkelerindendir. Ancak bu ilke, müşteri memnuniyeti getirebileceği gibi risk de taşır.
5. UML
Yazılım teknolojisi geliştikçe yazılan programların karmaşıklığı ve zorluğu giderek artmaktadır. Karmaşık projelerde kod organizasyonu yapmak oldukça zordur. İleride doğabilecek birçok problemin çıkmasına engel olmak için programın analiz ve dizayn aşamasında modellemenin doğru yapılması gerekmektedir.
Sistem tasarımcısının ilk aşamada yapması gereken çalışma, kullanıcı gereksiniminin belirlenmesidir. Gereksinim belirleme aşaması, bir yazılım projesindeki en kritik aşamadır. Bu aşamada değişik mesleklerden birçok insan bir sistem oluşturmak için bir araya gelir. Grupta temel olarak müşterinin alan uzmanları ve yazılım firmasının teknik elemanları yer alır. Sistemin tasarımını ve gerçekleştirimini üstlenen yazılımcılar genellikle problem alanıyla ilgili olarak o alanın profesyonelleri kadar bilgi ve deneyime sahip değillerdir. Buna karşılık müşterinin de yazılım geliştirme konusundaki bilgisi sınırlıdır. Daha önce bir proje geliştirme ortamında birlikte çalışmamış bu insanlar arasında terminoloji eksikliği de göz önüne alındığında iletişim problemlerinin doğması kaçınılmazdır. Bu iletişim problemlerini en aza indirmek için de modellemede ortak bir gösterim biçiminin, bir başka deyişle ortak bir modelleme dilinin kullanılması zorunludur.
Mühendislik dallarındaki grafik iletişimin başarısı olağanüstü bir örnektir. Farklı anadillere sahip ve üstelik birbirlerinin dillerine de hakim olmayan mühendisler mesleki işlerini bu grafik dillerde yürütebilirler. Dünyadaki bütün elektrik mühendisleri için bir topraklamanın, bir trafonun, bir transistörün simgesi aynıdır. Tek kelime bile konuşma gereksinimi olmadan tasarımlarını gösterebilirler ve ancak yüzlerce sayfa yazı ile anlatılacak şeyleri sadece bu grafiklerle açıklayabilirler. Yazılım geliştirmeyi sistemli bir biçimde ele alacaksak, bu işi bir mühendislik olarak yapacaksak, bu sektör için de ortak grafik notasyonların bulunması ve kullanılması gereklidir. Yazılım geliştirmede kullanılan çeşitli modellerin ifade edilebilmesi için yazılım sektöründeki herkesin kullanacağı modelleme dillerine ihtiyaç duyulmaktadır.
Yazılımın, diyagram şeklinde ifade edilebilmesi için oluşturulan nesne tabanlı sistemlerin incelenmesi ve tasarımında standart olarak kullanılan ortak modelleme dili UML’dir. Bir diğer deyişle UML, bir yazılım sisteminin inşa adımlarında üretilen işi kâğıt üzerinde göstermemize olanak sağlayan grafiksel dildir.
Geçmiş deneyimler, düz metin ve simgelerin yanında görsel öğeler de içeren modellerin daha anlaşılabilir olduğunu göstermiştir. Bu nedenle UML özellikle görsel öğeler açısından zengin bir dil olarak tasarlanmıştır. UML modelleri yalnızca yazılım profesyonelleri tarafından kullanılmakla kalmayıp, otomatik kod üreteçleri tarafından da okunabilme özelliğine sahiptir.
1970’lerden bu yana çeşitli yazılım geliştirme projelerinde elde edilen deneyimler sayesinde çok sayıda modelleme tekniği ve tekniklerin yanında gelen modelleme dilleri ortaya konmuştur. Bu tekniklerin ve dillerin bazıları yaygınlaşmış bazıları ise günümüzde kullanımdan kalkmıştır.1990’lı yıllar içinde yazılım sektöründe, sadece nesne tabanlı paradigmanın içinden 100’den fazla modelleme dili ortaya çıkmıştır. Bütün büyük firmalar ortada standart bir dil olmadığı için kendi özel dillerini kullanmaya başlamışlardır. Bu firmalarla çalışan müşterileri ve bu firmalardan ayrılıp başka yerlere geçen eski çalışanları da bu dilleri yanlarında götürmüşlerdir. Elbette bir dilin her taşınmasında küçük değişiklikler olmuş buda modelleme dili çeşidini artırmıştır.
Ancak zamanla nesne tabanlı yazılım geliştirmede çok büyük fikir adamları ve herkesin sözlerine önem verdiği Booch, Rumbaugh ve Jacobson’un modelleme teknikleri ve dilleri yaygınlık kazanmıştır. Ardından bu üçlü bu durumun farkına varıp kendi modelleme dillerinin güçlü yanlarını bir araya getirerek tek bir dil oluşturmaya karar vermişlerdir. UML ( Unified Modelling Language - Birleşik Modelleme Dili ) 1997 yılında bu çabanın bir ürünü olarak ortaya çıkmıştır. UML dilini oluşturan bu üçlüye Üç Amigo ( Three Amigoes ) adı takılmıştır. UML, yazılım sektöründeki yaygın teknikler ve yazılım dışı sektörlerin yararlı tekniklerinin çok iyi bir harmanını sunabilmiştir.
5.1. UML’nin Olumlu Yanları
UML iyi tasarlanmış bir modelleme dili olduğu için yazılım geliştirme ile bir ucundan ilgisi olan herkesin kullanmasına uygun notasyonları vardır. Müşteri ile olan iletişimden programcılar arasındaki iletişime kadar her düzeyde soyutlamaya olanak veren şekilleri vardır. Yani sürecin her aşamasına hitap etmeyi amaçlar.
.
Başlıca faydaları şunlardır:
Program kodlanmaya başlamadan önce geniş bir analizi ve tasarımı yapılmış olacağından kodlama işlemi daha kolay olur. Çünkü programdan ne beklendiği ve programlama ile neler yapılacağı profesyonel bir şekilde UML ile belirlenmiş olur.
Programda beklenmedik bir takım mantıksal hatalar ( bug ) minimuma indirgenmiş olur.
Tasarım aşaması düzgün yapıldıysa tekrar kullanılabilen kodların sayısı artacaktır. Buda program geliştirme maliyetini büyük ölçüde düşürecektir. UML diyagramları programın tamamını kapsayacağı için bellek kullanımı
daha etkili hale getirilebilir.
Programın kararlılığı artacaktır. UML ile dökümanlandırılmış kodları düzenlemek daha az zaman alacaktır.
Ortak çalışılan projelerde programcıların iletişimi daha kolay hale gelir. Çünkü UML ile program parçalara ayrılır ve parçalar arasında bir ilişki kurulur.
5.2. UML’nin Olumsuz Yanları
Gerçek-zamanlı analiz günlerinde sistemin işlevselliğini açıklamak için bir süreç modelimiz (örneğin veri akış diyagramı) ve nedensel bağımlılık (bir fonksiyonun çıktı üretmesi için gerekli girişlerin başka fonksiyonca sağlanması gibi) mevcut idi. Bu nedenselliğin yetersiz kaldığı durumlarda kara tabloları, süreç aktivasyon tabloları ve durum diyagramları fonksiyonun çalışmasını etkilemek için kullanılırdı. Bu davranışı ifade edebilmek için yeterli idi. Şimdi ise kullanıcı durumlarına, ardışık diyagramlar ya da işbirliği diyagramları formunda etkileşim diyagramlarına, durum diyagramları ve aktivite diyagramlarına sahibiz. Bu ise sistemin dinamik davranışını ifade edebilmek için 2 yerine 5 diyagrama sahip olduğumuz anlamına gelmektedir.
Ağır yazılım süreçlerinde diyagram çizimlerinin zaman kaybına neden olup sisteme zarar vermemesi için yazılım ekibinin diyagramları nasıl kullanışlı hazırlayacağı ve tuzaklardan nasıl kaçınacağı konusunda eğitilmesi gerekiyor.
UML diyagramlarında dikkat çeken problem insanların diyagramları ayrıntılı ve kendini açıklayabilecek şekilde hazırlamaya çalışmalarıdır. Kod ayrıntının ve asıl bilginin bulunduğu yerdir. Bu bilgiyi diyagramlarda sunmaya çalışmak diyagramları amacından saptırır.
Diyagramın ilk amacı iletişimi kolaylaştırmasıdır. Dolayısıyla öncelikle diyagramların ne için hazırlandığı sürekli akılda tutulmalıdır. UML’nin etkili kullanımını sağlamak için önemli öğeler seçilmeli önemsizler gözardı edilmelidir. Çizim sadece önemli nesneleri içermelidir. Her durum için Sequence diyagramları çizilmemeli anahtar durumlar seçilmeli ve bunlarda uygulanmalıdır.
Diyagramların başlıca kullanım alanlarından biri kodlamaya başlamadan önce tasarımın yeterliliğini görmektir. Karmaşık bir özelliğin kodlanmasından önce kısa bir tasarım çalışması yapmak çok yararlıdır. Tasarım aşamasında sadece önemli yapılar üzerinde yoğunlaşılmalı bütün detayları çözmeye çalışmamalıdır. Sonuç tasarım taslak vazifesi görmeli, son tasarım vazifesi değil. Şöyle ki ilk başta biraz tasarım yapıldığında bu tasarımdaki hataların, yanlış varsayımların farkına daha
sonraları özellikle kodlamaya başlandığında varılabilir. Bu problem olmayabilir çünkü tasarım değiştirilebilir. Fakat problem insanların tasarım aşamasının bittiğine inandığı durumlarda ortaya çıkar çünkü bu tür durumlarda kodlamadan gelen geri bildirim bitmiş olur tasarıma etki edemez. Tasarımı değiştirmek diyagramların değişeceği anlamına gelmeyebilir. Tasarım için taslak şeklinde bir diyagram hazırlayıp daha sonra bu atılabilir. Diyagram tasarımı anlamak için yararlı olacaktır fakat bu aşamadan sonra önemli belgeler haline gelmemelidirler. En iyi diyagramlar bu şekilde kullanılmayan ana yapı haline gelmeyen diyagramlardır.
UML diyagramlarının kullanım amaçlarından bir başkası da dokümantasyondur. Genel kullanımı ile diyagramlar bir case aracının içinde bulunur. Bu şekilde insanların çalışmasının kolaylaşacağı düşünülür fakat pratik bu düşüncenin tamamen yanlış olduğunu göstermektedir. Bir günlük bir UML modellemesinin sonunda bir günde üretilebilecek kod çıkar ancak sonuç itibari ile programcının gidip kodu elle düzenlemesi ve pek çok değişiklik yapması gerekir. Kısa zamanda diyagramlar ve kod arasındaki senkronizasyon bozulur. Aynı bilgiyi iki farklı yerde senkronize olarak tutmak gerekmektedir, güncel tutulabilmek için de zaman harcamak gereklidir. Bunu engellemek için sadece çok fazla zahmet gerekmeksizin güncel tutulabilecek diyagramlar kullanılmalıdır. Diyagramlar herkesin görebileceği bir yerde bulundurulmalı ve basit değişiklikler için insanların bu diyagramları kalemle değiştirmelerine olanak verilmelidir. İnsanların bu diyagramları kullanmadığı gözlemlendiğinde diyagramlar atılmalıdır.
Son olarak UML diyagramlarının iki ilgili grup arasında el değiştirdiği durumlara değinelim. Dokümantasyon oluşturmak müşteriye değer kattığı zaman UML yararlıdır ve iletişimi kolaylaştırır. Bir diyagram binlerce kelimeye bedel olabilir fakat yine diyagramlar seçilerek önemli öğeleri içerecek şekilde hazırlanmalıdır. Kod ayrıntılı bilginin olduğu tek yerdir. Diyagramlar kodun içerdiği bilginin özeti ve önemli noktalarını açığa çıkarmak açısından kullanılmalıdır.
5.3. Uml Diyagramları
UML gereksinim belirlemeden tamamlanmış sistemin testinin yapılmasına kadar yazılım geliştirme sürecinin farklı aşamalarında kullanılabilir. Genellikle gereksinim belirleme, tasarım ve dökümantasyon amaçlı kullanılmaktadır.
UML uygulamanın analizinden dizaynına dek geliştirme süresince yazılım modellemesinde kullanılan görsel bir tekniktir ve UML 2.1 sürümü ile 13 ayrı diyagrama sahiptir.
Bunlar:
Paket Diyagramları ( Package Diagrams ) : Paketler ve öğelerinin organizasyonunu yansıtmak amacıyla kullanılır, isimuzaylarının görselleştirilmesini sağlar, hem fiziksel hem de mantıksal ilişkileri göstermek için kullanılabilir.
Sınıf veya Yapısal Diyagramlar ( Class or Structural Diagrams ) : Gerçek dünyada eşyaları nasıl araba, masa, bilgisayar şeklinde sınıflandırıyorsak yazılımda da birtakım benzer özelliklere ve fiillere sahip sınıf adı verilen gruplar oluştururuz. Sınıf diyagramları kendi başlarına son derece yalın yapılardır ve görsel olarak çizilmeleri, ancak aralarındaki ilişkilerle birlikte incelendiklerinde anlamlıdır. UML’deki sınıf diyagramları sistemin durağan yapısını tanımlamak için kullanılır.
Nesne Diyagramları ( Object Diagrams ) : Sınıf diyagramlarının doğruluğunun test edilmesi için kullanılan nesne diyagramları sistemin belirli bir andaki durumunu gösterirler.
Karma Yapı ( Composite Structure ) : Bu diyagramlar bir sınıflandırıcının dahili yapısını sistemin diğer parçaları ile olan etkileşim noktalarını belirterek göstermek için kullanılır. Sınıflandırıcıyı içeren davranışı gerçekleştirmek için beraber olan parçalarının ilişki ve konfigürasyonunu gösterir.
Bileşen Diyagramları ( Component Diagrams ) : Özellikle birden çok geliştiricinin yürüttüğü projelerde sistemi bileşen dediğimiz parçalara ayırmak, geliştirmeyi kolaylaştırır. Genel olarak; tek başına çalışabilen alt modüller bileşen olarak düşünülebilir. Bu diyagramlarla bileşenler arasındaki
bağımlılıklar belirlenebilir ve bileşenler arasındaki organizasyon net olarak ortaya konabilir.
Yaygınlaştırma Diyagramları ( Deployment Diagrams ) : Bu tür diyagramlarla sistemin fiziksel incelenmesi yapılır. Mesela bilgisayarlar arasındaki bağlantılar, programın kurulacağı makineler ve sistemimizdeki bütün aletler bu diyagramlarla gösterilir
Kullanım Durum Diyagramları ( Use Case Diagrams ) : Kullanıcı senaryoları, kullanıcı-sistem etkileşimini modellemek için kullanılan bir yöntemdir. Diğer bir deyişle üzerinde çalıştığımız uygulama ile uygulamadan etkilenen dış kullanıcılar(aktör) arasında geçen iş hedeflerine uygun bir dizi etkileşime Use Case denir. Use Case 'ler sistemin kabaca ne yaptığı ile ilgilenir, kesinlikle nasıl ve neden yapıldığını incelemez.
Aktivite Diyagramları ( Activity Diagrams ) : Çok parçacıklı (multithreaded) uygulamalar geliştiriliyor ve bu uygulamaların algoritmik mantığı UML ile gösterilmek isteniyorsa bu diyagramlar kullanılmaktadır. İş akışını, bir süreci veya karmaşık bir algoritmayı UML ile modellemek için yine bu diyagramlar kullanılabilir. Aktivite diyagramları sayesinde iş süreçleri gözden geçirilerek, gereksiz şekilde ardışık yapılan işlemlerin paralel olarak yapılabileceği belirlenebilir. Ayrıca; bir veya daha fazla kullanım senaryosunun ayrıntıları bu diyagramlar sayesinde ortaya konulabilir.
Durum Makinesi Diyagramları ( State Machine Diagrams ) : Gerçek nesnelerin herhangi bir zaman içindeki durumunu gösteren diyagramlardır. Yani sistem içindeki sınıfların dışarıdan yapılan uyarılara ve tetiklemelere karşı sergilediği davranışları gösterir. Nesnelerin gelişen olaylara karşı içinde bulunduğu durumları modeller.
İletişim Diyagramları ( Communication Diagrams ) : Önceki sürümlerde işbirliği diyagramları(collaboration) olarak adlandırılan diyagramlardır. Bir sistemin amacının yerine gelmesi için sistemin bütün parçaları işlerini yerine getirmesi gerekir. Bu işler genellikle birkaç parçanın beraber çalışmasıyla mümkün olabilir. Bu tür ilişkileri göstermek için iletişim diyagramları kullanılır. Sistemin durağan ve dinamik davranışlarını birlikte gösterir.
Sıra Etkileşim Diyagramları ( Sequence Diagrams ) : Nesnelerin peşi sıra etkileşimde bulunmaları ve nesnelerin zaman boyutunda birbirleri ile ilişkiye girmelerini göstermek amacıyla kullanılır. Yani ardıl etkileşim diyagramları nesnelerin birbirleriyle haberleşmesini zaman boyutunda ele almaktadır. Zamanlama Diyagramları ( Timing Diagrams ) : Zamanla bir veya birden
fazla öğenin değer veya durum değişimini göstermek için kullanılır. Zamanlanmış olaylar, zaman ve onları etkileyen kısıtlamaların sürekliliği arasındaki etkileşimi de göstermektedir.
Etkileşim Tanıtma Diyagramları ( Interaction Overview Diagrams ) : Aktivite diyagramlarının etkileşimi gösteren kısımlarını içermektedir. Hemen hemen aktivite diyagramları ile aynı olmakla birlikte iki yeni özelliği etkileşim olayları ve etkileşim öğelerini bu diyagramlara eklemesidir.
UML Diyagramları bir sistemin farklı yönlerini ve özelliklerini gösteren diyagramlardır. Bir sistemin modellenmesinde sistem hangi yönden incelenmek isteniyorsa ona uygun diyagram seçilir ve çizilir. Geliştiricinin özelleşmiş ihtiyaçlarına bağlı olarak yazılımcıların bir kısmı model sistemlerindeki tüm diyagramları ve object management group tanımlamalarını kullanmada katı bir tutum ve özen gösterip gereksiz çizimlerle vakit kaybederken bir kısmı da kullanım senaryosu ve sınıf diyagramlarıyla yetinmektedir. Aşağıdaki grafik Martin Grossmana, Jay E. Aronsonb, Richard V. McCarthy tarafından yapılan araştırma sonuçlarından alınan UML diyagramlarının kullanım oranlarını göstermektedir. Bu grafik gösteriyor ki en çok kullanılan diyagramlar usecase, class ve sequence diyagramlarıdır.
Şekil 5.1 : UML diyagramlarının kullanım oranları
5.4. Uml Örnek Uygulama
En çok kullanılan beş diyagramları örneklemek amacıyla bir uzaktan eğitim sistemi modellenmiştir.
Uzaktan eğitim, öğrenci ile öğretmenin birbirinden uzakta olmalarına karşın eş zamanlı ya da ayrı zamanlı olarak bir araçla iletişim kurdukları bir eğitim sistemidir. Uzaktan eğitim sistemleri internet veya web üzerinden öğrenci ve öğretmen arasında eğitim alıp veren istemci sunucu sistemleri gibi düşünülebilir.
Gereksinim belirlemek için öncelikle sistem aktörleri olan temel katılımcıların tanımlanması gerekir. Uzaktan eğitim sistemlerinde kullanıcı grupları açıkça birbirinden ayrılmaktadır : öğrenciler, öğretmenler, yöneticiler, öğrenci işleri, vs gibi .Verilen Örnekte öğrenci ve öğretmen aktörleri üzerinde durulmuştur.
5.4.1. Kullanım Durumu ( Use Case )
Bir kullanım durumu bir sistemin, sistem dışındaki bir aktörün gözlemleyebileceği bir faydası olan bir sonuç verecek şekilde çalıştığı bir dizi eylemi ve varsa bu eylemdeki çeşitli değişik akışları tanımlayan bir belgedir.
Kullanım durumları kendi başlarına bir yada birden fazla senaryoyu içeren özel birer kısa film gibi düşünülebilirler.
Kullanım durumu özellikleri:
Sadece ve sadece bir tanımdır. Herhangi bir notasyon ya da programlama diline yönelik bir anlatım değildir. Sadece metin olabileceği gibi UML şemaları ve tablolarla da desteklenebilir.
Kullanım durumunun hitap ettiği bir ana aktör ve bu kullanım durumu sonunda bu ana aktörün elde ettiği bir fayda yani sonuç olmalıdır.
Her koşulda kullanım durumları ardışık olarak olan olayları, etkinlikleri listeler. Yani bir kullanım durumundaki adımlar takip edilerek bir sonuca ulaşılacaktır.
Birden fazla akış olabilir. Bu akışların her biri farklı sonuçlar verebileceği gibi aynı sonuca daha farklı şekillerle ulaşılmasını da sağlayabilirler.
Şekil 5.3 : Kullanım Durum Diyagramı: Öğretmen
Kullanım Durumu: Öğretmen sistemde oturum açar
Aktör Öğretmen
Kapsam Öğretmen kendisine verilen kullanıcı adı ve şifresiyle sistemde oturum açmak yani sisteme giriş yapmak ister.
Adımlar 1.Öğretmen kullanıcı adını girer
2.Sistem öğretmenin kullanıcı adını alır veritabanında bu isimde bir kullanıcı olup olmadığını sorgular varsa kullanıcı adı ve soyadını göstererek şifre sorar
3.Öğretmen şifresini ilgili alana yazar ve giriş butonuna tıklar
4.Sistem bu kullanıcının şifresinin doğruluğunu kontrol eder ve onaylanırsa öğretmenin yapabileceği işlemlerin listelendiği menüyü görüntüler.
Alternatif Akış Koşulu
Öğretmen kullanıcı adını yanlış girer.(Adım1)
Alternatif Akış 1.1.Sistem kullanıcıyı bu isimde bir kullanıcı olmağına dair uyarır ve yeniden kullanıcı adını girmesini ister
1.2.Öğretmen kullanıcı adını yeniden girer
1.3.Kullanıcı adı doğru girilince ana akışa dönülür 1.4.Kullanıcı adı yanlış girilince yeniden sorulur 1.5.Beş kez yanlış girerse akış sona erdirilir. Alternatif Akış
Sonrası
Öğretmen kullanıcı adını doğru girmiştir ve ana akışa dönülmüştür ya da
Öğretmen kullanıcı adını yanlış girmiştir ve beş deneme sınırını aşarsa akışa son verilmiştir
Alternatif Akış Koşulu
Öğretmen şifresini yanlış girmiştir(Adım 3)
Alternatif Akış 3.1.Sistem kullanıcı adına göre şifreyi çeker ve kullanıcıyı şifrenin hatalı olduğu konusunda uyarır ve yeniden şifre girmesini ister
3.2.Öğretmen şifresini adını yeniden girer 3.3.Şifre doğru girilince ana akışa dönülür 3.4.Şifre yanlış girilince yeniden sorulur
3.5.Üç kez yanlış girilirse kullanıcı askıya alınır ve akış sona erdirilir. Alternatif Akış
Sonrası
Öğretmen şifresini doğru girer ve ana akışa dönülür Ya da
Öğretmen şifresini yanlış girer ve üç deneme sonrasında hala yanlışsa kullanıcı askıya alınır ve akış sonlandırılır.
Sonuç Öğretmen sistem tarafından tanınmış ve oturum açılmıştır
5.4.2. Sınıf Diyagramları
Sınıf (class), aynı metotları (işlev), aynı ilişkileri ve aynı anlamı paylaşan nesneler topluluğunun ortak tanımıdır. Uygulamalarımızın yapıtaşları olan sınıfları ve bunlar arasındaki ilişkileri modellemek için kullanılan sınıf diyagramları UML’in en sık kullanılan diyagram çeşididir.
Sınıfları tasarlarken dikkat edilmesi gereken önemli bir tasarım kriteri sadeliktir. Bir sınıf ne kadar genel bir kavrama hitap ediyorsa o kadar sadeleşir ve yalınlaşır. Gereksiz özelliklerin olmaması gerekir. Bu, özelliklerin ve işlemlerin sayıca az ve basit bir biçimde organize olmasından anlaşılabilir.
UML, sınıfları görsel olarak üçe bölünmüş dikdörtgenlerle tanımlar. Dikdörtgenin birinci bölümüne sınıfın adı, ikinci bölümüne içerdiği niteliklerin (attributes) adı, üçüncü bölüme de içerdiği metotların (methods) listesi yazılır.
Sınıf diyagramında yer alan nitelik ve metot isimlerinin önünde aşağıda sıralanan bezemeler (adornments) kullanılabilir.
Özel (-) : Nitelik ya da metoda sınıf dışından erişim engellenmiştir, sadece var olan sınıf içinden görüntülenebilir.(private)
Korumalı (#) : Nitelik ya da metoda erişim sınırlandırılmıştır (protected), sadece kalıtım yoluyla türetilmiş alt sınıflar ve kendi sınıfı içinden görülebilir
Genel (+) : Nitelik ya da metot genel kullanıma açıktır (public)
Şekil 5.4 : Sınıf örneği Öğrenci +ÖğrenciNo:String +AdSoyad : String #Adres : String #Tel : String -Fakülte : String
+NotHesapla(in not1:decimal,not2:decimal) : decimal #DönemOrtÖğren(in yil:string,donem:string) : decimal
Bir sınıf diyagramında kullanılabilecek temel yapılar bunlar olmasına rağmen "constraints" ve "notes" dediğimiz elemanları da ekleyebiliriz. Notes(Notlar) genellikle işlevlerin ve özelliklerin hakkında bilgi veren opsiyonel kutucuklardır. Constraints (koşullar) 'ler ise sınıfa ilişkin birtakım koşulların belirtildiği ve parentez içinde yazılan bilgilerdir.
Sınıf diyagramları kendi başlarına son derece yalın yapılardır ve görsel olarak çizilmeleri, ancak aralarındaki ilişkilerle birlikte incelendiklerinde anlamlıdır.
Sınıflar arası olası ilişki türleri:
Birliktelik(Association) : Uzun süreli bir ilişki olarak düşünülmelidir.İki sınıfa ait nesneler birlikte çalışıyorsa bu türden bir ilişki olacaktır.Bütün birliktelik ilişkilerinde en az bir ilişki yönü bulunur.Bu yön, ilişkideki roller tarafından belirlenir.
Simge Anlamı
1 Bir ve yalnız bir ilişkide bu sınıfa ait bir ve yalnız bir nesne bulunur 0..1 Sıfır ya da bir. Bu sınıfa ait nesnelerden ya hiç olmaz ya da sadece bir tane
olur.
1..* En az bir. Bu sınıfa ait en az bir nesne bulunacaktır, ancak sayıda bir üst sınır yoktur.
0..* Herhangi bir sayı. Bu sınıfa ait hiçbir nesne olmayabilir. Bir üst sınırda yoktur.
a..b En az a tane en çok b tane nesne vardır.
Şekil 5.5 : Birliktelik simgeleri ve açıklamaları
Parça-bütün ilişkisi(aggregation):Bir nesne başka nesnelerden parçalardan oluşuyorsa o zaman bu ilişki geçerlidir.
İlişki gösteriminde içi boş baklava şekli kullanılıyorsa parçalar tek başlarına bulabilir, içi dolu baklava şekli kullanılıyorsa tek başlarına bulunamazlar. İçi dolu baklava daha güçlü bir bağlılığı simgelemektedir ve bu ilişkiye özellikle bileşke(composite) adı da verilir.
Şekil 5.6 : Genel Sınıf Diyagramı
5.4.3. Ardıl Etkileşim Diyagramları (Sequence Diagrams)
"Sequence" kelime anlamı olarak "birbirini takip eden, ardışık olan, peşi sıra" anlamlarına gelir. UML diyagramı olarak ise nesnelerin peşi sıra etkileşimde bulunmaları ve nesnelerin zaman boyutunda birbirleri ile ilişkiye girmeleri anlamında kullanılmaktadır. Yani "sequence" diyagramları nesnelerin birbirleriyle haberleşmesini zaman boyutunda ele almaktadır. Bir diyagramın zamana bağlı olmasından kasıt, nesnelerin gerçekleştirdikleri aktivitelerin peşi sıra gerçekleşmesi ve bu peşi sıralığın belirlenen zaman dilimleri içerisinde meydana gelmesidir.
Bir "sequence" diyagramı temel olarak nesnelerden(objects), mesajlardan (messages) ve zaman eksenlerinden(timeline) oluşmaktadır
Tasarım ve modellemenin en küçük yapı taşı olan nesneler belirli görevleri gerçekleştirmek için tanımlanan yapı bloklarıdır. Sequence diyagramlarında nesneler dikdörtgen ve bu dikdörtgen içinde nesne ismi olacak şekilde temsil edilir. Sequence diyagramlarında nesneler genellikle diyagramın fiziksel olarak en üstünden ve soldan sağa olacak biçimde sıralanır. Yani nesnelerin sequence diyagramlarındaki orijini sol üst köşedir ve yayılım biçimi soldan sağadır.
Yukarıdan aşağıya doğru inen hatlar zaman çizgisini oluşturmaktadır.
Soldan sağa doğru sistemde ilerleyen mesajları yada emirleri, sağdan sola doğru da gelen yanıtları belirten oklar kullanılmaktadır.
Bazı mesajlar için koşullar olabilir. Bu koşullar köşeli parantezler içinde belirtilir.
Bir noktadan çıkan alternatif akışlar aynı noktadan çıkan birden fazla ok ile gösterilir.
Zaman çizgisi üzerindeki kutular, söz konusu aktörün ya da sınıfın bir süre boyunca bir iş ile uğraştığını gösterir.
Ana senaryo, aktörle amacı arasındaki en kısa ve en sorunsuz iş akışının adımlarını içermektedir. Bu senaryo yazılırken hiç bir sorun yaşanmadığı varsayılır. Bu nedenle ana senaryo “mutlu senaryo” veya “güneşli gün senaryosu olarak ta anılır. Aşağıda kullanım durumları bölümünde senaryosunu yazdığımız “Öğretmen sistemde oturum açar” durumunun mutlu senaryosu sıra diyagramları ile gösterilmiştir.
