Yazılım Mühendisliği Hafta - 6 Tasarım - EEMB DERSLER · Yazılım Mühendisliği Bölüm –6 Tasarım 23.03.2013 Yazılım Mühendisliği Yansı - 9 Veri tasarımında dikkat

1

23.03.2013 Yazılım Mühendisliği 1

Yazılım Mühendisliği

Hafta - 6

Tasarım

Bölüm – 6 Tasarım

23.03.2013 Yazılım Mühendisliği

Yansı - 2

Giriş

Tasarım, Sistem Analizi çalışması sonucunda üretilen

Mantıksal Modelin Fiziksel Modele dönüştürülme

çalışmasıdır.

Fiziksel Model geliştirilecek yazılımın;

hangi parçalardan oluşacağını,

bu parçalar arasındaki ilişkilerin neler olacağını,

parçaların iç yapısının ayrıntılarını,

gerekecek veri yapısının fiziksel biçimini (dosya, veri

tabanı, hash tablosu, vektör, vs)

tasarımını içerir.



Yansı - 3

Tasarım Kavramları

Soyutlama (abstraction): Detayları gizleyerek

yukarıdan bakabilme imkanı sağlanır.

İyileştirme (enhancement): Soyutlama düzeyinde

irdeleme bittikten sonra, daha alt seviyelere inilerek

tanımlamalarda ayrıntı, bazen de düzeltme yapılarak

tasarımın daha kesinlik kazanması sağlanır.

Modülerlik (modularity): Sistemi istenen kalite

faktörleri ışığında parçalara ayrıştırma sonucu elde

edilir.



Yansı - 4

Modülerlik

Bütün karmaşıklığın tek bir modülde toplanması

yerine, anlaşılabilir ve dolayısıyla projenin zihinsel

kontrol altında tutulması için sistem bir çok modüle

ayrılır.

Modüller, isimleri olan tanımlanmış işlevleri bulunan

ve hedef sistemi gerçekleştirmek üzere tümleştirilen

birimlerdir.



Yansı - 5

Sistem ve modülleri

Sistem

A B C

A A A A

A A A A

Çıkış yelpazesi=3

genişlik

Giriş

yelpazesi

derinlik



Yansı - 6

İşlevsel Bağımsızlık

Modüllere parametre ile veri gönderilir ve sonuç

değer alınır.

Bu modülü çağıran program parçası sadece bu

sonucu kullanabilir.

Çağrılan modülün işlevsel olarak yaptıkları ile ilgili

değildir.

2



Yansı - 7

Veri Tasarımı

Yapı Tasarımı, arayüz tasarımı ve süreç tasarımından

önce yapılması gereken ilk tasarım veri tasarımıdır.

Bilgi saklama ve soyutlama bu işlem için önemli

kavramlardır.


Verilerin Düzenlenmesi

Değişik tekniklerle veri toplama işlemi gerçekleştikten

sonra bu verilerin düzenlenmesi gerekir.

Her alınan bilgi incelenmeli ve sistem tasarımcılarının

anlayabileceği şekilde sunulmalıdır.

Bu eylemi gerçekleştirmek için en bilinen ve

kullanılan bazı yöntemler; veri akış şemaları, varlık

ilişkili şemalar, karar tabloları ve karar ağaçlarıdır.

23.03.2013

Yansı - 8




Yansı - 9

Veri tasarımında dikkat edilecek konular

Değişik veri yapıları değerlendirilmelidir.

Bütün veri yapıları ve bunlar üzerinde yapılacak işlemler tanımlanmalıdır.

Alt düzeyde tasarım kararları tasarım süreci içerisinde geciktirilmelidir.

Bazı çok kullanılan veri yapıları için bir kütüphane oluşturulmalıdır.

Kullanılacak programlama dili soyut veri tiplerini

desteklemelidir.


Veri Akış Şemaları

Veri akış şemaları (Data Flow Diagram - DFD) ile

verinin sisteme girişini, sistemde işlenişini, işleniş

esnasında sistem içindeki hareketleri, işlendikten

sonra sistem içinde saklanması veya sistem dışına

gönderilmesi gibi aşamalarda izledigi yol görsel

olarak ifade edilir.

Verinin işleyiş sırasında kimler tarafından ve ne

şekilde işlendiği de gözler önüne seriliyor.

23.03.2013

Yansı - 10




Veri akış şemaları fiziksel ve mantıksal olarak ikiye

ayrılırlar.

Fiziksel Veri Akış Şemaları: bu şemalar uygulama bağımlı

şemalardır.

