Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

UML-düzenleme

Okul sunum
by

pelin karacan

on 10 December 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of UML-düzenleme

*UML Nedir? *UML'in Faydalar UML(Unified Modeling Language) Yazılım teknolojisi gelitikçe yazılan programların karmasıklığı ve zorluğu giderek artmaktadır. Yazacağımız programlar çok karmaşık olacağı için kod organizasyonu yapmamız zor olacaktır. Heleki birden fazla programcının çalışacağı projelerde bu neredeyse imkansız hale gelmiştir. Bu yüzden standart bir modelleme ve analiz diline ihtiyaç duyarız.UML daha çok nesneye dayalı programlama dilleri için uygundur. Problemlerimizi parçalara ayırabiliyorsak ve parçalar arasında belirli iliskiler sağlayabiliyorsak UML kullanmak işimizi oldukça kolaylaştırmaktadır. ÖRNEĞİN;Müsteri ATM makinesinden para çeker,banka memuru ATM makinasına para yükler.Ama banka memuru ile müşteri arasında doğrudan bir ilişki yoktur.Bu tür ilişkiler UML de çeşitli diagramlarla gösterilir.

*UML'in Tarihi;

Grady Booch,James Rumbaugh ve Ivar Jacobson tarafından gelitirilmiştir.UML 'den önce her birinin kendi geliştirdiği metodları vardı.

Grady Booch Booch Metodu

James Rumbaugh OMT(ObjectModelingTechnique)

Ivar Jacobson OOSE(ObjectOrientedSoftwareEngineering)

Rational firması tarafından bu görsel modelleme dilleri birletirilerek 1995'te UML gelistirilmis ve 1997 yılında OBJECT MANAGEMENT GROUP (OMG) tarafından bir standart olarak kabul edilmistir. Herseyden önce UML bir Programlama dili değildir.Bir diyagram çizme ve ilişkisel modelleme dilidir. ANALİZ DİZAYN KODLAMA UYGULAMA 1-Öncelikle programımızın kodlamaya başlamadan önce genis bir analiz ve tasarımı yapılmışs olacağından kodlama islemi daha kolay olur.

2- Programımızda beklenmedik bir takım mantıksal hataları(bug) minimuma indirgemiş oluruz.

3-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.

4-UML diagramları programımızın tamamını kapsayacağı için bellek kullanımını daha etkili hale getirebiliriz.

5-Programımızın kararlılığı artacaktır. UML ile dokümanlandırılmış kodları düzenlemek daha az zaman alacaktır.

