Sunuyu indir
Sunum yükleniyor. Lütfen bekleyiniz
1
UML Unified Modeling Language
Yazılım Mühendisliği
2
İçindekiler… UML ve modelleme nedir? UML’ye neden ihtiyaç var?
UML’nin yararları, Diyagramlar, Class Diyagramları, Class Diyagramları arasındaki ilişkiler, Use Case Diyagramları, Örnek Yazılım Mühendisliği
3
MODELLEME İLE GÖRSEL MODELLEME
İşte bu seviyede karşımıza “Görsel Modelleme (Visual Modelling)” tekniklerindeki değişimler ve gelişimler çıkmıştır. Görsel Modellemeler, var olan problemlerin gerçek dünya etrafında şekillenmiş halleridir. Modeller ; 1) Problemin kavranmasında, 2) Proje ile ilgili herhangi bir iletişimde (müşteri, analizci, tasarımcı, programcı...), 3) Doküman hazırlanmasında, 4) Tasarım ve problem çözümünde, küçümsenmeyecek kolaylıklar sağlar. Yazılımın oluşturulması ve geliştirilmesi için büyük önem taşırlar. Modeller, karmaşık sistem ya da yapıların gereksiz ayrıntılarından, yani bir nevi filtreleme yaparak, kurtarılmasını sağlayıp daha kolay anlaşılmasını sağlarlar. Buna kısaca liratürde “Soyutlama (Abstraction)” denilmektedir. Bir mühendis herhangi bir karmaşık problem karşısında sistemi ypılandırmak için öncesinde ilgili sistemin değişik açılarını soyutlayan ve karşılayan modeller oluşturmalı ve adım adım bu modellere detayları ekleyerek istenen son şekle ulaşmalıdır. Yazılım Mühendisliği
4
Neden UML? Bir sistemin analizi yapılırken belirli bir programlama dilinden yada geliştirme sürecinden bağımsız olmayı sağlar. Mimar-inş.müh ilişkisinde olduğu gibi tasarımcı-programcı arasında standart bir olarak köprü görevi görür. Analiz ve tasarımda ortaya çıkan eksikleri gidermek daha sonraki aşamalarda farkedilecek olanları çözmeye oranla daha az masraf ve zaman gerektirir. Yazılım Mühendisliği
5
UML ve Modelleme UML,sürekli gelişen yazılım teknolojisi ve artan karmaşıklık karşısında endüstriyel olarak geliştirilmiş ve standartlaşmış bir evrensel modelleme biçimi ve dilidir. UML kesinlikle bir programlama dili değildir! Yazılım Mühendisliği
6
UML’ ye neden ihtiyaç var?
Yazılım üretiminde başarı %17 seviyelerinde… Bugün büyük ölçekli yazılımlar deneme yanılma yöntemiyle yazılacak boyutu çoktan aşmış durumda İhtiyaçların,kaynakların,proje planının paylaşılması gerekli Görsel ve metinsel notasyonlar kullanarak sistemi tüm boyutlarıyla modelleyebileceğimiz ve tasarımını gerçekleştirebileceğimiz bir araç gerekli... Modellenmiş ve dokümante edilmiş bir yazılımı her yerde ve ortamda tanıtabilir ve kolayca anlatabiliriz. Yazılım Mühendisliği
7
UML’ nin yararları Gereksinim Analizi Modelleme (UML) Kod Geliştirme
Bellek kullanımında verimli olur Senaryolar yardımıyla programın kararlılığı artar Takım çalışması için ideal bir yardımcıdır Analizi ve tasarımı yapılmış olduğu için daha kolay kodlama yapılabilir. Hatalar en aza indirilir Tekrar kullanılabilir kod parçaları artabilir Gereksinim Analizi Modelleme (UML) Kod Geliştirme Uygulama Yazılım Mühendisliği
8
UML Diagramları Davranış diagramları. Bir sistem yada iş akışının davranış özelliklerini anlatan çizimlerdir. activity, state machine, use case diagramları Etkileşim diagramları. Davranış diagramlarının alt kümesidir. Nesneler arası etkileşimi betimlerler. communication, interaction overview, sequence, timing diagramları Yapı diagramları. Statik diagramlardır. Bir yapının elemanları zamandan bağımsız olarak tasarlanır. class, composite structure, component, deployment, object, package diagramları. Yazılım Mühendisliği
9
UML Modellemede Diyagramlar
Bir modelleme metodolojisi olan UML temel olarak 9 diyagram tipine sahiptir. Class Diyagramları (Sınıf yapılarını gösterir) Object Diyagramları (Gerçekleşmiş Nesnelerin bilgileri) State Diyagramları (Nesnelerin o anki durumları) Sequence Diyagramları (Değişken durumların ifadesi) Activity Diyagramları (Nesnelerin faaliyetleri) Use Case Diyagramları (Gerçek senaryolar üzerinde test) Collaboration ”” (Parçaların bütünü oluşturması) Component ”” (Bileşenlerin diyagramı) Deployment ”” (Sistemin çalışma platformundaki hallerini gösteren diyagramlar) Yazılım Mühendisliği
10
Class Diyagramları UML’de sınıflar OOP mantığından yola çıkılarak düşünülmüştür Sınıfların bir adı,özellikleri (attributes) ve işlevleri(functions) vardır. Bunlara ek olarak “notes” (sınıf hakkında ekstra bilgiler) ve “Constraints” adlı sınıfla ilgili çeşitli özel koşullara ait bilgilerde bulunabilir. Yazılım Mühendisliği
11
Class’lar arasındaki ilişkiler
İnsan sınıfından Ali nesnesi ve Kitap sınıfından ‘Uml Kitabı’ nesnesi ve aralarındaki ‘okuma’ ilişkisi Burada müşteri ile kitapçı sınıfı arasında "satın alma“ ilişkisi var.Fakat müşteri satın alırken ücret ödemek zorundadır.Bu ilişkiyi göstermek için ücret sınıfı ilişki ile kesikli çizgi ile birleştirilir. Burada 1 komutan 100 Er'e komut(emir) verebilir anlamı çıkmaktadır Yazılım Mühendisliği
12
Use Case Diyagramları Sınıfların ve sistemin zamanla değişimini gösteren diyagramlara ‘USE CASE’ diyagramları denmektedir.Bu diyagramlar Actors ve Use Case 'ler arasındaki ilişkilerden oluşmaktadır Use Case modelini oluşturan diğer önemli bir yapı ise senaryolardır. Senaryolar kullanıcı tarafından başlatılan çeşitli olaylar dizisidir. Bir Use Case modeli Use Case diyagramları ve Use case açıklamaları dediğimiz senaryolardan oluşmaktadır. Aktör yani kullanıcı Use Case modelinde bir Use Case 'i başlatır ve sonuç olarak bir değeri başka bir kullanıcıya verir. Use Case 'ler elips şeklinde gösterilir. Kullanıcıların altında kullanıcıların adı bulunur. Kullanıcı ve Use Case arasındaki ilişkiyi belirtmek için ise düz bir çizgi çizilir. ! Use Case’ler sistemin kesinlikle nasıl ve neden yapıldığını incelemez. Yazılım Mühendisliği
13
Neden Use Case diagramları kullanılır?
Sistemin ne yaptığının yüksek-düzey görüntüsünü sağlar. Müşteri(client) ile iletişim kurmak ve isteklerinin tam olarak belirlenmesi için açık, anlaşılır bir modeldir. Test durumları oluşturmada senaryolardan faydalanılır. Her bir senaryo aynı zamanda bir test durum dizisidir. Yazılım Mühendisliği
14
Temel Use Case Diagramı Bileşenleri
Aktörler Use case’ler İlişkiler Sistem sınırı/sınırları Yazılım Mühendisliği
15
Aktörler (actors) Aktörler sistem içinde olayları başlatan kişi yada nesnelerdir. Bir aktör insan, donanım cihazları, çevre birim yada başka bir sistem olabilir. Yazılım Mühendisliği
16
İlişkiler Bir aktor ile use case arasındaki ilişki düz bir çizgi ile, use caseler arasındaki ilişki ise "uses“ yada "extends" etiketli oklarla olur. "uses" ilişkisi ana use case in bir alt kümesidir, “extends" ilişkisi ise ana use case den farklı özellikleri (alternatif seçenekleri) olan bir use case ile ilişkilendirilir. Yazılım Mühendisliği
17
Sistem sınırları Sistem sınırı genellikle tüm sistemi içine alan kısımdır. Fakat büyük ve karmaşık sistemlerde her bir modül bir sistem sınırı oluşturabilir. Örneğin bir işletmenin ERP sistemi için personel, muhasebe gibi kısımlar kendi use caseleri ile ayrı bir sistem sınırı oluştururlar. Sistemin bütünü bu modüllerin bir araya gelmesiyle oluşur. Yazılım Mühendisliği
18
Use Case Diagram oluşturma
Düzenli bir use case diagramı oluşturmak için önce sistem içindeki aktivite dizisini betimleyen bir paragraf yada adımları gösteren bir algoritma yazılması yararlıdır. Aktörler belirlenir. Hata raporu hazırla Test uzmanı yeni bir hata bulundu raporu hazırlar. Test uzmanı hatanın kaynağını belirler, problemin tanımını yapar, kime gideceğini belirler. Sistem hatayı kaydeder ve görevli kişiye yeni bir hata bulunduğunu bildirir. Yazılım Mühendisliği
19
Örnek İnternet ortamından giriş bir kullanıcının neler yapabileceğini use case diyagramlarıyla ifade edelim. Siteye gelen bir kullanıcı kayıtsız şartsız makale başlıklarını görebilmektedir. Online olan kullanıcı siteyi tavsiye edebilir, siteye üye olabilir, kitapları inceleyebilir. Ancak makale okuması ve kaynak kod indirebilmesi için siteye üye girişi yapmalıdır. Makale okuması ve kaynak kod indirebilmesi için gereken şart siteye üye olmaktır. Siteye bağlanan bir kullanıcının site üzerindeki hareketlerini belirtir diyagram bu şekilde oluşturulabilir. Yazılım Mühendisliği
20
Kaynaklar www.Csharpnedir.com www.Aspnedir.com www.uml.org
Yazılım Mühendisliği
Benzer bir sunumlar
© 2024 SlidePlayer.biz.tr Inc.
All rights reserved.