Gerçek sistemde yer alan donanım, değişik bölümlerdeki

değişik insanlar vb. Bu şemalarda yer alır.

Mantıksal Veri Akış Şemaları: sistemdeki eylemlerin nasıl

gerçekleştiğinden çok sistemde nelerin yer aldığı üzerinde

durulur.

23.03.2013

Yansı - 11



Veri Akış Şeması Elemanları Veri Akış Şeması

Elemanları Özellikler Gösterimi

Yourdon & Coad Gane & Sarson

İşlem(Process): veri üzerinde gerçekleşen iş birimidir.

Numarası, adı, tipi, tanımlaması, girdilerin ve çıktıların veri akışı, notlar

Veri Akışı (Data Flow):işlemler arası verinin akışını gösterir

Numarası, adı, tipi, tanımlaması, başka isim, nitelik, notlar

VERI AKIŞI

VERI AKIŞI

Veri Depolama (Data Storage):verinin mantıksal depolanması

Numarası, adı, tipi, tanımlaması, başka isim, nitelik, notlar

Veri Deposu

Dış Varlık (External Entity):verinin kaynağı yada gideceği yerdir.

Etiketi, tipi, tanımlaması, başka isim, nitelik, notlar

İŞLEM İŞLEM

Veri

Deposu

Dış Varlık Dış Varlık

23.03.2013

Yansı - 12


3



Bu elemanlar kullanılarak bir veri akış şeması

çizilebilir ancak dikkat edilmesi ve uyulması gereken

bazı kurallar bulunmaktadır.

Her işlem için bir giriş bir de çıkış veri akışı olmalıdır

Her işlem kendine gelen veriyi işleyip yeni bir veri

üretmelidir.

Her veri deposu en az bir tane veri akışına katılmalıdır.

Her dış varlık en az bir veri akışına katılmalıdır

Bir veri akışı en az bir işleme eklenmelidir.

23.03.2013

Yansı - 13



Veri akış şemalarında genelden özele denebilecek bir

yapıyla ele alınmaktadır.

Bu yapının daha iyi işleyebilmesi için veri akış

şemaları katmanlardan oluşur.

Bu katmanlarda sistem en üst katmanda en genel

durumuyla en alt katmanda ise istenen en özel

birimiyle ifade edilir

23.03.2013

Yansı - 14




Örnek

Bu kurallar doğrultusunda, bir kumaş fabrikasından kumaş alıp,

aldığı kumaşı işleyip müşterilerine satan bir firmanın veri akış

şeması:

Şekilde kumaş fabrikası ve müşteri dış varlık, dikiş ise işlemdir. Bu

elemanlar arasında ilişki olduğunu gösteren oklar ise veri akışını

ifade etmektedir.

İlişki: kumaş fabrikasından gelen kumaşlar dikiş işleminden geçip

müşteriye sunulmakta, aynı zamanda müşterilerden bir karşılık

alınıp kumaş fabrikasına verilmektedir.

MÜŞTERI

DİKİŞ

KUMAŞ

FABRIKASI

23.03.2013

Yansı - 15



23.03.2013

Yansı - 16



Varlık İlişkili Şemalar

Varlık ilişkili şemalar (Entity Relationship Diagram –

ERD) sistemin kullanacağı veritabanı tasarımında

kullanılır.

Bir sistemdeki varlıkların birbirleriyle olan karşılıklı

ilişkileri görsel olarak ifade eden şemalardır.

Varlık ilişkili şemaları sistemde gerçekleşen bütün

işlemlerin veritabanı eksenli düşünülmesi ile ortaya

çıkan şemalardır. Sistemde yer alan bütün veriler

varlıklara ve bu varlıklar arasındaki ilişkilere aktarılır.

23.03.2013

Yansı - 17



Varlık İlişkili Şemalar

Varlık İlişki Şeması Elemanları Simgeler

Varlık (Entity): verinin depolanmak

istendiği somut veya mantıksal

nesnelerdir. Varlıklar; görevler, olaylar,

yerler, somut nesneler ve kavram

olarak beş şekilde sınıflandırılır.

İlişki (Relationship): iki varlığın

veritabanı içinde veriyi nasıl

paylaştıklarını ifade eder.

Nitelik (Attribute): varlığın özelliklerini

tanımlar.

VARLIK

İLİŞKİ

NİTELİK

23.03.2013

Yansı - 18


4


Örnek

KİTAPLAR KULLANICILAR

ÖDÜNÇ-VERİLEN-

KİTAPLAR

1:N 1:N

yazar

KID ese

radı KullID adı adresi