6-Ortak çalışılan projelerde programcıların iletişimi daha kolay hale gelir. Çünkü UML ile programımızı parçalara ayırdık ve parçalar arasında bir ilişki kurduk. UML ÇEŞİTLERİ CLASS DİAGRAM OBJECT DİAGRAM STATE DİAGRAM SEQUENCE DIAGRAM ACTİVİTY DİAGRAM USE CASE DİAGRAM COLLABORATION DIAGRAM COMPONENT DIAGRAM DEPLOYMENT DIAGRAM 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 gruplar olutururuz. Bunlara "Class"(sınıf) denir. Bir nesne(object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek nesneler kullanılır. Gerçek nesnelerin herhangi bir zaman içindeki durumunu gös-teren diyagramlardır.Mesela, Berk nesnesi insan sınıfının gerçek bir örneği olsun.Berk'in doğması, büyümesi ve ölmesi State Diagram 'larıyla gösterilir Class ve Object diyagramları statik bilgiyi modeller.Bu tür zamanla değişen durumları belirtmek için sequence diyagramları kullanılır. Bir nesnenin durumu kullanıcı tarafından ya da nesnenin kendi içsel işlevleri tarafından değişebilir.Bu değişim sırası activity diagramları ile gösterilir. Programımızın davranışının bir kullanıcı gözüyle incelenmesi Use Case diyagramlarıyla yapılır. Gerçek dünyada insanların kullanacağı bir sistemde bu diyagramlar büyük önem taşırlar. Bir sistemin amacının yerine gelmesi için sistemin bütün parçaları işlerini yerine getirmelidir. 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 bu diagram kullanılır. Özellikle birden çok geliştiricinin yürüttüğü projelerde sistemi öyle mo-dellememiz gerekir ki her geliştirici ötekinden bağımsız olarak çalışabilsin.Bu tür modellemelerde Component diagram kullanılır. Bu tür diyagramlarla sistemin fiziksel incelenmesi yapılır. Mesela bilgisayarlar arasındaki bağlantılar, programın kurulacağı makinalar ve sistemimizdeki bütün aletler Deployment Diyagramında gösterilir. *UML Diyagramlarına 4+1 Bakış (View) Bir yazılım sistemi oluşturulurken sadece tek boyutta analiz ve modelleme yapılmaz. Bu amaçla; yazılım geliştirme sürecinin farklı aşamalarında farklı UML diyagramlarını kullanmak gerekmektedir. 4+1 bakış, bu diyagramları sınıflandırmak ve yazılım yaşam çevrimindeki kullanım yerlerini ortaya koymak için kullanılan bir kavramdır. Bu bakışlar; 1-) Kullanıcı Bakışı (User View): Müşteri gereksinimlerini ortaya koymak ve müşteriye, sistemi tanıtmak amacı ile kullanılan bakış açısıdır.Bu amaçla;kullanım senaryosu" (use case) diyagramları kullanılmaktadır. 2-) Yapısal Bakış (Structural View): Sistemin nelerden meydana geldiğini gösteren bakış açısıdır.Bu amaçla;"sınıf" (class) diyagramları ve "nesne" (object) diyagramları kullanılmaktadır. 3-) Davranış Bakışı (Behavioral View): Sistemin dinamik yapısını ortaya koyan bakış açısıdır. Bazı kaynaklarda; süreç (process) bakışı olarak da açıklanmaktadır. Bu amaçla;"sıralama" (sequence), "işbirliği" (collaboration), "durum" (statechart), "aktivite" (activity) diyagramları kullanılmaktadır. 4-) Gerçekleme Bakışı (Implementation View): Sistemin alt modüllerini ortaya koyan bakış açısıdır. Bu amaçla;"bileşen" (component) diyagramları kullanılmaktadır. 5-) Ortam Bakışı (Environment View): Donanımın , fiziksel mimarisinin ortaya konduğu bakış açısıdır.Bu amaçla;"dağıtım" (deployment) diyagramları kullanılmaktadır. *Class Diagramlarıi UML ile sınıf diyagramları oluşturmak nesne temelli programlamanın getirdiği bir gerekliliktir.UML ile oluşturulan "Class Diagramları", aralarında bizim belirlediğimiz ilişkileri içeren sınıflar topluluğudur. Class'lara isim verirken, her kelimenin baş harfinin büyük olması diyagramlarımızın başkaları tarafından incelenmesi sırasında kolaylık sağlayacaktır. UML' de bir class dikdörtgen ile gösterilir. Dikdörtgenin en üstünde sınıfın adı vardır. Bir classın çeşitli özellikleri olabilir.Mesela, bir insan nesnesi olan 'berk' nesnesinin yaşı bir özellik(attribute) bildirir. Bir classın özellikleri SınıfAdı'nın hemen altına yazılır. Bir Classın hiç özelliği olmayabileceği gibi birden fazla özelliği de olabilir. Bir özelliğin değerini sonradan değiştirebileceğimiz gibi yandaki "yaş" özelliği gibi varsayılan bir değer de verebiliriz. Bu değerler number,string, boolean,float,double veya kullanıcı tanımlı bir tür olabilir. Classların bir diğer önemli elemanı da işlevlerdir (operations). İşlevler bir Classta iş yapabilen elemanlardır.Bu iş başka bir classa yönelik olabileceği gibi kendi içindeki bir iş de olabilir. İşlevler özelliklerden farklı olarak birtakım bilgilere ihtiyaç duyabilir, veya birtakım bilgileri dışarıya verebilir, ya da bunların hiçbirini yapmaz. Yandaki işlev1, birtakım işler yapar bunun için dışardan bir bilgiye ihtiyaç duymaz ve dışarıya bir bilgi vermez, işlev2, işini yapabilmek için birtakım bilgilere ihtiyaç duyar.Mesela, işlev2, eğer bir toplama işlemi yapıyorsa toplanacak elemanları ister. işlev3 ise iş yaptıktan sonra işinin sonucunu dış dünyaya verir. *USE CASE DİAGRAMLAR Use Case diagramalar elimizdeki sorunu analiz ederken her seyin açiga çikmasi için kullanilir. Use Case diagram dışarıdan baktığımızda aktörler ile fonksiyonlar arasindaki olayların bağını kurmamızı sağlar. Aktörler bize entitilerle sistemler arasındakı ilişkileri tanımlarlar. Use Case diagramlar sistemin kabaca ne yaptığı ile ilgilenir.Kesinlikle neden ve nasıl yapıldığını incelemez. *Use Case Diagram temelleri Use Case Diagramlar yapılırken Assumption (Varsayım) mantığı kullanılır. Bazı şeylerin yapıldığı varsayılır. Örneğin bir gise yetkilisi sistem üzerinden bilet satacak ise onun sisteme giriş yaptığı varsayılır. Bunu her seferde tekrar tekrar belirtmeye gerek yoktur. Use Case Diagramlarda Precondition (ön sart) gereklidir. Örneğin hesaptan para çekilecek ise hesapta para olmalıdır. Use Case Diagramlarda Progress (ilerleme) esnasında açik açik madde madde süreç anlatılmalıdır. Eger yetmez ise Activity Diagramlar ile süreç desteklenmelidir. Use Case Diagramlarda Post Condition (Son şart) işlemi vardır. Örnegin Atm’den para çekiyorsunuz ama kartı almadan parayı alamazsınız. 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. Her ne kadar bazı sistemlerde bir olay ya da senaryo kullanıcı tarafından değil de donanım veya belirli bir zaman geçmesi sonucu başlatılsa da, sistemi tasarlamamız için Use Case 'lerden faydalanamayacağımız anlamına gelmez. ÖRNEK Bir saatimiz olsun ve saatimizin üç tane fonksiyonu olsun.Saatimiz saati göstersin, saati ayarlayabilelim ve saatimizin pilini degiştirebilirim. Burada iki adet aktör var biri saati kullanan kişi digeri ise saatin teknik servisi... ÖRNEK Elimizde bir ürünümüz var ve bu ürünümü-zün silinmesi fonksiyonumuz var biz ürünü sildigimizde o ürün pasif konuma geçiyor. Diger bir fonksiyonumuz ise pasif ürünün silinmesi işlemidir. Bizim bu ürünleri silme-miz için bir ürün kontrolü fonksiyonumuz vardır. Diger bir fonksiyonumuz ise ürün ödeme fonksiyonudur. Ödeme yapilirken ise elimizdeki kartin bilgilerinin kontrolü ge-rekmektedir. Diger bir fonksiyonumuz ise kart bilgileri kontrol fonksiyonudur. *Use Caseler Arasındaki ilişkiler Use case 'ler tekrar kullanılabilen birimlerdir. Tekrar kullanmanın iki yöntemi vardır.Bunlar : inclusion ve extension 'dır. Bu iki metodun dışında use case 'ler arasındaki ilişkiyi gösteren iki kavram daha vardır. Bunlar ise :Generalization(Genelleme) ve Grouping(gruplama) 'dır. Inclusion(içerme) Bu metodla bir use case içindeki adımlardan birini başka bir use case içinde kullanabiliriz. Inclusion yöntemini kullanmak için <> şeklindeki bir ifade kullanılır. Bu ifade daha önce gördüğümüz sınıf diyagramlarındaki sınıfları birbirine bağlayan noktalı çizgilerin üzerine yazılır. Kullanmak istediğimiz use case 'ler arasına çektiğimiz noktalı çizginin üzerine <> yazısını yazarız. Extension(eklenti) Bu metodla varolan bir Use Case 'e yeni yeni adımlar ekleyerek yani use case 'ler yaratlır. Inclusion'da olduğu gibi extension 'ları göstermek için yine use case 'ler arasına noktalı çizgiler konur ve üzerine <> ibaresi yazılır. Generalization(genelleme) Bildiğiniz gibi sınıflar için türetme kavramı vardır. Türetme ile oluşturulan sınıf ana sınıfın tüm özelliklerini alır ve istenirse yeni sınıfa yeni özellikler eklenir. Use Case 'ler arasındaki bu ilişki de sınıflarda türetme(inheritance) kavramına benzemektedir. Gösterim biçimi sınıf diyagramlarındaki türetmenin gösteriliş şekliyle aynıdır. Yani use case 'ler arasında düz bir çizgi çizilir ve çizginin taban(base) sınıfı gösteren ucuna içi boş bir üçgen çizilir.Şimdi bir siteye ait kullanıcıların genellemesinin nasıl yapıldığını görelim. Bir sitedeki online kullanıcılar ziyaretçilerden ve üyelerden oluşur, ayrıca sitenin üye kullanıcıları ve ziyaretçiler için sunduğu hizmetler farklı olabileceği için aktörler arasında genelleme yapılmıştır. Grouping(gruplama) Gruplama metodu tamamen fiziksel olarak bazı use case 'leri bir arada toplamak için kullanılır. Gruplama tekniği genellikle birkaç alt sistemden oluşan büyük sistemlerde kullanılır.Örneğin siteye giren bir kullanıcının neler yapabileceğini inceleyelim. Dinlediğiniz için teşekkür ederim...
Sorularınızı alabilirim:)
Full transcript