KullID KID Iade

tarihi

23.03.2013

Yansı - 19



Örnek

Yukarıdaki örnek bir kütüphane sisteminin kitap ödünç

verme modülü için hazırlanmış basit bir varlık ilişki

şemasıdır.

Bu şemada “ÖDÜNÇ-VERİLEN-KİTAPLAR”,

“KİTAPLAR” ve “KULLANICILAR” birer varlık olarak

yer almaktadır.

Şemada 1:N ifadesi ilişkinin nasıl bir ilişki olduğunu

ifade eder. “KullID”, “Adı” gibi ifadeler de varlığın bazı

değerlerini tutmaya yöneliktir ve varlığın niteliklerini

ifade eder.

23.03.2013

Yansı - 20




Yansı - 21

Yapısal Tasarım

Yapısal Tasarımın ana hedefi modüler bir yapı geliştirip modüller arasındaki kontrol ilişkilerini temsil etmektir.

Ayrıca yapısal tasarım bazen de veri akışlarını gösteren biçime dönüştürülebilir.

Veri Akışları Üç parçada incelenebilir

Girdi Akışı

Çıktı Akışı

İşlem Akışı



Yansı - 22

Ayrıntı Tasarım- Süreç Tasarımı

Süreç tasarımı; veri, yapı ve arayüz tasarımından sonra yapılır.

İdeal şartlarda bütün algoritmik detayın belirtilmesi amaçlanır.

Ayrıca süreç belirtiminin tek anlamı olması gerekir, değişik şahıslar tarafından farklı yorumlanmamalıdır.

Doğal diller kullanılabilir (açıklamalarda, çünkü doğal dil tek anlamlı değildir)

Süreç Tanımlama Dili (PDL)



Yansı - 23

Yapısal Program Yapıları

Yapısal programlamanın temel amacı;

program karmaşıklığını en aza indirmek,

program anlaşılabilirliğini artırmaktır.

Bu amaçla şu yapıları kullanılır;

Ardışıl İşlem yapısı

Koşullu işlem yapısı

Döngü yapısı

GOTO kullanımı uygun değildir.



Yansı - 24

Karar Tabloları

Bazen karmaşık koşul değerlendirmeleri yapmak

gerekir. Bunların düzenli bir gösterilimi karar

tablolarında yapılabilir.

Öncelikle, bütün işlemler saptanmalı, sonra ön

koşullar belirlenmelidir.

Belirli işlemler ile belirli koşulları birleştirerek tablo

oluşturulur.

Alt tarafta ise işlemler benzer satırlar olarak gösterilir.

5


Karar Tabloları

Sistemde yer alan bütün verileri ve etkinlikleri

görülebilmesi hatta olası durumların sezilebilmesi ve

gözden kaçırılmaması için etkili bir şekilde

kullanılabilirler.

Karar tabloları, karar verme mantığının tablolar

üzerinde ifade edilmesiyle oluşur. Karar tabloları bir

sistem işlemini anlaşılabilir olması için o işlemin

koşulları ve çalışma biçimini ayırarak sunar.

23.03.2013

Yansı - 25



Karar Tabloları

Bir karar tablosunu meydana getiren 4 eleman vardır.

1. Koşullar: bir karar tablosunda gerekli olan bütün sınamaların listelemesi bazı kaynaklarda “şartlar” şeklinde de kullanılmaktadır.

2. Eylemler: karar tablosunda yer alan bütün işlemlerin listelenmesi, bazı kaynaklarda “faaliyetler” şeklinde de kullanılmaktadır.

3. Koşul Kuralları: koşulların gerçekleşmesinde karşılaşılabilecek olası durumları listelemesi

4. Eylem Kuralları: koşul kurallarına göre karar verilen eylemin belirtilmesi.

23.03.2013

Yansı - 26




Yansı - 27

Karar Tablosu Örneği-Hesap

Kurallar 1 2 3 4

Hesap Geçerli X X X X

Şifre Geçerli X X X

Yeterli Nakit Var X

Yeterli Bakiye Var X X

Bakiye Bildirme İşlemi X

Para Çekme İşlemi X

Para Yatırma İşlemi X

Para Gönderme İşlemi X


Karar Ağaçları

• Karar verme aşamalarının kök dallanmalı bir yapıyla ortaya çıktığı durumlarda oldukça verimli kullanılan bir yöntem olan karar ağaçları dallanmaların grafiksel olarak gösterildiği şemalardır.

Karar ağaçları kararların, olayların, bir sorunun sonuçları ile ilgili durumların iki boyutlu grafiklerle sunulmasıdır.

Karar ağaçları, sistemle ilgili olası, beklenen, alternatif durumları belirlemek için kullanırlar. Bununla beraber birbiri ardına gelen kararlar dizisinin nasıl ilerlediğini gösteren yolda karar ağaçları ile ifade edilebilir.

Karar ağaçları kök denebilecek bir tek durumla başlar ve her biri bir çıktı (karar) olan birden fazla eylemle son bulur.

23.03.2013

Yansı - 28



Karar Ağacı Örneği

23.03.2013

Yansı - 29




Yansı - 30

Program Tanımlama Dili

Program Tanımlama Dilleri süreç belirtiminde doğal

dillerin programlama dili ile sentezlenmesi şeklinde

ortaya çıkmıştır.

Hangi programlama dilinin kullanılacağından

bağımsız özellikler bulunmalıdır.

DO

Hesap Numarasını Oku

IF (hesap numarası geçerli değil) başlangıca dön işlem türünü iste

IF (para yatırma islemi) { para_yatir(); Başlangıca dön}

IF (yeterli bakiye yok) başlangıca dön

WHILE

6



Yansı - 31

Tasarlanması Gereken Ortak Alt

Sistemler

Yetkilendirme altsistemi

Güvenlik altsistemi

Yedekleme altsistemi

Veri transferi altsistemi

Arşiv altsistemi

Dönüştürme altsistemi



Yansı - 32

Yetkilendirme Alt Sistemi

Özellikle kurumsal uygulamalarda farklı kullanıcıların

kullanabilecekleri ve kullanamayacakları özellikleri

ifade eder.

İşlev bazında yetkilendirme

Ekran bazında yetkilendirme

Ekran alanları bazında yetkilendirme

Oracle veri tabanına erişim konusunda yetkilendirme

yapmaktadır.



Yansı - 33

Güvenlik Alt Sistemi

Yapılan bir işlemde, işlemi yapan kullanıcının

izlerinin saklanması işlemleri.

LOG files (Sistem günlüğü)



Yansı - 34

Yedekleme Alt Sistemi

Her bilgi sisteminin olağandışı durumlara hazırlıklı

olmak amacıyla kullandıkları veri tabanı (sistem)

yedekleme ve yedekten geri alma işlemlerinin olması

gerekmektedir.



Yansı - 35

Veri İletişim Alt Sistemi

Coğrafi olarak dağıtılmış hizmet birimlerinde çalışan

makineler arasında veri akışının sağlanması işlemleri

Çevirim içi veri iletimi (real-time)

Çevirim dışı veri iletimi (disketler, teypler)



Yansı - 36

Arşiv Alt Sistemi

Belirli bir süre sonrasında sık olarak kullanılmayacak

olan bilgilerin ayrılması ve gerektiğinde bu bilgilere

erişimi sağlayan alt sistemlerdir.

Aktif veri tabanı.

7



Yansı - 37

Dönüştürme Alt Sistemi

Geliştirilen bilgi sisteminin uygulamaya alınmadan

önce veri dönüştürme (mevcut sistemdeki verilerin

yeni bilgi sistemine aktarılması) işlemlerine ihtiyaç

vardır.



Yansı - 38

Kullanıcı Arayüz Tasarımı

Kullanıcı ile ilişkisi olmayan arayüzler

Modüller arası arayüz

Sistem ile dış nesneler arası arayüz

Kullanıcı arayüzleri

Kullanım kolaylığı ve öğrenim zamanı esastır

Program=arayüz yaklaşımı vardır



Yansı - 39

Genel Prensipler

Veri giriş formlarının tutarlı olması

Önemli silmelerde teyit alınmalı

Yapılan çoğu işlem geri alınabilmeli

Hataların affedilmesi, yanlış girişte kırılmama

Komut isimlerinin kısa ve basit olması

Menülerin ve diğer etkileşimli araçların standart

yapıda kullanımı



Yansı - 40

Bilgi Gösterimi

Yalnızca içinde bulunulan konu çerçevesi ile ilgili bilgi gösterilmeli

Veri çokluğu ile kullanıcı bunaltılmamalı, grafik ve resimler kullanılmalı

Tutarlı başlık, renkleme ve kısaltma kullanılmalı

Hata mesajları açıklayıcı ve anlaşılır olmalı

Değişik tür bilgiler kendi içinde sınıflandırılmalı

Rakamsal ifadelerde analog görüntü verilmeli (%89 değil)



Yansı - 41

Veri Girişi

Kullanıcı hareketleri en aza indirilmeli

Gösterim ve girdi sahaları birbirinden ayrılmalı (renk)

Kullanıcı uyarlamasına izin verilmeli, kullanıcı bazı özellikleri tanımlayabilmeli

Kullanılan konu ile ilgili gereksiz komutlar deaktifleştirilmeli

Bütün girdiler için yardım kolaylıkları olmalı



Yansı - 42

Kullanıcı Arayüz Prototipi

Tasarım çalışması sonucunda, daha önceden gereksinim çalışması sırasında hazırlanmış olan kullanıcı arayüz prototipi, ekran ve rapor tasarımları biçimine dönüşür. Ekranlar son halini alır, raporlar kesinleşir. Kullanıcıya gösterilerek onay alınır.

Tüm programın tek elden çıktığının ifade edilebilmesi açısından tüm ekranların aynı şablon üzerine oturtulması önerilmektedir. Menü Çubuğu

Araç Çubuğu

Gövde (Değişebilir)

Durum Çubuğu

8



Yansı - 43

Başlangıç Tasarım Gözden Geçirme

Yapılan tasarım çalışmasının bir önceki geliştirme

aşaması olan analiz aşamasında belirlenen

gereksinimleri karşılayıp karşılamadığının

belirlenmesidir.

Sistem gereksinimlerine yardımcı olan kullanıcılar

Sistem analizini yapan çözümleyiciler

Sistemin kullanıcıları

Tasarımcılar

Yönlendirici

Sekreter

Sistemi geliştirecek programcılar

dan oluşan bir grup tarafından yapılır.



Yansı - 44

Ayrıntılı Tasarım Gözden Geçirme

Başlangıç tasarımı gözden geçirme çalışmasının

başarılı bir biçimde tamamlanmasından sonra,

tasarımın teknik uygunluğunu belirlemek için Ayrıntılı

Tasarım Gözden Geçirme çalışması yapılır. Bu

çalışmada;

Çözümleyiciler

Sistem Tasarımcıları

Sistem Geliştiriciler

Sekreter

den oluşan bir ekip kullanılır.



Yansı - 45

Tasarım Kalite Ölçütleri

Bağlaşım (Coupling)

Tasarımı oluşturan modüller arası ilişki ile ilgilidir.

Bağlılık-Yapışıklık (Cohesion)

Modüllerin iç yapısı ile ilgilidir.



Yansı - 46

Bağlaşım

Modüller arası bağlılığın ölçülmesi için kullanılan bir ölçüttür.

Yüksek kaliteli bir tasarımda bağlaşım ölçümü az olmalıdır.

Bağlaşımın düşük olması

Hatanın dalgasal yayılma özelliğinin azaltılması

Modüllerin bakım kolaylığı

Modüller arası ilişkilerde karmaşıklığın azaltılması

nedenleri ile istenmektedir



Yansı - 47

Yalın Veri Bağlaşımı

Herhangi iki modül arası iletişim yalın veriler

(tamsayı, karakter, boolean, vs) aracılığı ile

gerçekleştiriliyorsa bu iki modül yalın veri

bağlaşımlıdır şeklinde tanımlanır.



Yansı - 48

Karmaşık Veri Bağlaşımı

Herhangi iki modül arasındaki iletişimde

kullanılan parametrelerin karmaşık veri yapısı

(kayıt, dizi, nesne, vs) olması durumunda

modüller karmaşık veri paylaşımlı olarak

tanımlanır.

9



Yansı - 49

Denetim Bağlaşımı

İki Modül arasında iletişim parametresi olarak

denetim verisi kullanılıyorsa bu iki modül

denetim bağlaşımlı olarak tanımlanır.



Yansı - 50

Ortak Veri Bağlaşımı

Eğer iki modül ortak bir alanda tanımlanmış verilere

ulaşabiliyorsa bu iki modül ortak veri bağlaşımlı olarak

tanımlanır.

Verilerin ortak veri bağlaşımlı olmaları şu nedenlerden

dolayı fazla istenmez;

Ortak veri alanını izlemek zordur.

Ortak veri kullanan modüllerde yapılan değişiklikler diğer modülleri etkiler.

Ortak veri üzerinde yapılacak değişikliklerde bu veriyi kullanacak bütün modüller göz önüne alınmalıdır.



Yansı - 51

İçerik Bağlaşımı

Modüllerin iç içe tasarlanması sonucu, bir

modülün başka bir modül içerisinde

tanımlanmış veri alanına erişebilmesi

olanaklaşır ve bu durum içerik bağlaşımına

yol açar.



Yansı - 52

Bağlılık-Yapışıklık

Bir modülün kendi içindeki işlemler arasındaki ilişkilere ilişkin bir ölçüttür. Modül gücü olarak ta tanımlanır.

Tasarımda bağlılık-yapışıklık özelliğinin yüksek olması tercih edilir.

Yapışıklık ile Bağlaşım ters orantılıdır.



Yansı - 53

İşlevsel Yapışıklık

İşlevsel Yapışık bir modül, tek bir iş problemine ilişkin

sorunu çözen modül olarak tanımlanır.

Maas_Hesapla, Alan_Hesapla gibi



Yansı - 54

Sırasal Yapışıklık

Bir modülün içindeki işlemler incelendiğinde,

bir işlemin çıktısı, diğer bir işlemin girdisi

olarak kullanılıyorsa bu modül sırasal yapışık

bir modül olarak adlandırılır.

Ham_Veri_Kaydını_Düzelt

Duzeltilmis_Ham_Veri_Kaydini_Dogrula

Dogrulanmis_Kaydi_Gonder

10



Yansı - 55

İletişimsel Yapışıklık

Bir modülün içindeki farklı işlemler aynı girdi

ya da çıktıyı kullanıyorlarsa bu modül

iletişimsel yapışık bir modül olarak

adlandırılır.

Sicil_No_yu_Al

Adres_Bilgisini_Bul

Telefon_Bilgisini_Bul

Maas_Bilgisini_Bul



Yansı - 56

Yordamsal Yapışıklık

Yordamsal Yapışık modüldeki işlemler arasında denetim ilişkisi bulunmaktadır.

İşlemlerin birbirleri ile veri ilişkisi yoktur, ancak işlem sırası önemlidir.

Ekran_Goruntusunu_Yaz

Giris_Kaydini_Oku



Yansı - 57

Zamansal Yapışıklık

Bir modül içindeki işlemlerin belirli bir zamanda

uygulanması gerekiyor ve bu işlemlerin kendi

aralarında herhangi bir ilişkisi yok, yani

işlemlerin sırası önemli değil ise, zamansal

yapışıklık vardır.

Alarm_Zilini_Ac

Kapiyi_Ac

Kamerayi_Calistir



Yansı - 58

Mantıksal Yapışıklık

Mantıksal olarak aynı türdeki işlemlerin bir

araya toplandığı modüller mantıksal yapışık

olarak adlandırılır.

Dizilere değer atama işlemleri



Yansı - 59

Gelişigüzel Yapışıklık

İşlemler arasında herhangi bir ilişki bulunmaz.

Ara_Kayit_Oku

B_dizisine_baslangic_deger_ata

Stok_kutugu_oku

Hata_iletisi_yaz

Unified ModelLing

Language (UML)

Bütünleşİk Modelleme

DİLİ

23.03.2013 60 Yazılım Mühendisliği

11


UML NEDİR?

UML, yazılımın tasarımı ve planlanması için kullanılan

standart bir dildir.

Bir program ya da yazılım geliştirme dili değildir.

Modelleme kanıtlanmış ve kabul edilmiş bir mühendislik

tekniğidir.

Model gerçeğin basitleştirilmiş halidir. Model sayesinde

anlaşılması güç yazılımları basit bir dille ifade edebiliriz. Bu

da yazılımın anlaşılmasını kolaylaştırır, sistem

gereksinimlerini ve davranışlarını daha iyi anlamamızı ve

hatalarımızı kolaylıkla görüp en düşük seviyeye

indirgememizi sağlar.

23.03.2013

Yansı - 61



UML NEDİR?

UML yazılım mühendisliğinde nesneye yönelik sistemleri modellemede kullanılan açık standart olmuş bir görsel modelleme dilidir.

Yazılım geliştirmenin çözümlemeden bakıma kadar tüm aşamalarında ekipler ve bireyler arasındaki iletişimin düzgün yürütülmesi için kullanılmaktadır.

Yazılımın yaşam döngüsü içinde farklı görev gruplarının projeye ve sisteme farklı bakış açıları vardır. Bundan dolayı UML çeşitli bakış açılarını ifade eden diyagramlar içermektedir.

Çok zengin bir dil olmasından dolayı, Yazılım Mühendisliği’nin bir çok yönden ihtiyaçlarını karşılamaktadır.

23.03.2013

Yansı - 62



UML’NİN TARİHİ

23.03.2013

Yansı - 63



UML’YE NEDEN GEREK VAR?

Hataların kolaylıkla fark edilip en düşük seviyeye

indirgenmesi.( Risk, zaman, maliyet)

Yazılım üretiminde başarı oranının düşük olması.

Yazılımda paylaşım önemlidir. Tüm ekibin aynı dili

konuşabilmesi gerekmektedir.

Sistemin tamamını basit bir dille ve görsellikle görebilmek

ve tasarlayabilmek gerekli.

Modellenmiş ve dokümante edilmiş bir yazılımın

tanıtımının kolay olması.

Yazılım kalitesini arttırma.

23.03.2013

Yansı - 64



UML’NİN AVANTAJLARI-1

Kodlama kolaylığı sağlar.

Kullanılan tekrar kod sayısı ayırt edilebilir bu sayede

verim sağlanır.

Mantıksal hataların minimum seviyeye düşürülmesini

sağlar. Bütün sistem tasarlandığı için oluşabilecek

hataların düzeltilmesi de daha kolaydır.

Geliştirme maliyetinin düşmesini sağlar.

23.03.2013

Yansı - 65



UML’NİN AVANTAJLARI-2

UML diyagramları ile yazılım tamamını görebileceğimiz için

verimli bellek kullanımı sağlanabilir.

Karmaşık sistemlerde değişiklik yapmayı kolaylaştırır.

UML ile dokümanlaştırılmış kodları düzenlemek daha az

zaman alacaktır.

UML diyagramlarını kullanan yazılımcılar aynı dili

konuşacaklarından kolay iletişim sağlanır. Ayrıca müşteriler

ve teknik sorumlular diyagramlar üzerinden kolaylıkla iletişim

kurabilirler.

23.03.2013

Yansı - 66


12


UML Temel Konvensiyonlar

Bütün UML diyagramları düğüm ve kenarlardan oluşan graflardan oluşur Nodes are entities and drawn as rectangles or ovals

Dikdörtgenler sınıfları veya durumları gösterir

Oval şekiller fonksiyonları gösterir

• Sınıfların isimlerinde alt çizgi yoktur

• SimpleWatch

• Firefighter

• Durumların alt çizgisi vardır

• myWatch:SimpleWatch

• Joe:Firefighter

• İki düğüm arasındaki kenar onların arasındaki ilişkiyi belirtir


UML DİYAGRAMLARI

Grafiksel bir dil olan UML, modelleme için değişik diyagramlar kullanır. Diyagramlar, bir sistem modelini kısmen tarif eden grafiklerdir.

UML 2.0, 3 bölümde incelenen 13 farklı diyagram içerir.

Yapısal diyagramlarda modellenen sistemde nelerin var olması gerektiği vurgulanır.

Davranış diyagramlarında modellenen sistemde nelerin meydana gelmesi gerektiğini belirtir.

Davranış diyagramlarının bir alt kümesi olan Etkileşim diyagramlarında ise modellenen sistemdeki elemanlar arasındaki veri ve komut akışı gösterilir.

23.03.2013

Yansı - 68



DAVRANIŞ DİYAGRAMLARI

Davranış Diyagramları:

Kullanım Senaryosu (Use-Case) diyagramı

Durum (Statechart) diyagramı

Faaliyet (Activity) diyagramı

23.03.2013

Yansı - 69



Durum Diyagramları

State

Initial state

Final state

Transition

Event

Tek bir objenin dinamik davranışını tarif eder

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed Increment

Minutes

Increment

Hours

Blink

Hours

Blink

Seconds

Blink

Minutes

Increment

Seconds

Stop

Blinking


YAPISAL DİYAGRAMLAR

Yapısal Diyagramlar

Sınıf (Class) diyagramı

Nesne (Object) diyagramı

Bileşen (Component) diyagramı

Paket (Package) diyagramı

Dağılım (Deployment) diyagramı

Birleşik Yapı (Composite Structure) diyagramı

23.03.2013

Yansı - 71



Sınıf Diyagramları

1 2

push()

release()

1

1

blinkIdx

blinkSeconds()

blinkMinutes()

blinkHours()

stopBlinking()

referesh()

LCDDisplay Battery

Load

1

2

1

Time

Now

1

Watch

Operations

state PushButton

Attribute

Sınıf diyagramları sisteminin yapısını temsil eder

Class

Association

Multiplicity

13


ETKİLEŞİM DİYAGRAMLARI

Etkileşim Diyagramları

Sıralama (Sequence) diyagramı

İletişim (Communication) diyagramı

Etkileşime Bakış (Interaction Overview) diyagramı

Zaman Akış (Timing) diyagramı

23.03.2013

Yansı - 73



Message

Sıralama Diyagramları

:Time :Watch :WatchUser

Object

Activation

Sistemin objeler arasındaki dinamik davranışını mesaj olarak tarif eder

Actor

pressButton1()

Lifeline

blinkHours()

pressButton2() incrementMinutes()

:LCDDisplay

pressButton1and2()

commitNewTime()

stopBlinking()

refresh()

pressButton1() blinkMinutes()


USE CASE DİYAGRAMLARI

Analiz aşamasında Use Case Diyagramları kullanılır.

Tasarım aşamasında ise modellerin 3 tipi ortaya konulur.

1. Sınıf Diyagramları

2. Durum Diyagramları

3. Etkileşim Diyagramları

23.03.2013

Yansı - 75




Sistemin çok basit bir şekilde modellenmesini ve

işlerin detayının (senaryonun) metin olarak

anlatılmasını içerir.

Aktörden gelen bazı isteklere karşı sistemin yaptığı

aktiviteleri gösterir.

Gelişmenin erken safhalarında yapılandırılır.

Amaç

Sistemin içeriğini belirtmek.

Sistemin gereksinimlerini elde etmek.

Sistemin mimarisini geçerli kılmak.

Analistler ve uzmanlar tarafından geliştirilir.

23.03.2013

Yansı - 76




23.03.2013

Yansı - 77




BİLEŞENLERİ

Aktör

• Sistemin kullanıcılarıdır.

• Aktörler genelde belirli bir rol ifade ederler.

• Diğer aktörlerle bağlantılı olabilirler bu bağlantı bir ok ile gösterilir.

• Sistem sınırları dışında gösterilir.

23.03.2013

Yansı - 78


14


USE CASE DİYAGRAMLARI BİLEŞENLERİ

Use case

• Sistemin destekleyeceği işler.

• Sistem fonksiyonelliğinin büyük bir parçasını gösterir.

• Diğer bir use case ile genişletilebilir.

• Diğer bir use case içerebilir.

• Sistem sınırları içinde gösterilir.

Use case

23.03.2013

Yansı - 79




Sistem sınırı

• İçerisinde sistemin ismi yazılıdır.

• Sistemin kapsamını gösterir.

Bağıntı ilişkisi

• Aktör ve use case ler arasındaki

bağıntıyı gösteren çizgidir.

Sistem

* *

23.03.2013

Yansı - 80




Inclusion (içerme) ilişkisi

Bu metotla bir use case içindeki adımlardan birini başka bir use

case içinde kullanabiliriz.

Inclusion yöntemini kullanmak için <<include>> şeklindeki bir

ifade kullanılır.

Kullanmak istediğimiz use case 'ler arasına çektiğimiz noktalı

çizginin üzerine <<include>> yazısını yazarız.

<<include>>

23.03.2013

Yansı - 81




BİLEŞENLERİ Extension (eklenti) ilişkisi

Bu metodla varolan bir Use Case 'e yeni yeni adımlar

ekleyerek yeni use case 'ler yaratılır.

Inclusion'da olduğu gibi extension 'ları göstermek için

yine use case 'ler arasına noktalı çizgiler konur ve

üzerine <<extend>> ibaresi yazılır.

<<extend>>

23.03.2013

Yansı - 82




Genelleme ilişkisi:

• Özelleşmiş use case ile daha genel use case

arasındaki ilişkidir.

• Özelleşmiş use case den temel use case’e doğru bir

ok ile gösterilir.

23.03.2013

Yansı - 83




Yansı - 84

15


Use Case Diyagramı

23.03.2013

Yansı - 85



23.03.2013

Yansı - 86



Include & Extend

23.03.2013

Yansı - 87



23.03.2013

Yansı - 88



23.03.2013

Yansı - 89



Genelleme

23.03.2013

Yansı - 91


16


serhatkilicarslan.com( Slides için teşekkürler)

M. Erhan Saridogan, Yazılım Mühendisliği

Martin Fowler

UML Distilled: A Brief Guide to the Standard Object

Modeling Language, 3rd ed., Addison-Wesley, 2003

Grady Booch,James Rumbaugh,Ivar Jacobson

The Unified Modeling Language User Guide, Addison

Wesley, 2nd edition, 2005

Open Source UML tools

http://java-source.net/open-source/uml-modeling

Diğer UML slides


Yansı - 92

Documents

Yazılım Mühendisliği Hafta - 6 Tasarım - EEMB DERSLER · Yazılım Mühendisliği Bölüm –6 Tasarım 23.03.2013 Yazılım Mühendisliği Yansı - 9 Veri tasarımında dikkat