Temel uml diyagramları. UML'nin temel diyagramları. Durum haritasındaki dahili faaliyetler

& nbsp & nbsp & nbsp & nbsp Birleşik Modelleme Dili (UML), yazılım sistemlerinin yanı sıra iş modelleri ve diğer yazılım dışı sistemleri belirtmek, görselleştirmek, oluşturmak ve belgelemek için kullanılan bir dildir. UML, daha önce büyük ve karmaşık sistemleri modellemek için başarıyla kullanılmış olan mühendislik tekniklerinin bir karışımıdır.

& nbsp & nbsp & nbsp & nbsp UML'nin yaratıcıları, onu yazılım sistemlerini, iş sistemlerini ve çeşitli nitelikteki diğer sistemleri tanımlamak, temsil etmek, tasarlamak ve belgelemek için bir dil olarak temsil eder. UML, gösterimi ve metamodeli tanımlar. Notasyon, modellerde kullanılan grafik nesnelerin bir koleksiyonudur; bir modelleme dilinin sözdizimidir.

& nbsp & nbsp & nbsp & nbsp UML, aşağıdakileri sağlayan görsel modeller oluşturmak için etkileyici araçlar sağlar:

• projeye dahil olan tüm geliştiriciler tarafından tek tip olarak anlaşılmalıdır;
• proje içinde bir iletişim aracıdır.

& nbsp & nbsp & nbsp & nbsp Birleşik Modelleme Dili (UML):

• nesne yönelimli (OO) programlama dillerine bağlı değildir;
• kullanılan proje geliştirme metodolojisine bağlı değildir;
• herhangi bir OO programlama dilini destekleyebilir.

& nbsp & nbsp & nbsp & nbsp UML açık kaynaklıdır ve temeldeki çekirdeğe genişletilebilir. UML'de, genellikle birbirinden çok farklı olan çeşitli konu alanlarındaki sınıfları, nesneleri ve bileşenleri anlamlı bir şekilde tanımlayabilirsiniz.

UML diyagramları

& nbsp & nbsp & nbsp & nbsp Sistem tasarımcısının emrinde, Rational Rose, sıralı oluşturma, tasarlanan tüm sistemin ve bireysel bileşenlerinin tam bir resmini elde etmenizi sağlayan aşağıdaki diyagram türlerini sağlar:

• Kullanım durumu diyagramı
• Dağıtım şeması (topoloji şemaları);
• Durum diyagramı;
• etkileşim diyagramı Etkinlik şeması
• Sıra diyagramı
• İşbirliği diyagramı
• Sınıf diyagramı
• bileşen diyagramı
• davranış diyagramları
• Etkinlik şeması
• Uygulama şemaları

& nbsp & nbsp & nbsp & nbsp Bu diyagramların her biri sistem modelinin farklı bir görünümünü somutlaştırır. Bu durumda, kullanım durumu diyagramı, diğer tüm diyagramları oluşturmak için başlangıç ​​noktası olan sistemin kavramsal bir modelini temsil eder. Sınıf diyagramı, bir sistemin yapısal tasarımının statik yönlerini yansıtan mantıksal bir modeldir ve aynı zamanda mantıksal bir modelin çeşitleri olan davranış diyagramları, işleyişinin dinamik yönlerini yansıtır. Uygulama diyagramları, bir sistemin bileşenlerini temsil etmek ve fiziksel modeline atıfta bulunmak için kullanılır.

& nbsp & nbsp & nbsp & nbsp Yukarıdaki diyagramlardan bazıları iki veya daha fazla alt türü belirtmek için kullanılır. Aşağıdaki diyagramlar bağımsız temsiller olarak kullanılır: kullanım durumları, sınıflar, durumlar, etkinlikler, sıra, işbirliği, bileşenler ve dağıtımlar.

& nbsp & nbsp & nbsp & nbsp UML diyagramları için içerdikleri bilgiler açısından önemli olan üç tür görsel sembol vardır:

• bağlantılar düzlemde farklı çizgilerle temsil edilen;
• Metin bireysel geometrik şekillerin sınırları içinde yer alan;
• grafik sembolleriçizelgelerin görsellerine yakın çizilir.

& nbsp & nbsp & nbsp & nbsp Diyagramları grafik olarak görüntülerken, aşağıdaki kurallara uyulması önerilir:

• her diyagram, simüle edilen alanın bir bölümünün tam bir temsili olmalıdır;
• diyagramda temsil edilen modelin varlıkları aynı kavramsal düzeyde olmalıdır;
• varlıklarla ilgili tüm bilgiler şemada açıkça gösterilmelidir;
• diyagramlar çelişkili bilgiler içermemelidir;
• diyagramlar metinsel bilgilerle aşırı yüklenmemelidir;
• her diyagram, tüm öğelerinin doğru yorumlanması için kendi kendine yeterli olmalıdır;
• belirli bir sistemi tanımlamak için gereken diyagram türlerinin sayısı kesin olarak sabit değildir ve geliştirici tarafından belirlenir;
• sistem modelleri yalnızca UML gösteriminde tanımlanan öğeleri içermelidir.

UML'deki varlıklar

& nbsp & nbsp & nbsp & nbsp UML dört tür varlık tanımlar: yapısal, davranışsal, gruplama ve açıklama... Varlıklar, modellerin oluşturulduğu dilin ana nesne yönelimli öğeleridir.

& nbsp & nbsp & nbsp & nbsp yapısal varlıklar UML modellerinde isimlerdir. Tipik olarak, sistemin kavramsal veya fiziksel öğelerine karşılık gelen modelin statik parçalarını temsil ederler. Yapısal varlıklara örnek olarak sınıf, arayüz, işbirliği, kullanım durumu, bileşen, düğüm, aktör verilebilir.

& nbsp & nbsp & nbsp & nbsp davranışsal varlıklar UML modelinin dinamik bileşenleridir. Bunlar, bir modelin zaman ve mekan içindeki davranışını tanımlayan fiillerdir. İki ana davranışsal varlık türü vardır:

• etkileşim, özü belirli bir amaca ulaşmak için belirli bir bağlamda nesneler arasında mesaj alışverişi olan davranıştır;
• otomat - çeşitli olaylara yanıt olarak bir nesnenin veya etkileşimin içinden geçtiği durumların sırasını belirleyen bir davranış algoritması.

& nbsp & nbsp & nbsp & nbsp Varlıkları gruplandırma UML modelinin düzenleyici parçalarıdır. Bunlar, modelin ayrıştırılabileceği bloklardır. Böyle bir birincil varlığın tek bir kopyası vardır - bu bir pakettir.

& nbsp & nbsp & nbsp & nbsp Paketler, öğeleri gruplar halinde düzenlemek için evrensel bir mekanizmadır. Yapısal, davranışsal ve diğer gruplandırma varlıkları pakete yerleştirilebilir. Program çalışırken gerçekte var olan bileşenlerin aksine, paketler tamamen kavramsaldır, yani yalnızca geliştirme sürecinde var olurlar.

& nbsp & nbsp & nbsp & nbsp Açıklama varlıkları UML modelinin açıklayıcı kısımlarıdır: modelin herhangi bir unsuruna ilişkin ek açıklama, açıklama veya açıklamalar için yorumlar. Açıklama öğelerinin yalnızca bir temel türü vardır, açıklama. Resmi olmayan veya resmi metinlerde ifade edilen diyagramlara yorumlar veya kısıtlamalar sağlamak için bir not kullanılır.

UML'deki ilişkiler

& nbsp & nbsp & nbsp & nbsp UML'de aşağıdaki ilişki türleri tanımlanmıştır: bağımlılık, ilişkilendirme, genelleme ve uygulama... Bu ilişkiler, UML'deki ana yapıştırıcı yapılardır ve ayrıca varlıkların modeller oluşturmak için nasıl kullanıldığıdır.

& nbsp & nbsp & nbsp & nbsp Bağımlılık iki varlık arasındaki semantik bir ilişkidir, bunlardan birinde bağımsız, diğerinin semantiğini etkileyebilir, bağımlı.

& nbsp & nbsp & nbsp & nbsp bağlantı- nesneler arasındaki bir dizi semantik veya mantıksal bağlantıyı tanımlayan yapısal bir ilişki.

& nbsp & nbsp & nbsp & nbsp genellemeözel bir öğe nesnesinin (soydan gelen) bir genel öğe nesnesi (ata) ile değiştirilebildiği bir ilişkidir. Aynı zamanda nesne yönelimli programlama ilkelerine uygun olarak çocuk, ebeveyninin (ebeveynin) yapısını ve davranışını miras alır.

& nbsp & nbsp & nbsp & nbsp gerçekleştirme Bir sınıflandırıcının bir yükümlülüğü tanımladığı ve diğerinin onun yerine getirilmesini garanti ettiği sınıflandırıcılar arasındaki anlamsal bir ilişkidir. Bir uygulama ilişkisi iki durumda oluşur:

• arabirimler ve bunları uygulayan sınıflar veya bileşenler arasında;
• kullanım durumları ve bunları uygulayan işbirlikleri arasında.

Ortak UML Mekanizmaları

& nbsp & nbsp & nbsp & nbsp UML'deki sistemin doğru bir açıklaması için, genel mekanizmalar olarak adlandırılanlar kullanılır:

• özellikler;
• eklemeler (süsler);
• bölümler (ortak bölümler);
• genişletilebilirlik mekanizmaları

& nbsp & nbsp & nbsp & nbsp UML sadece grafiksel bir dil değildir. Notasyonunun her bir grafik öğesi, Şartname karşılık gelen dil yapısının metinsel temsilini içerir. Örneğin, bir sınıf simgesinin özniteliklerini, işlemlerini ve davranışını tanımlayan bir özelliği vardır, ancak bir diyagramda görsel olarak simge genellikle bu bilgilerin yalnızca küçük bir bölümünü yansıtır. Ayrıca model, bu sınıfın tamamen farklı yönlerini yansıtan, ancak yine de spesifikasyona karşılık gelen başka bir temsilini içerebilir. Bu nedenle, sistemi görselleştirmek için grafik UML notasyonu kullanılır ve spesifikasyonlar yardımıyla ayrıntılarını açıklar.

& nbsp & nbsp & nbsp & nbsp Hemen hemen her UML öğesinin, en önemli özelliklerinin görsel bir temsilini sağlayan benzersiz bir grafik temsili vardır. "Sınıf" varlık gösterimi, adını, niteliklerini ve işlemlerini içerir. Bir sınıf belirtimi, özniteliklerin ve işlemlerin görünürlüğü, yorumlar veya sınıfın soyut olduğuna dair bir gösterge gibi diğer ayrıntıları içerebilir. Bu ayrıntıların çoğu grafik veya metin olarak işlenebilir. eklemeler sınıfı temsil eden standart dikdörtgene.

& nbsp & nbsp & nbsp & nbsp Nesne yönelimli sistemleri modellerken, belirli bir bölünme temsil edilen varlıklar.

& nbsp & nbsp & nbsp & nbsp İlk olarak, sınıflara ve nesnelere bölünme vardır. Bir sınıf bir soyutlamadır ve bir nesne bu soyutlamanın somut bir düzenlemesidir. Bu bağlamda, hemen hemen tüm dil yapıları bir sınıf/nesne ikiliği ile karakterize edilir. Dolayısıyla, kullanım durumları ve kullanım durumu örnekleri, bileşenler ve bileşen örnekleri, düğümler ve düğüm örnekleri vardır. Grafik gösterimde, bir nesne için bir sınıfla aynı sembolü kullanmak ve adın altını çizmek gelenekseldir.

& nbsp & nbsp & nbsp & nbsp İkinci olarak, arayüz ve uygulaması arasında bir bölünme vardır. Arayüz taahhütleri beyan eder ve uygulama bu taahhütlerin somut uygulamasını temsil eder ve beyan edilen anlambilimin yakından takip edilmesini sağlar. Bu nedenle, hemen hemen tüm UML yapıları, arayüz/uygulama ikiliği ile karakterize edilir. Örneğin, kullanım senaryoları kooperatifler tarafından ve operasyonlar yöntemlerle uygulanmaktadır.

& nbsp & nbsp & nbsp & nbsp UML açık bir dildir, yani kontrollü uzantıların alan modellerinin özelliklerini yansıtmasını sağlar.

& nbsp & nbsp & nbsp & nbsp UML uzatma mekanizmaları şunları içerir:

• klişeler (klişeler) - UML kelime dağarcığını genişleterek, mevcut dil öğelerine dayanarak, belirli bir sorunu çözmeye odaklanan yenilerini oluşturmaya izin verir;
• etiketli değer - temel UML yapılarının özelliklerini genişleterek, öğe belirtimine ek bilgilerin eklenmesine izin verir;
• kısıtlamalar - UML yapılarının anlamını genişleterek yeni kurallar oluşturmanıza ve mevcut kuralları geçersiz kılmanıza olanak tanır.

& nbsp & nbsp & nbsp & nbsp Birlikte, bu üç dil genişletme mekanizması, onu projenin ihtiyaçlarına veya geliştirme teknolojisinin özelliklerine göre değiştirmenize olanak tanır.

Kullanım durumu diyagramı

& nbsp & nbsp & nbsp & nbsp Bu tür diyagram, sistemin gerçekleştirdiği işlemlerin bir listesini oluşturmanıza olanak tanır. Bu tür diyagramlara genellikle fonksiyon diyagramı denir, çünkü bu tür diyagramlar kümesine dayalı olarak sistem gereksinimlerinin bir listesi oluşturulur ve sistem tarafından gerçekleştirilen fonksiyonlar kümesi belirlenir.

Şekil - 1. Kullanım senaryoları şeması

& nbsp & nbsp & nbsp & nbsp Kullanım durumu diyagramları, bir sistemin işlevselliğini veya sistemin ne yapması gerektiğini açıklar. Diyagramın geliştirilmesi aşağıdaki hedeflere sahiptir:

• simüle edilen alanın genel sınırlarını ve bağlamını tanımlar;
• tasarlanan sistemin işlevsel davranışı için genel gereksinimleri formüle etmek;
• mantıksal ve fiziksel modeller şeklinde sonraki detaylandırması için sistemin ilk kavramsal modelini geliştirmek;
• sistem geliştiricilerinin müşterileri ve kullanıcıları ile etkileşimi için ilk belgeleri hazırlamak.

& nbsp & nbsp & nbsp & nbsp Kullanım durumu diyagramının özü aşağıdaki gibidir. Tasarlanan sistem, kullanım durumları aracılığıyla sistemle etkileşime giren bir dizi varlık veya aktör olarak temsil edilir. Bu durumda, bir aktör veya aktör, sistemle dışarıdan etkileşime giren herhangi bir varlıktır. Geliştiricinin kendisinin belirlediği şekilde, modellenen sistem üzerinde bir etki kaynağı olarak hizmet edebilecek bir kişi, teknik cihaz, program veya başka herhangi bir sistem olabilir. kullanım durumu sistemin oyuncuya sağladığı hizmetleri tanımlamaya hizmet eder.

& nbsp & nbsp & nbsp & nbsp Kullanım senaryosunun amacı, bir varlığın davranışının iç yapısını açığa çıkarmadan tam bir yönünü veya parçasını tanımlamaktır. Böyle bir varlık, bir sistem veya kendi davranışı olan bir modelin herhangi bir öğesi olabilir.

& nbsp & nbsp & nbsp & nbsp Her kullanım durumu, modellenen varlığın aktörün isteği üzerine sağladığı ayrı bir hizmete karşılık gelir, yani bu varlığın nasıl kullanıldığını belirler. Aktörün isteği üzerine başlatılan hizmet, eksiksiz, bölünmez bir eylemler dizisidir. Bu, sistemin isteği işlemeyi bitirdikten sonra sonraki istekleri yürütmeye hazır olması için orijinal durumuna dönmesi gerektiği anlamına gelir.

& nbsp & nbsp & nbsp & nbsp Kullanım Durumları hem tasarlanan sistem için harici gereksinimleri belirtmek hem de mevcut bir sistemin işlevsel davranışını belirtmek için kullanılabilir. Bir bütün olarak kullanım durumları kümesi, sistemin beklenen davranışının tüm olası taraflarını tanımlamalıdır. Ek olarak, kullanım senaryoları, sağlanan hizmetlerle doğru şekilde çalışabilmek için aktörlerin sistemle nasıl etkileşime girmesi gerektiğini belirleyen gereksinimleri dolaylı olarak belirler. Kolaylık sağlamak için birçok kullanım senaryosu ayrı bir paket olarak görülebilir.

& nbsp & nbsp & nbsp & nbsp Kullanım örnekleri şunları içerebilir: bir müşterinin cari hesabının durumunu kontrol etme, bir ürünün satın alınması için sipariş verme, müşterinin kredibilitesi hakkında ek bilgi alma, monitör ekranında bir grafik formu görüntüleme , ve diğer eylemler.

Sınıf diyagramı

& nbsp & nbsp & nbsp & nbsp Nesne yönelimli programlamanın merkezi, bir sistemin mantıksal bir modelinin sınıf diyagramı biçiminde geliştirilmesidir. Nesne yönelimli programlama sınıflarının terminolojisinde bir sistem modelinin statik yapısını temsil etmek için bir sınıf diyagramı (sınıf diyagramı) kullanılır. Bir sınıf diyagramı, özellikle, nesneler ve alt sistemler gibi etki alanının bireysel varlıkları arasındaki çeşitli ilişkileri yansıtabilir ve bunların iç yapılarını ve ilişki türlerini tanımlayabilir.

Şekil - 2. Sınıf diyagramı

& nbsp & nbsp & nbsp & nbsp Diyagram simgeleri, karmaşık bir sistem hiyerarşisi, sınıf ilişkileri (Sınıflar) ve arabirimler (Arayüzler) görüntülemenize olanak tanır. Bu diyagram türü içerik olarak sistem nesnelerini görüntüleyen İşbirliği diyagramının tam tersidir. Rational Rose, bu tür diyagramları çeşitli gösterimlerde kullanarak sınıflar oluşturmanıza olanak tanır. bir bulut gibi. Bu nedenle, bir sınıf sadece gelecekte belirli bir nesnenin oluşturulacağı bir şablondur.

& nbsp & nbsp & nbsp & nbsp Sınıf diyagramı, köşeleri "sınıflandırıcı" türünün öğeleri olan ve çeşitli yapısal ilişkilerle birbirine bağlanan bir grafiktir. Bir sınıf diyagramı ayrıca arayüzler, paketler, ilişkiler ve hatta nesneler ve ilişkiler gibi bireysel örnekler içerebilir.

& nbsp & nbsp & nbsp & nbsp Sınıf UML dilinde, diğer sınıfların nesneleri ile aynı yapıya, davranışa ve ilişkilere sahip bir dizi nesneyi belirtmek için kullanılır. Sınıf, ek olarak yatay çizgilerle bölümlere veya bölümlere ayrılabilen bir dikdörtgen olarak grafiksel olarak gösterilir. Bu bölümler sınıf adını, nitelikleri (değişkenleri) ve işlemleri (yöntemleri) içerebilir.

Durum diyagramı (durum diyagramı diyagramı)

& nbsp & nbsp & nbsp & nbsp UML'deki her durum diyagramı, belirli bir sınıfın bir örneğinin tüm olası durumlarını ve bir durumdan diğerine geçişlerinin olası dizilerini tanımlar, yani bir nesnenin durumlarındaki tüm değişiklikleri şu şekilde modeller: dış etkilere tepkisi.

& nbsp & nbsp & nbsp & nbsp Durum çizelgeleri en yaygın olarak tek tek nesnelerin davranışını tanımlamak için kullanılır, ancak kullanım durumları, aktörler, alt sistemler, işlemler ve yöntemler gibi diğer model bileşenlerinin işlevselliğini belirtmek için de kullanılabilir.

Şekil - 2. Durum diyagramı

& nbsp & nbsp & nbsp & nbsp Durum diyagramı, bazı otomatları temsil eden özel bir grafik türüdür. Grafiğin köşeleri, ilgili grafik sembolleriyle gösterilen otomatın olası durumlarıdır ve yaylar, durumdan duruma geçişlerini gösterir. Modelin ayrı ayrı öğelerinin daha ayrıntılı bir sunumu için durum diyagramları iç içe yerleştirilebilir.

& nbsp & nbsp & nbsp & nbsp UML meta modelinde makine modellenmiş bir varlığın davranışını sonlu sayıda durum ve geçişle ayrı bir uzay biçiminde temsil etmek için gerekli bir dizi kavramı tanımlayan bir pakettir.

& nbsp & nbsp & nbsp & nbsp Sistemin olası durumlardan herhangi birinde bulunma süresi, bir durumdan diğerine geçiş için geçen süreyi önemli ölçüde aşıyor. Limitte, geçiş süresinin sıfıra eşit olabileceği (aksi belirtilmedikçe), yani nesne durumlarındaki değişikliğin anında gerçekleşebileceği varsayılmaktadır.

& nbsp & nbsp & nbsp & nbsp Makinenin davranışı, onları birbirine bağlayan yayların oryantasyonu dikkate alınarak, tepe noktasından tepe noktasına grafik boyunca sıralı hareket olarak modellenir.

& nbsp & nbsp & nbsp & nbsp Makine için aşağıdaki ön koşullar karşılanmalıdır:

• bir nesnenin girebileceği durum, yalnızca mevcut durumu tarafından belirlenir ve tarihe bağlı değildir;
• her an, otomat, durumlarından sadece birinde olabilir. Aynı zamanda, herhangi bir olay meydana gelmezse, otomat herhangi bir süre boyunca ayrı bir durumda kalabilir;
• makinenin belirli bir durumda olduğu süre ve belirli bir duruma ulaşması için geçen süre hiçbir şekilde belirtilmemiştir;
• otomatın durum sayısı sonlu olmalı ve hepsi açıkça belirtilmelidir. Bireysel sözde durumlar spesifikasyonlara sahip olmayabilir (başlangıç ​​ve son durumlar). Bu durumda, amaçları ve semantikleri tamamen model bağlamından ve dikkate alınan durum diyagramından belirlenir;
• otomat grafiği izole durumlar ve geçişler içermemelidir. İlk durum hariç her durum için bir önceki durum tanımlanmalı ve her geçiş otomatın iki durumunu birbirine bağlamalıdır;
• nesne aynı anda iki veya daha fazla ardışık duruma gidebildiğinde (paralel alt otomatlar durumu hariç), otomat çelişkili geçişler içermemelidir. UML'de, koruma koşulları getirilerek çatışmalardan kaçınılabilir.

devletler sadece UML meta modelinde değil, aynı zamanda uygulamalı sistem analizinde de temeldir. Dinamik bir sistem kavramının tamamı, bir durum kavramına dayanmaktadır. UML'deki durum semantiğinin bir takım spesifik özellikleri vardır.

& nbsp & nbsp & nbsp & nbsp UML'de durum, belirli koşulların karşılandığı tek bir durumu modellemek için kullanılan soyut bir metasınıftır. Durum, bir sınıfın veya nesnenin nitelikleri için belirli bir değerler kümesi olarak belirtilebilir. Bireysel öznitelik değerlerinde yapılan değişiklikler, modellenen sınıf veya nesnenin durumundaki değişiklikleri yansıtacaktır.

Etkinlik şeması

& nbsp & nbsp & nbsp & nbsp Tasarlanmış veya analiz edilmiş bir sistemin davranışını modellerken, yalnızca durumlarını değiştirme sürecini temsil etmek değil, aynı zamanda tarafından gerçekleştirilen işlemlerin algoritmik ve mantıksal uygulamasının özelliklerini detaylandırmak da gerekli hale gelir. sistem.

& nbsp & nbsp & nbsp & nbsp Aslında, bu tür diyagramlar modellenmiş bir nesnenin durumlarını yansıtmak için de kullanılabilir, ancak bir Faaliyet diyagramının temel amacı bir nesnenin iş süreçlerini yansıtmaktır. Bu tür bir diyagram, yalnızca işlemlerin sırasını değil, aynı zamanda işlemlerin dallanmasını ve hatta senkronizasyonunu da göstermenize olanak tanır.

& nbsp & nbsp & nbsp & nbsp Bu tür diyagramlar, blok diyagramları oluşturmak için kullanılabilirler de dahil olmak üzere herhangi bir karmaşıklıktaki nesnelerin davranışı için algoritmalar tasarlamanıza olanak tanır.

& nbsp & nbsp & nbsp & nbsp Etkinlik diyagramları, işlemleri UML dilinde gerçekleştirme sürecini modellemek için kullanılır. Kullandıkları grafiksel gösterim, durumları ve geçişleri de içermeleri bakımından durum çizelgesi gösterimine çok benzer. Aktivite diyagramındaki her durum, bazı temel işlemlerin yürütülmesine karşılık gelir ve bir sonraki duruma geçiş ancak bu işlemin tamamlanmasıyla gerçekleştirilir.

& nbsp & nbsp & nbsp & nbsp Bu nedenle, etkinlik diyagramları durum diyagramlarının özel bir durumu olarak kabul edilebilir. Dahili faaliyetlerin ve eylemlerin tamamlanması nedeniyle UML dilinde prosedürel ve senkronize kontrolün özelliklerini uygulamanıza izin verirler. Etkinlik diyagramlarını kullanmanın ana yönü, yürütülmesi için algoritmalar sunmak gerektiğinde, sınıf işlemlerinin uygulanmasının özelliklerini görselleştirmektir.

& nbsp & nbsp & nbsp & nbsp UML bağlamında aktivite makine tarafından gerçekleştirilen ve bazı sonuçlara veya eylemlere (eylemlere) yol açan bireysel hesaplamaların bir toplamıdır. Aktivite diyagramı, bir aktiviteden diğerine geçişlerin mantığını ve sırasını gösterir ve analistin dikkati sonuçlara odaklanır. Faaliyetin sonucu, sistemin durumunda bir değişikliğe veya bir değerin geri dönmesine yol açabilir.

& nbsp & nbsp & nbsp & nbsp Eylem durumu bazı girdi eylemi ve durumdan ayrılan en az bir geçişi olan bir durumun özel bir durumudur. Bu geçiş, dolaylı olarak girdi eyleminin zaten tamamlandığını varsayar. Eylem durumu, temel olduğu için iç geçişlere sahip olamaz. Eylem durumunun yaygın bir kullanımı, bir algoritmanın (prosedür) veya kontrol akışının yürütülmesinde tek bir adımı simüle etmektir.

Sıra diyagramı

& nbsp & nbsp & nbsp & nbsp Durum ve aktivite diyagramları göz önüne alındığında, bu diyagramların sistemlerin davranışının dinamiklerini belirtmek için kullanılmasına rağmen, onlarda zamanın açıkça mevcut olmadığına dikkat edildi. Davranışın zamansal yönü, nesnelerin etkileşimini tanımlayan eşzamanlı süreçlerin modellenmesinde önemli bir öneme sahip olabilir. UML, nesnelerin zaman içindeki etkileşimini modellemek için dizi diyagramlarını kullanır.

& nbsp & nbsp & nbsp & nbsp Sıra şeması yalnızca nesneler etkileşimde doğrudan yer alan kişilerdir. Dizi diyagramları için kilit nokta, nesnelerin zaman içindeki etkileşiminin dinamikleridir.

& nbsp & nbsp & nbsp & nbsp UML'de bir dizi diyagramının iki boyutu vardır. Soldan sağa, her biri etkileşime katılan ayrı bir nesnenin yaşam çizgisini gösteren dikey çizgiler şeklinde. Diyagramın en solunda etkileşimi başlatan nesne gösterilmektedir. Sağda, doğrudan ilkiyle etkileşime giren başka bir nesne tasvir edilmiştir. Böylece, dizi diyagramındaki tüm nesneler, birbirleriyle etkileşime girerken nesnelerin etkinliği veya derecesi ile belirlenen bir tür düzen oluşturur.

& nbsp & nbsp & nbsp & nbsp Grafik olarak, her nesne bir dikdörtgen olarak gösterilir ve yaşam çizgisinin en üstünde bulunur. Nesne adı ve sınıf adı, iki nokta üst üste ile ayrılmış olarak dikdörtgenin içine yazılır. Bu durumda, nesnenin bir özelliği olan tüm kaydın altı çizilir.

& nbsp & nbsp & nbsp & nbsp Sıra diyagramının ikinci boyutu, yukarıdan aşağıya dikey zaman eksenidir. Diyagramın en üst kısmı, zaman içindeki ilk ana karşılık gelir. Nesne etkileşimleri, bir nesneden diğerine gönderilen mesajlar aracılığıyla gerçekleştirilir. Mesajlar, mesaj adıyla birlikte yatay oklar olarak görüntülenir ve bunların sırası, oluşma zamanına göre belirlenir. Yani, yukarıdaki sıra şemasında yer alan mesajlar, aşağıda bulunanlardan daha erken tetiklenir. Zaman eksenindeki ölçek gösterilmemiştir çünkü dizi diyagramı yalnızca erken-sonraki etkileşimlerin zamansal sıralamasını modellemektedir.

İşbirliği diyagramı

& nbsp & nbsp & nbsp & nbsp İşbirliği diyagramının ana özelliği, yalnızca etkileşim sırasını değil, aynı zamanda bu etkileşime katılan nesneler arasındaki tüm yapısal ilişkileri grafiksel olarak temsil etme yeteneğidir.

Şekil - 3. İşbirliği diyagramı

& nbsp & nbsp & nbsp & nbsp Bu tür diyagram, mesajların iletim dizisinden soyutlayarak nesnelerin etkileşimini tanımlamanıza olanak tanır. Belirli bir nesnenin alınan ve iletilen tüm mesajları ve bu mesajların türleri, bu tür diyagramlarda kompakt bir biçimde yansıtılır.

& nbsp & nbsp & nbsp & nbsp Her şeyden önce, dikdörtgen şeklindeki işbirliği şeması, etkileşime katılan nesneleri, nesnenin adını, sınıfını ve muhtemelen niteliklerin değerlerini içerir. Ayrıca, sınıf diyagramında olduğu gibi, nesneler arasındaki ilişkiler, çeşitli bağlantı hatları şeklinde gösterilir. Bu durumda, ilişkilendirmenin adlarını ve nesnelerin bu ilişkilendirmede oynadığı rolleri açıkça belirtebilirsiniz. Ek olarak, dinamik bağlantılar - mesaj akışları gösterilebilir. Bunlar ayrıca nesneler arasındaki bağlantı çizgileri olarak temsil edilirler; bunların üzerinde, genel mesaj başlatma sıralamasında yönü, mesaj adını ve sıra numarasını gösteren bir ok vardır.

& nbsp & nbsp & nbsp & nbsp Sıra diyagramından farklı olarak, işbirliği diyagramı yalnızca bir etkileşimde belirli roller oynayan nesneler arasındaki ilişkileri gösterir. Bu grafik, zamanı ayrı bir boyut olarak göstermez. Bu nedenle, etkileşimlerin ve paralel akışların sırası, sıra numaraları kullanılarak belirlenebilir. Bu nedenle, nesneler arasındaki ilişkileri gerçek zamanlı olarak açıkça belirtmeniz gerekiyorsa, bunu bir dizi diyagramında yapmak en iyisidir.

& nbsp & nbsp & nbsp & nbsp Konsept işbirliği UML'deki temel kavramlardan biridir. Modellenen sistemin genel bağlamında belirli bir amaç ile etkileşime giren bir dizi nesneyi belirlemeye hizmet eder. İşbirliğinin amacı, sistemdeki bireysel en önemli operasyonların uygulanmasının özelliklerini belirlemektir. İşbirliği, sistemin davranışının yapısını, bu işbirliğindeki katılımcıların etkileşimi açısından tanımlar.

& nbsp & nbsp & nbsp & nbsp İşbirliği iki düzeyde sunulabilir:

• belirtim düzeyi - düşünülen etkileşimde sınıflandırıcıların rollerini ve derneklerin rolünü gösterir;
• örnek düzeyi - işbirliğinde ayrı roller oluşturan örnekleri ve ilişkileri gösterir.

& nbsp & nbsp & nbsp & nbsp Malzeme Listesi düzeyinde işbirliği diyagramı, etkileşimde yer alan öğelerin oynadığı rolleri gösterir. Bu düzeydeki işbirliğinin unsurları, işbirliğindeki katılımcılar arasındaki sınıflandırıcıların ve derneklerin ayrı rollerini gösteren sınıflar ve birliklerdir.

& nbsp & nbsp & nbsp & nbsp Örnek düzeyinde bir işbirliği diyagramı, bir nesneler (sınıf örnekleri) ve ilişkiler (ilişkilendirme örnekleri) koleksiyonuyla temsil edilir. Bu durumda, bağlantılar mesaj oklarıyla desteklenir. Bu düzeyde, yalnızca bir işlemin veya sınıflandırıcının uygulanmasıyla doğrudan ilgili olan nesneler gösterilir. Bu durumda, işbirliği diyagramında yalnızca sınıflandırıcıların rolleri bulunduğundan, sınıflandırıcıların kendileri olmadığından, tüm özellikleri veya tüm ilişkileri göstermek hiç de gerekli değildir. Bu nedenle, sınıflandırıcı tüm örneklerinin tam bir tanımını gerektirirken, sınıflandırıcının rolü yalnızca belirli bir işbirliğine katılmak için gerekli olan özelliklerin ve ilişkilerin tanımını gerektirir.

& nbsp & nbsp & nbsp & nbsp Bundan önemli bir sonuç çıkar. Bir ve aynı nesne kümesi farklı kooperatiflere katılabilir. Söz konusu işbirliğine bağlı olarak, hem bireysel nesnelerin özellikleri hem de aralarındaki bağlantılar değişebilir. İşbirliği diyagramını, diyagram öğeleri arasındaki tüm özellikleri ve ilişkileri göstermesi gereken bir sınıf diyagramından ayıran şey budur.

bileşen diyagramı

& nbsp & nbsp & nbsp & nbsp Bu tür diyagram, sistemin fiziksel tasarımında bileşene göre sınıfların ve nesnelerin dağılımı için tasarlanmıştır. Bu tür diyagramlara genellikle birim diyagramları denir.

Şekil - 4. Bileşen şeması

& nbsp & nbsp & nbsp & nbsp Bir yazılım sisteminin eksiksiz tasarımı, birbiriyle tutarlı olması gereken mantıksal ve fiziksel seviyelerin bir dizi modelidir. UML, aşağıdakileri içeren sistem modellerini fiziksel olarak temsil etmek için uygulama diyagramlarını kullanır: bileşen diyagramı ve dağıtım şeması.

& nbsp & nbsp & nbsp & nbsp Bileşen diyagramı, daha önce ele alınan diyagramların aksine, sistemin fiziksel temsilinin özelliklerini açıklar. Kaynak ve yürütülebilir kod olabilen yazılım bileşenleri arasında bağımlılıklar kurarak geliştirilmekte olan sistemin mimarisini tanımlamanıza olanak tanır. Bir bileşen diyagramının ana grafik öğeleri, bileşenler, arayüzler ve bunların bağımlılıklarıdır.

& nbsp & nbsp & nbsp & nbsp Bileşen diyagramı aşağıdaki amaçlar için geliştirilmiştir:

• yazılım sisteminin kaynak kodunun genel yapısının görselleştirilmesi;
• yazılım sisteminin yürütülebilir sürümünün özellikleri;
• program kodunun bireysel parçalarının yeniden kullanılabilirliğini sağlamak;
• kavramsal ve fiziksel veritabanı şemalarının temsilleri.

& nbsp & nbsp & nbsp & nbsp Sistem analistleri ve mimarları ile programcılar, bileşen diyagramlarının geliştirilmesinde yer alır. Bir bileşen diyagramı, mantıksal bir görünümden program kodu biçiminde bir projenin belirli bir uygulamasına tutarlı bir geçiş sağlar. Bazı bileşenler yalnızca program kodunun derlenmesi aşamasında, diğerleri ise yürütme aşamasında bulunabilir. Bir bileşen diyagramı, bileşenler arasındaki genel bağımlılıkları yansıtır, ikincisini sınıflandırıcılar olarak kabul eder.

& nbsp & nbsp & nbsp & nbsp Fiziksel varlıkları UML dilinde temsil etmek için özel bir terim kullanılır - bileşen... Bileşen, belirli bir arayüz seti uygular ve modelin fiziksel temsilinin öğelerinin genel olarak tanımlanmasına hizmet eder. Bileşeni grafiksel olarak temsil etmek için özel bir sembol kullanılır - sola yerleştirilmiş iki küçük dikdörtgen içeren bir dikdörtgen. Büyük dikdörtgenin içine bileşenin adı ve gerekirse bazı ek bilgiler yazılır. Bu sembolün temsili, bileşenle ilişkili bilgilerin doğasına bağlı olarak biraz değişebilir.

Dağıtım şeması

& nbsp & nbsp & nbsp & nbsp Bu tür diyagramlar, sistemin donanımını, yani programları değil "donanımı" analiz etmek için tasarlanmıştır. İngilizce'den doğrudan çeviride, Dağıtım "dağıtım" anlamına gelir, ancak "topoloji" terimi bu tür diyagramların özünü daha doğru bir şekilde yansıtır.

Şekil - 5. Dağıtım şeması

& nbsp & nbsp & nbsp & nbsp Bir yazılım sisteminin fiziksel temsili, hangi platform ve hangi hesaplamanın uygulandığı hakkında hiçbir bilgi yoksa tam olamaz. Kullanıcının bilgisayarında yerel olarak çalışan ve çevresel aygıtları ve kaynakları kullanmayan bir program geliştiriliyorsa, ek diyagramlar geliştirmeye gerek yoktur. Kurumsal uygulamalar geliştirirken, bu tür diyagramların varlığı, ağın dağıtılmış bilgi işlem ve iletişim kaynaklarını etkin bir şekilde kullanmak, güvenliği sağlamak ve diğerleri için bileşenlerin rasyonel yerleşimi sorunlarını çözmek için son derece yararlı olabilir.

& nbsp & nbsp & nbsp & nbsp Dağıtım diyagramları, UML'de dağıtılmış bir yazılım sisteminin genel yapılandırmasını ve topolojisini temsil etmek için tasarlanmıştır.

& nbsp & nbsp & nbsp & nbsp Dağıtım şeması, programın yalnızca yürütme aşamasında (çalışma zamanı) var olan öğelerini ve bileşenlerini görselleştirmek için tasarlanmıştır. Bu durumda, yalnızca yürütülebilir dosyalar veya dinamik kitaplıklar olan programın bileşenleri-örnekleri sunulur. Çalışma zamanında kullanılmayan bileşenler dağıtım şemasında gösterilmez. Bu nedenle, programların kaynak kodlarına sahip bileşenler yalnızca bileşen şemasında bulunabilir. Dağıtım şemasında gösterilmezler.

& nbsp & nbsp & nbsp & nbsp Bir dağıtım şeması, işlemcilerin, cihazların, süreçlerin ve bunlar arasındaki ilişkilerin grafiksel temsillerini içerir. Mantıksal görünüm diyagramlarından farklı olarak, bir dağıtım diyagramı, uygulamasının özelliklerini tam olarak yansıtması gerektiğinden, bir bütün olarak sistem için tek tiptir. Bir dağıtım şemasının geliştirilmesi, genellikle yazılım sistem modelinin belirtilmesindeki son adımdır.

& nbsp & nbsp & nbsp & nbsp Bir dağıtım şeması geliştirirken aşağıdaki hedefler izlenir:

• sistem bileşenlerinin fiziksel düğümlerine göre dağılımını belirlemek;
• yürütme aşamasında sistem uygulamasının tüm düğümleri arasındaki fiziksel bağlantıları gösterin;
• sistemdeki darboğazları belirleyin ve gerekli performansı elde etmek için topolojisini yeniden yapılandırın.

& nbsp & nbsp & nbsp & nbsp Dağıtım diyagramları sistem analistleri, ağ mühendisleri ve sistem mühendisleri tarafından ortaklaşa geliştirilir.

Rational Rose masaüstü arayüzünün özellikleri

& nbsp & nbsp & nbsp & nbsp Rational Rose CASE aracı, iyi bilinen görsel programlama ortamlarına benzer şekilde, programın çalışma arayüzü için genel kabul görmüş standartları uygular. Yeni başlayanlar için bile pratikte zorluk çıkarmayan Rational Rose'u kullanıcının bilgisayarına kurduktan sonra, bu programı MS Windows 95/98 ortamında başlatmak, ekranda çalışan bir arayüz ile sonuçlanıyor (Şekil 6).

Şekil - 6. Rational Rose programının çalışma arayüzünün genel görünümü

& nbsp & nbsp & nbsp & nbsp Rational Rose çalışma arayüzü, başlıcaları:

• Programın ana menüsü
• Diyagram penceresi
• Belgeler penceresi
• Tarayıcı penceresi
• Günlük penceresi

Bu unsurların her birinin amacını ve ana işlevlerini kısaca ele alalım.

Programın ana menüsü

Programın ana menüsü genel kabul görmüş standartta yapılmıştır ve aşağıdaki forma sahiptir (Şekil 7).

Adından da anlaşılacağı gibi, tek tek menü öğeleri, tüm proje ile ilgili benzer işlemleri bir bütün olarak birleştirir. Menü öğelerinin bazıları tanıdık işlevler içerir (proje açma, diyagramları çıktı alma ve yazdırma, panoya kopyalama ve panodan çeşitli diyagram öğelerini yapıştırma). Diğerleri o kadar spesifiktir ki, öğrenmek için ek çaba gerektirebilir (program kodu oluşturma, modellerin tutarlılığını kontrol etme, ek modülleri bağlama seçenekleri).

Şekil - 7. Programın ana menüsünün görünümü

Standart araç çubuğu

Standart araç çubuğu, programın ana menüsünün altında bulunur ve şöyle görünür (Şekil 8). Araçlardan bazıları mevcut değil (yeni projede öğe yok). Standart araç çubuğu, geliştiricilerin en sık gerçekleştirdiği menü komutlarına hızlı erişim sağlar.

Şekil - 8. Standart araç çubuğunun görünümü

Kullanıcı, bu panelin görünümünü kendi takdirine bağlı olarak özelleştirebilir. Bunu yapmak için Araçlar -> Seçenekler menü öğesini seçin ve Araç Çubukları sekmesini açın. Bu şekilde çeşitli araç düğmelerini gösterebilir veya gizleyebilir ve boyutlarını değiştirebilirsiniz.

Tarayıcı penceresi

Varsayılan olarak, tarayıcı penceresi, standart araç çubuğunun altındaki çalışma arayüzünün sol tarafında bulunur (Şekil 9).

Tarayıcı, model görünümlerini, gezinmeyi basitleştiren ve projenizdeki herhangi bir model öğesini bulmanızı sağlayan hiyerarşik bir yapı içinde düzenler. Bu durumda, geliştiricinin modele eklediği herhangi bir öğe, tarayıcı penceresinde hemen görüntülenir. Buna göre, tarayıcı penceresinde bir öğe seçtikten sonra, onu diyagram penceresinde görselleştirebilir veya özelliklerini değiştirebiliriz. Tarayıcı ayrıca model öğelerini paketler halinde düzenlemenize ve öğeleri modelin farklı görünümleri arasında taşımanıza olanak tanır. İstenirse, tarayıcı penceresi çalışma arayüzünün başka bir yerine yerleştirilebilir veya Görünüm menü öğesi kullanılarak tamamen gizlenebilir. Dış çerçevesinin kenarlığını sürükleyerek de tarayıcıyı yeniden boyutlandırabilirsiniz.

Şekil - 9. tarayıcı görünümü

Özel araç çubuğu

Tarayıcı penceresi ile çalışma arayüzünün ortasındaki diyagram penceresi arasında özel bir araç çubuğu bulunur. Varsayılan olarak, modelin sınıf diyagramını oluşturmak için bir araç çubuğu sunulur (Şekil 10).

Şekil - 10.Özel bir sınıf diyagramı araç çubuğunun görünümü

Araç çubuğunun çerçevesini istediğiniz konuma taşıyarak özel araç çubuğunun konumunu değiştirebilirsiniz. Ayrıca belirli araçlara karşılık gelen düğmeleri tek tek ekleyerek veya kaldırarak panelin kompozisyonunu özelleştirebilirsiniz. Düğme atamaları, fare işaretçisi ilgili düğme üzerinde duraklatıldıktan sonra görünen araç ipuçlarında bulunabilir.

Diyagram penceresi

Diyagram penceresi, proje modelinin çeşitli görünümlerinin görselleştirildiği arayüzünün ana çalışma alanıdır. Varsayılan olarak, diyagram penceresi çalışma arayüzünün sağ tarafında bulunur, ancak konumu ve boyutu da değiştirilebilir. Yeni bir proje geliştirirken, proje sihirbazı kullanılmadıysa, diyagram penceresi modelin herhangi bir öğesini içermeyen boş bir alandır (Şekil 11).

Bu pencerede bulunan diyagramın adı programın başlık çubuğunda (programın en üst satırında) veya pencere tam ekrana genişletilmemişse diyagram penceresinin başlık çubuğunda gösterilir. . Diyagram penceresinde aynı anda birkaç diyagram bulunabilir, ancak bunlardan sadece biri aktif olabilir. Örneğin, Şekil 1'de. 11, diğer diyagramlar mevcut olmasına rağmen, dağıtım diyagramı etkindir. Diyagramlar arasında geçiş, standart araç çubuğunda istenen görünüm seçilerek veya Pencere menü öğesi aracılığıyla yapılabilir. Ayrı bir diyagram türünü etkinleştirirken, belirli bir diyagram türü için ayarlanmış özel bir araç çubuğunun görünümü değişir.

Şekil - 11. Modelin farklı görünümleri ile diyagram penceresinin görünümü

Belgeler penceresi

Varsayılan dokümantasyon penceresi ekranda bulunmayabilir. Bu durumda, Görünüm -> Belgeler menü öğesi aracılığıyla etkinleştirilebilir, ardından tarayıcının altında görünecektir (Şek. 12).

Belge penceresi, adından da anlaşılacağı gibi, model görünümünün öğelerini belgelemek içindir. İçine çeşitli bilgiler yazabilirsiniz ve önemli olan - Rusça. Bu bilgiler daha sonra yorumlara dönüştürülür ve program kodunun yürütülmesinin mantığını hiçbir şekilde etkilemez.

Dokümantasyon penceresinde, diyagramın ayrı bir seçilmiş öğesiyle ilgili bilgiler etkinleştirilir. Bu durumda, tarayıcı penceresinde veya diyagram penceresinde bir öğe seçebilirsiniz. Diyagrama yeni bir öğe eklendiğinde (örneğin, bir sınıf), boş olan belgeleri otomatik olarak oluşturulur (Belge yok). Daha sonra, geliştirici, proje üzerinde çalışırken hatırlanan ve değiştirilebilen gerekli açıklayıcı bilgileri bağımsız olarak sunar.

Çalışma arayüzünün diğer pencerelerinin yanı sıra, dokümantasyon penceresinin boyutunu ve konumunu değiştirebilirsiniz.

Şekil - 12. Dokümantasyon penceresi görünümü

Günlük penceresi

Günlük penceresi, programla çalışma sırasında oluşturulan çeşitli hizmet bilgilerinin otomatik olarak kaydedilmesi için tasarlanmıştır. Günlük, modeli güncelleme, menüleri ve araç çubuklarını özelleştirme gibi geliştirici eylemlerinin zamanını ve yapısını ve program kodu oluşturulurken oluşan hata mesajlarını kaydeder.

Günlük penceresi, diyagram penceresi alanındaki çalışma arayüzünde her zaman bulunur (Şekil 13). Ancak diğer diyagram pencereleri tarafından kapatılabilir veya küçültülebilir. Günlük penceresini Pencere-> Günlük menüsünden etkinleştirebilirsiniz. Bu durumda, çalışma arayüzünün sağ bölmesinde diğer pencerelerin üstünde görüntülenir. Bu pencere tamamen kaldırılamaz, yalnızca küçültülebilir.

Şekil - 13. Günlük penceresi görünümü

Çözüm

& nbsp & nbsp & nbsp & nbsp Zamanla, UML matematikçilerin, sistem analistlerinin, fizikçilerin, programcıların, yöneticilerin, ekonomistlerin ve diğer mesleklerden uzmanların iletişim kurabilecekleri ve mesleki bilgilerini birleşik bir biçimde sunabilecekleri "Esperanto" haline gelecektir. Sonuçta, özünde, uzmanların her biri kendi bilgi alanındaki model kavramlarla çalışır. Ve UML dili aracılığıyla belirlenebilen tam da bu model yönüdür.

& nbsp & nbsp & nbsp & nbsp Bu bağlamda, giderek bir bilgi temsil dilinin özelliklerini kazandığı için UML dilinin önemi önemli ölçüde artmaktadır. Aynı zamanda, UML'de bir modelin yapısını ve davranışını temsil etmek için resimli araçların varlığı, bildirimsel ve prosedürel bilginin yeterli bir temsilini elde etmeyi ve daha az önemli olmayan, bu formlar arasında anlamsal bir yazışma kurmayı mümkün kılar. bilgi. UML'nin tüm bu özellikleri, yakın gelecekte en ciddi beklentilere sahip olduğu sonucuna varmamızı sağlıyor.

Bu makale, yazılım geliştirmenin yeni çağını, bunun UML için yeni gereksinimler üzerindeki etkisini ve bunları yerine getirmek için en iyi uygulamaları incelemektedir.
& nbsp 7. "Rational Rose'da Veri Modelleme" Sergey Trofimov Rational Rose kullanılarak fiziksel veri temsilinin modellenmesini açıklar
& nbsp 8. UML dili. UML dilinin genel anlayışı: dilin yapıları, grafik öğeleri ve diyagramları.
& nbsp 9. Pratik UML. Bu belge, Practical UML'nin bir çevirisidir. Geliştiriciler için Uygulamalı Bir Giriş. Geliştiriciler için pratik bir giriş
& nbsp 10. "UML nesne yönelimli modellemenin standart dili" Vendrov Alexander Mihayloviç. UML'nin Tarihçesi
& nbsp 11. UML, birleşik bir modelleme dilidir. Bu materyal, UML'de kullanılan yazılım sistemlerini ve notasyonları tanımlama yöntemleri hakkında ilk bilgileri içerir.
& nbsp 12. UML dili. Kullanici rehberi. Grady Booch, James Rambeau, Ivar Jacobson
& nbsp 13. "Rational Rose'da UML diyagramları" Sergey Trofimov
& nbsp 14. "Analiz ve tasarım. Görsel modelleme (UML) Rational Rose" Konstantin Domolego
& nbsp 15. Gennady Vernikov Kütüphanesi. Tasarım ve modelleme standartlarının eksiksiz açıklamaları.
& nbsp 16. "Yazılım sistemlerinin geliştirilmesinde UML kullanan bir konu alanının açıklamasına bir örnek" Ye.B. Zolotukhina, R.V. Alfimov. Makale, Birleşik Modelleme Dilinin (UML) kullanımına dayalı etki alanı modellemeye yönelik olası bir yaklaşımın belirli bir örneğini göstermektedir.

& nbsp & nbsp & nbsp & nbsp

11.1. Birleşik Modelleme Dilinin Yapısı

Birleştirilmiş Modelleme Dili (UML) şu anda nesne yönelimli sistemlerin tasarım ve geliştirme sonuçlarının tanımlanması (belgelenmesi) için fiili standarttır. UML geliştirmesi, Rational Software'den Grady Booch ve James Rambeau tarafından 1994 yılında başladı. 1995 sonbaharında, Ivar Jacobson onlara katıldı ve aynı yılın Ekim ayında, Birleşik Yöntemin 0.8 ön sürümü yayınlandı. O zamandan beri, ikisi uluslararası standart statüsüne sahip olan UML spesifikasyonunun birkaç versiyonu yayınlandı:

UML 1.4.2 - "ISO / IEC 19501: 2005. Bilgi teknolojisi. Açık dağıtılmış işleme. Birleşik modelleme dili (UML). Sürüm 1.4.2" (İng. "Bilgi teknolojisi. Açık dağıtılmış işleme. Birleştirilmiş modelleme dili (UML). Sürüm 1.4.2 ");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Bilgi teknolojisi. OMG UML. Bölüm 1. Altyapı" (İng. "Bilgi teknolojisi - Nesne Yönetim Grubu Birleşik Modelleme Dili ( OMG UML) - Bölüm 1: Altyapı ") ve" ISO / IEC 19505-2: 2012. Bilgi teknolojisi. Birleşik Nesne Yönetimi Grubu Modelleme Dili (OMG UML). Bölüm 2. Üstyapı "(İng." Bilgi teknolojisi - Nesne Yönetim Grubu Birleşik Modelleme Dili (OMG UML) - Bölüm 2 : Üstyapı ").

En son resmi dil spesifikasyonu www.omg.org adresinde bulunabilir.

UML'nin genel yapısı aşağıdaki şekilde gösterilmiştir.

Pirinç. 11.1. UML yapısı

11.2. UML anlambilimi ve sözdizimi

anlambilim - dil birimlerinin anlamını, özellikle de kelimelerini ve kelime öbeklerini inceleyen bir dilbilim bölümü.

Sözdizimi - kelimeleri ve formlarını deyimler ve cümleler halinde birleştirme yolları, cümleleri karmaşık cümleler halinde birleştirme, metnin bir parçası olarak ifadeler oluşturma yolları.

Bu nedenle, UML'ye uygulandığı gibi, anlambilim ve sözdizimi, doğal ve biçimsel dilleri temel kavramları (model öğeleri) ve bunların uzantıları için mekanizmaları temsil etmek üzere birleştiren bir sunum stili (model oluşturma) tanımlar.

11.3. UML gösterimi

Notasyon, görsel sunumu için anlambilimin grafiksel bir yorumudur.

UML üç tanımlar varlık türü :

Yapısal - kavramsal veya fiziksel bir nesnenin yansıması olan bir soyutlama;

Gruplama - diyagram öğelerinin bazı anlamsal birleşimi için kullanılan bir öğe;

Açıklayıcı (açıklama) - bir diyagram öğesine bir yorum.

Aşağıdaki tablo, grafik gösterimde kullanılan ana varlıkların kısa bir tanımını ve bunları göstermenin ana yollarını sağlar.

Tablo 11.1. varlıklar

bir tip	İsim	atama	Tanım (anlambilim)
Yapısal	(sınıf)		Ortak bir yapı ve davranışa sahip birçok nesne
	(nesne)		Açıkça tanımlanmış kavramsal sınırları, bireyselliği (kimliği), durumu ve davranışı olan gerçek veya hayali bir varlığın soyutlaması. UML perspektifinden, nesneler sınıf örnekleridir (varlık örnekleri)
	(aktör)	Mühendis yol hizmetleri	Sistemle etkileşime giren ve işlevselliğini belirli hedeflere ulaşmak veya belirli sorunları çözmek için kullanan, sistemin dışında kalan bir varlık. Dolayısıyla aktör, harici bir bilgi kaynağı veya alıcısıdır.
	(kullanım durumu)		Aktör için önemli bir sonuca yol açan sistem tarafından gerçekleştirilen eylemlerin açıklaması
	(belirtmek, bildirmek)		Bir varlığın yaşamında belirli bir koşulu yerine getirdiği, bir faaliyette bulunduğu veya bir olayın gerçekleşmesini beklediği anın tanımı
	İşbirliği (işbirliği)		Belirli bir sorunu çözme sürecinde bir dizi aktör, nesne ve etkileşimlerinin tanımı
	(bileşen)		Tutarlı bir arabirimler kümesinin uygulanmasını sağlayan sistem modülleri dahil, sistemin (dosya) fiziksel kısmı
	(arayüz)	iHesaplama	Bir sınıf veya bileşen tarafından sağlanan bir hizmeti (hizmetler kümesini) tanımlayan bir dizi işlem
	(düğüm)		Sorunu çözmek için kaynaklar sağlayan sistemin fiziksel kısmı (bilgisayar, yazıcı vb.)
gruplama	(paket)		Elemanları gruplamak için genel mekanizma. Bir bileşenin aksine, paket tamamen kavramsal (soyut) bir kavramdır. Paketin özel durumları sistem ve modeldir.
	(parça)		Aktör ve nesne örnekleri arasındaki belirli etkileşim alanı
	(etkinlik bölümü)		Bir varlık (aktör, nesne, bileşen, düğüm vb.) tarafından gerçekleştirilen bir grup operasyon (sorumluluk alanı)
	(kesilebilir etkinlik bölgesi)		Standart olmayan bir durumun bir sonucu olarak normal dizisi kesintiye uğrayabilecek bir grup operasyon
açıklama	Not (yorum)		Öğe yorumu. Kesikli bir çizgi ile yorum yapılan öğeye eklenir

Bazı kaynaklarda, özellikle [,], davranışsal varlıklar da ayırt edilir. etkileşimler ve sonlu durum makineleri, ancak mantıksal bir bakış açısından, diyagramlar olarak sınıflandırılmalıdırlar.

Yukarıdaki varlıklardan bazıları, dolaylı olarak, ayrıştırma diyagramlarında ayrıntılı olarak açıklanmaktadır. Üst düzey diyagramda, özel bir simge veya etiketle işaretlenirler.

Aşağıdaki tablo, tüm türlerin bir açıklamasını sağlar ilişki Varlıklar arasındaki ilişkileri belirtmek için diyagramlarda kullanılan UML.

Tablo 11.3. İlişki

İsim	atama	Tanım (anlambilim)
bağlantı		İki veya daha fazla varlık arasındaki anlamlı ilişkiyi tanımlayan bir ilişki. En genel ilişki türü
Toplama		"Parça"nın "bütün"den ayrı olarak var olabileceği "parça" - "bütün" ilişkisini tanımlayan bir ilişkilendirme alt türü. Eşkenar dörtgen "bütün" tarafından gösterilir. İlişki yalnızca aynı türdeki varlıklar arasında gösterilir
Kompozisyon		"Parçaların" "bütün"den ayrı olarak var olamayacağı bir kümeleme alt türü. Kural olarak, "parçalar", "bütün" ile aynı anda yaratılır ve yok edilir.
Bağımlılık		Bir varlıktaki (bağımsız) bir değişikliğin başka bir varlığın (bağımlı) durumunu veya davranışını etkileyebileceği iki varlık arasındaki ilişki. Okun yanında bağımsız bir varlık gösterilir
genelleme		Genel bir varlık (ata, ebeveyn) ile özel bir varlık (alt, alt) arasındaki ilişki. Üçgen ebeveyn tarafından belirlenir. İlişki yalnızca aynı türdeki varlıklar arasında gösterilir
gerçekleştirme		Bir varlığın diğerinin gerçekleştirmeyi taahhüt ettiği bir eylemi tanımladığı, varlıklar arasındaki bir ilişki. İlişkiler iki durumda kullanılır: arayüzler ve sınıflar (veya bileşenler) arasında, kullanım durumları ve işbirlikleri arasında. Ok tarafı, eylemi tanımlayan varlığı gösterir (arayüz veya kullanım durumu)

İlişkilendirme için toplama ve kompozisyon belirtilebilir çokluk (İngilizce çokluğu), ilişkiye katılan varlıkların toplam örneklerinin sayısını karakterize eder. Genellikle ilgili varlığın yanında ilişkinin her iki tarafında belirtilir. Çokluk aşağıdaki şekillerde belirtilebilir:

- * - hiçbiri dahil olmak üzere herhangi bir sayıda kopya;

Negatif olmayan tam sayı - çokluk kesinlikle sabittir ve belirtilen sayıya eşittir (örneğin: 1, 2 veya 5);

Negatif olmayan tam sayıların aralığı "birinci sayı .. ikinci sayı" (örneğin: 1..5, 2..10 veya 0..5);

Belirli bir başlangıç ​​değerinden keyfi bir son "ilk sayı .. *" ye kadar bir sayı aralığı (örneğin: 1 .. *, 5 .. * veya 0 .. *);

Negatif olmayan tam sayıların ve virgülle ayrılmış aralıkların numaralandırılması (örneğin: 1, 3,5, 10, 15 .. *).

Çokluk belirtilmezse değeri 1 olarak kabul edilir. Bağımlılığa, genellemeye ve uygulamaya katılan varlık örneklerinin çokluğu her zaman 1 olarak kabul edilir.

Aşağıdaki tabloda açıklanmaktadır genişletmek için mekanizmalar varlıkların ve ilişkilerin anlamını netleştirmek için kullanılır. Genel olarak, uzatma mekanizması, parantez veya tırnak içine alınmış bir metin dizisidir.

Tablo 11.4. Uzatma mekanizmaları

İsim	atama	Tanım (anlambilim)
klişe (klişe)	« »	Bir gösterim öğesinin semantiğini belirten bir adlandırma (örneğin: "include" stereotipiyle bir bağımlılık, bir dahil etme ilişkisi olarak kabul edilir ve "sınır" stereotipiyle bir sınıf, bir sınır sınıfıdır)
Koruma durumu (koruma durumu)		Boole koşulu (örneğin: veya [tanımlama tamamlandı])
sınırlama (kısıtlama)	{ }	Model öğesinin anlamını sınırlayan kural (örneğin, (yürütme süresi 10 ms'den az))
etiketli değer (etiketli değer)	{ }	Bir gösterim öğesinin yeni veya niteleyici özelliği (örneğin: (sürüm = 3.2))

Tırnak içinde metin dizisi olarak gösterilen kalıp yargılara ek olarak, çizelgelerde grafik kalıp yargılar kullanılabilir. Aşağıdaki şekil, standart ve basmakalıp gösterim örneklerini göstermektedir.

a) standart atama		b) standart atama metin klişesi ile		c) grafik klişe

Pirinç. 11.2. Standart ve kalıplaşmış sınıf gösterimi örnekleri

Diyagram geliştirilmekte olan bilgi sisteminin bazı yönlerini temsil etmek için notasyon öğelerinin bir grubudur. Diyagramlar genellikle varlıkların köşeler ve ilişkilerin yaylar olduğu bağlantılı bir grafiktir. Aşağıdaki tablo, UML diyagramlarının kısa bir açıklamasını sağlar.

Tablo 11.5. diyagramlar

Diyagram			Randevu
				fiziksel gerçekleşme derecesine göre	dinamikleri görüntüleyerek	görüntülenen açıdan
(kullanım durumu)			Sistem işlevlerini, aktörler ve işlevler arasındaki etkileşimi görüntüler	Mantıklı	Statik	fonksiyonel
(sınıf)			Bir dizi sınıfı, arabirimi ve aralarındaki ilişkileri görüntüler.	Mantıksal veya fiziksel	Statik	İşlevsel ve bilgilendirici
(paket)			Bir dizi paketi ve aralarındaki ilişkiyi görüntüler	Mantıksal veya fiziksel	Statik	Bileşen
Davranış (davranış)	(durum makinesi)		Bir varlığın durumlarını ve yaşam döngüsü boyunca aralarındaki geçişleri görüntüler	Mantıklı	Dinamik	Davranışsal
	(aktivite)		Sistemdeki iş süreçlerini görüntüler (davranış algoritmalarının açıklaması)
	Etkileşimler (etkileşim)	(sıra)	Nesneler ve aktörler arasında geçen mesajların sırasını görüntüler
		(iletişim)	Sıra diyagramına benzer, ancak vurgu, nesneler arasındaki etkileşimlerin yapısı üzerindedir.
uygulama (uygulama)	(bileşen)		Sistem bileşenlerini (programlar, kitaplıklar, tablolar vb.) ve bunlar arasındaki bağlantıları görüntüler.	Fiziksel	Statik	Bileşen
	(dağıtım)		Bileşenlerin ana bilgisayarlara göre yerleşimini ve yapılandırmasını görüntüler

UML 2.x standardı ayrıca ek, oldukça özel diyagramlar tanımlar:

Nesne diyagramı benzerdir, ancak sınıflar yerine nesneler görüntülenir;

Zamanlama diyagramı - bir nesnenin zaman içindeki durumunu tanımlar;

Bileşik yapı şeması - diğer sınıflarla etkileşim için bir sınıfın bağlantı noktalarını (arayüzler dahil) tanımlar;

Profil şeması - bunlara dahil olan sınıfların açıklamasına benzer;

Etkileşime genel bakış diyagramı benzerdir, ancak gizli etkileşim parçalarına sahiptir (ref etiketli parçalar). Bu, öğeleri ayrı ayrışım diyagramlarında somutlaştırılacak olan bağlamsal (kavramsal) bir öğedir.

Sistemin iç mimarisinin genişletilmiş bir kavramsal temsili amacıyla, yapının çoğu, sözde için yerleşik grafik stereotiplerin kullanımına izin verir. Böyle bir diyagram 1 olarak adlandırılır, ancak UML standardı tarafından tanımlanan diyagram listesine ait değildir.

Sistemin ayrı bir modelini geliştirirken, birkaç tür diyagram oluşturulur. Ayrıca, karmaşık bir sistemin bir modelini geliştirirken, kural olarak, aynı türden birkaç diyagram oluşturulur. Aynı zamanda, gerekli değilse, ayrı diyagram türleri oluşturmamak da mümkündür. Örneğin, diyagramlar ve birbirleriyle değiştirilebilirler; yalnızca karmaşık davranışa sahip nesneler için oluşturulurlar. Aşağıdaki tablo, sistem modeline göre diyagramlar geliştirme (iyileştirme) ihtiyacı hakkında rehberlik sağlar.

Tablo 11.6. Modelleri ve Diyagramları Bağlama

Tablo, test modelini göstermez, çünkü yapısı çerçevesinde diyagramlar geliştirilmez, ancak eksiksizlik ve tutarlılık açısından kontrol edilir (test edilir).

Şemaların inşasından sonra bir kısmı, bir sonraki modelin (teknolojik süreç) geliştirilmesi çerçevesinde geliştirme ve iyileştirme gerektirir. Bu nedenle, örneğin, geliştirme sırasında açıklığa kavuşturulmalıdır. Modellerde.

4. "" kavramına bir tanım verin.

UML, Birleşik Modelleme Dilinin kısaltmasıdır. Aslında, en popüler iş süreci modelleme tekniklerinden biridir ve yazılım geliştirmeyi belirtmek, görselleştirmek ve belgelemek için uluslararası bir standart gösterimdir. Nesne Yönetim Grubu tarafından tanımlanan, birkaç ek UML notasyon sisteminin bir sonucu olarak ortaya çıktı ve şimdi görsel modelleme için fiili standart haline geldi. Herhangi bir nesne yönelimli programlamanın temel ilkesi, bir model oluşturmakla başlar.

UML, yazılım geliştirme ve dokümantasyon etrafındaki kaostan yaratıldı. 1990'larda, yazılım sistemlerini temsil etmenin birkaç farklı yolu vardı. Bu sistemleri temsil etmek için daha birleşik bir görsel UML yöntemine ihtiyaç vardı ve sonuç olarak 1994-1996 yıllarında Rational Software'de çalışan üç yazılım mühendisi tarafından geliştirildi. Daha sonra 1997'de bir standart olarak kabul edildi ve sadece birkaç güncellemeyle öyle kaldı.

Temel olarak UML, yazılım geliştirme alanında genel amaçlı bir modelleme dilidir. Ancak, artık etkinlik diyagramları gibi çeşitli iş veya iş akışı süreçlerinin belgelerine yansıtılmaktadır. UML tipi diyagramlar, akış şemalarının yerine kullanılabilir. Hem iş akışlarını modellemek için daha standart bir yol hem de okunabilirliği ve verimliliği artırmak için çok çeşitli özellikler sunarlar.

Mimari, UML'nin oluşturulmasının temelini tanımlayan bir meta-nesneye dayanmaktadır. Tüm bir uygulama oluşturmak için yeterince doğrudur. Tamamen yürütülebilir UML, yazılım geliştirme döngüsü boyunca tüm süreçlerle farklı teknolojiler kullanarak birden çok platformda konuşlandırılabilir.

UML, kullanıcılar tarafından görsel bir modelleme dilinin geliştirilmesi için tasarlanmıştır. Yapılar, şablonlar ve işbirliği gibi üst düzey tasarım kavramlarını destekler. UML, aşağıdakiler gibi bir öğeler topluluğudur:

1. Programlama dili ifadeleri.
2. Aktörler - kullanıcının veya nesneyle etkileşime giren diğer herhangi bir sistemin oynadığı rolü tanımlar.
3. İş sözleşmesinin ifası için yapılacak faaliyetler ve diyagramlar halinde sunulmuştur.
4. Müşteriler için belirli bir hizmet oluşturan, sıralı eylemlerin bir akış şemasıyla görselleştirilen bir dizi görevi içeren bir iş süreci.
5. Mantıksal ve yeniden kullanılabilir yazılım bileşenleri.

UML diyagramları iki kategoriye ayrılır. İlk tür, yapısal bilgileri temsil eden yedi tür diyagramı içerir, ikincisi, yaygın davranış türlerini temsil eden diğer yedi tür diyagramı içerir. Bu diyagramlar, sistemlerin mimarisini belgelemek için kullanılır ve doğrudan UML sistem modellemesine dahil olur.

UML diyagramları, sistem modelinin statik ve dinamik görünümleri olarak sunulur. Statik görünüm, statik yapıyı vurgulayan sınıf ve bileşik yapı diyagramlarını içerir. Dinamik bir görünüm, nesneler arasındaki etkileşimi ve sıra, etkinlik ve durum diyagramlarını kullanarak nesnelerin iç durumlarındaki değişiklikleri temsil eder.

IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner ve Dia dahil olmak üzere modellemeyi basitleştirmek için çok çeşitli UML modelleme araçları mevcuttur.

UML, hem yazılım geliştirme belgelerinde hem de iş süreçlerinde farklı şekillerde kullanılır:

1. Eskiz. Bu durumda, sistemin çeşitli yönlerini ve özelliklerini iletmek için UML diyagramları kullanılır. Ancak bu, sistemin yalnızca üst düzey bir görünümüdür ve büyük olasılıkla projeyi sonuna kadar taşımak için gerekli tüm ayrıntıları içermeyecektir.
2. İleri Tasarım - Uygulamanın kodlanmasından önce eskizin tasarımı yapılır. Bu, kullanıcının oluşturmaya çalıştığı sisteme veya iş akışına daha iyi bir genel bakış sağlamak içindir. Projenin genel sağlığını ve iyiliğini iyileştirecek birçok tasarım sorunu veya kusuru belirlenebilir.
3. Ters tasarım. Kod yazıldıktan sonra, UML diyagramları farklı etkinlikler, roller, katılımcılar ve iş akışları için bir belge biçimi olarak görünür.
4. Taslak. Bu durumda diyagram, yalnızca sistemin veya yazılımın fiili olarak uygulanmasını gerektiren eksiksiz bir yapı görevi görür. Bu genellikle CASE (Bilgisayar Destekli Yazılım Mühendisliği Araçları) araçları kullanılarak yapılır. CASE araçlarını kullanmanın ana dezavantajı, belirli bir düzeyde bilgi, kullanıcı eğitimi, yönetim ve personel gerektirmeleridir.

UML, Java, C ++ veya Python gibi bağımsız bir programlama dili değildir, ancak doğru araçlarla sözde bir UML olabilir. Bu amaca ulaşmak için tüm sistemin farklı diyagramlarda belgelenmesi gerekir ve doğru yazılım kullanılarak diyagramlar doğrudan koda çevrilebilir. Bu teknik, yalnızca çizelgeleri çizmek için harcanan zaman, gerçek kodu yazmaktan daha az zaman alıyorsa faydalı olabilir. UML, sistem modellemesi için oluşturulmuş olmasına rağmen, iş alanlarında birçok kullanım alanı bulmuştur.

Aşağıda iş modelleme için örnek bir UML diyagramı verilmiştir.

Pratik bir çözüm, telesatışlar için süreç akışını bir aktivite diyagramı aracılığıyla görselleştirmek olabilir. Siparişin girdi olarak alındığı andan siparişin tamamlanıp belirli bir çıktının verildiği ana kadar.

Birkaç UML diyagramı türü vardır ve her biri, ister uygulamadan önce ister uygulamadan sonra geliştirilsin, belgelerin bir parçası olarak farklı bir görevi yerine getirir. Diğer tüm türleri kapsayan en geniş iki kategori, davranış diyagramı ve yapı diyagramıdır. Adından da anlaşılacağı gibi, bazı UML diyagramları bir sistemin veya sürecin yapısını analiz etmeye ve tasvir etmeye çalışırken, diğerleri bir sistemin davranışını, katılımcılarını ve bileşenlerini tanımlar.

Farklı türler aşağıdaki gibi ayrılır:

1. 14 farklı UML diyagramının tümü, sistemler ve mimariler belgelenirken düzenli olarak kullanılmaz.
2. Pareto ilkesi, UML diyagramlarının kullanımı için de geçerlidir.
3. Grafiklerin %20'si, zamanın %80'inde geliştiriciler tarafından kullanılır.

Yazılım geliştirmede en sık kullanılan öğeler şunlardır:

• kullanım şemaları;
• sınıf diyagramları;
• sıra.

Eylem diyagramları, iş süreci modelleri oluşturmak için en önemli UML diyagramlarıdır. Yazılım geliştirmede, farklı eylemlerin akışını tanımlamak için kullanılırlar. Sıralı veya paralel olabilirler. Faaliyetler sonucunda kullanılan, tüketilen veya üretilen nesneleri ve farklı faaliyetler arasındaki ilişkiyi tanımlarlar.

Yukarıdakilerin tümü, net bir başlangıç ​​ve bitiş ile birbirine bağlı olduklarından, birinden diğerine giden iş süreçlerini modellemek için önemlidir. Bir iş ortamında buna iş süreci eşlemesi de denir. Baş aktörler yazar, editör ve yayıncıdır. UML örnekleri aşağıdakileri içerir. Gözden geçiren kişi taslağı inceleyip bazı değişikliklerin yapılması gerektiğine karar verdiğinde. Yazar daha sonra taslağı gözden geçirir ve genel bakışı analiz etmek için tekrar verir.

kullanım şeması

Sistemin temel taşı - sistem düzeyi için gereksinimleri analiz etmek için kullanılır. Bu gereksinimler farklı kullanım durumlarında ifade edilir. Bir UML diyagramının üç ana bileşeni şunlardır:

1. İşlevsel - kullanım durumları olarak sunulur.
2. Bir eylemi anlatan fiil.
3. Aktörler - sistemle etkileşime geçmek için. Aktör, kullanıcılar, kuruluşlar veya harici bir uygulama olabilir. Katılımcılar arasındaki ilişki düz oklarla temsil edilir.

Örneğin, bir envanter kontrol çizelgesi için. Bu durumda bir mal sahibi, bir tedarikçi, bir yönetici, bir envanter uzmanı ve bir envanter denetçisi vardır. Yuvarlak kaplar, aktörlerin gerçekleştirdiği eylemleri temsil eder. Olası eylemler arasında hisse senedi satın almak ve ödeme yapmak, stokların kalitesini kontrol etmek, stokları iade etmek veya bunları dağıtmak yer alır.

Bu tür diyagram, bir sistemdeki katılımcılar arasındaki dinamik davranışı görüntülemek için çok uygundur ve uygulama ayrıntılarını yansıtmadan sunumunu basitleştirir.

Geçici

UML zamanlama diyagramları, odak zamana bağlı olduğunda nesne ilişkilerini temsil etmek için kullanılır. Aynı zamanda, nesnelerin nasıl etkileşime girdiği veya birbirini nasıl değiştirdiği ilginç değil, ancak kullanıcı nesnelerin ve öznelerin doğrusal bir zaman ekseni boyunca nasıl hareket ettiğini hayal etmek istiyor.

Her bir katılımcı, bir aşamadan diğerine geçerken, esasen aşamaları oluşturan bir çizgi olan bir yaşam çizgisi aracılığıyla temsil edilir. Olayların süresi ve buna bağlı olarak meydana gelen değişiklikler üzerinde durulmuştur.

Bir zamanlama çizelgesinin ana bileşenleri şunlardır:

1. Lifeline bireysel bir üyedir.
2. Durum Zaman Çizelgesi - Tek bir yaşam yolu, bir süreç içinde çeşitli durumlardan geçebilir.
3. Süre kısıtlaması - Kısıtlamanın karşılanması için gereken süreyi temsil eden bir zaman aralığı kısıtlaması.
4. Zaman sınırı - katılımcı tarafından bir şey yapılması gereken zaman aralığını sınırlayın.
5. Yıkım Görünümü - Bireysel bir katılımcıyı yok eden ve o katılımcının yaşam döngüsünün sonunu gösteren bir mesajın görünümü.

Durum diyagramları olarak da adlandırılan yatay diyagramlar, bir sistem içindeki bir bileşenin çeşitli durumlarını tanımlamak için kullanılır. Bir diyagram esasen bir nesnenin birden çok durumunu ve dahili ve harici olaylara göre nasıl değiştiğini açıklayan bir makine olduğu için bir son ad biçimi alır.

Bir satranç oyununda çok basit bir makine durum diyagramı olacaktır. Tipik bir satranç oyunu, Beyaz tarafından yapılan hamlelerden ve Siyah tarafından yapılan hamlelerden oluşur. Beyazın ilk hamlesi vardır ve bu da oyunu başlatır. Oyunun sonu, Beyaz veya Siyahın kazanmasına bakılmaksızın gerçekleşebilir. Oyun bir maç, istifa veya berabere bitebilir (farklı makine koşulları). Durum çizelgeleri temel olarak çeşitli sistemlerin ileri ve geri UML tasarımında kullanılır.

Ardışık

Bu diyagram türü, yalnızca bilgisayar bilimi topluluğu arasında değil, aynı zamanda iş uygulamaları geliştirmek için bir tasarım katmanı modeli olarak da en önemli UML diyagramıdır. Görsel olarak açıklayıcı yapıları nedeniyle iş süreçlerini tanımlamak için popülerdirler. Adından da anlaşılacağı gibi, diyagramlar, özneler ve nesneler arasında meydana gelen mesajların ve etkileşimlerin sırasını tanımlar. Aktörler veya nesneler, yalnızca gerektiğinde veya başka bir nesne onlarla iletişim kurmak istediğinde etkin olabilir. Tüm iletişimler kronolojik sırayla sunulur.

Daha fazla bilgi için aşağıdaki örnek UML dizi şemasına bakın.

Örnekte gösterildiği gibi, bir sistemin yapısını göstermek için yapı diyagramları kullanılır. Daha spesifik olarak, yazılım geliştirmede bir sistemin mimarisini ve farklı bileşenlerin birbirine nasıl bağlı olduğunu temsil etmek için bir dil kullanılır.

UML sınıf diyagramı, yazılım dokümantasyonu için en yaygın diyagram türüdür. Şu anda yazılmakta olan programların çoğu hala nesne yönelimli programlama paradigmasına dayandığından, yazılımı belgelemek için sınıf diyagramlarını kullanmak mantıklıdır. Bunun nedeni, OOP'nin UML sınıflarına ve aralarındaki ilişkilere dayanmasıdır. Özetle, grafikler, veri alanları olarak da adlandırılan öznitelikleri ve üye işlevler olarak adlandırılan davranışlarıyla birlikte sınıfları içerir.

Daha spesifik olarak, her sınıfın 3 alanı vardır: üstte ad, adın hemen altında nitelikler, altta işlemler / davranış. Çeşitli sınıflar arasındaki ilişki (bağlantı hattı ile temsil edilir) bir sınıf diyagramı oluşturur. Yukarıdaki örnek, temel bir sınıf diyagramını göstermektedir.

nesneler

UML yapısal diyagramlarını tartışırken, bilgisayar bilimi kavramlarını daha derinlemesine incelemeniz gerekir. Yazılım geliştirmede sınıflar soyut veri türleri, nesneler ise örnek olarak kabul edilir.Örneğin, genel bir soyut tür olan “Car” varsa, “Car” sınıfının bir örneği “Audi” olacaktır.

UML nesne diyagramları, yazılım geliştiricilerin, oluşturulan soyut yapının pratikte uygulandığında, yani nesneler oluşturulduğunda uygulanabilir bir yapı olup olmadığını kontrol etmesine yardımcı olur. Bazı geliştiriciler, bunun ikincil bir doğruluk doğrulama düzeyi olduğunu düşünüyor. Sınıfların örneklerini görüntüler. Daha doğrusu, "Müşteri" genel sınıfının artık örneğin "James" adında gerçek bir müşterisi var. James daha genel bir sınıfın bir örneğidir ve verilen değerlerle aynı niteliklere sahiptir. Aynı şey Hesaplar ve Birikimler hesabı için de yapıldı. Her ikisi de kendi sınıflarının nesneleridir.

dağıtım

Dağıtım diyagramları, yazılım ve donanım arasındaki ilişkiyi görselleştirmek için kullanılır. Daha açık olmak gerekirse, dağıtım diyagramlarıyla, yazılım bileşenlerinin (yapıların) düğümler olarak bilinen donanım bileşenlerinde nasıl dağıtıldığına dair fiziksel bir model oluşturabilirsiniz.

Bir web uygulaması için tipik bir basitleştirilmiş dağıtım modeli şunları içerir:

1. Düğümler (uygulama sunucusu ve veritabanı sunucusu).
2. Artifacts istemci uygulama şeması ve veritabanı.

Paket diyagramı, yukarıda açıkladığımız UML dağıtım diyagramları için makrolara benzer. Çeşitli paketler, düğümler ve yapılar içerir. Diyagramları ve model bileşenlerini gruplar halinde gruplandırırlar, tıpkı bir ad alanının bir şekilde ilişkili olan farklı adları içine alması gibi. Sonuç olarak, daha karmaşık sistemleri ve davranışları temsil etmek için birkaç başka paket tarafından da bir paket oluşturulabilir.

Bir paket diyagramının temel amacı, karmaşık bir sistemi oluşturan çeşitli ana bileşenler arasındaki ilişkileri göstermektir. Programcılar, bu soyutlama özelliğini, özellikle ayrıntılar resmin dışında bırakılabildiğinde, paket diyagramlarını kullanmak için iyi bir avantaj olarak görmektedir.

Hayattaki diğer her şey gibi, bir şeyi doğru yapmak da doğru araçları gerektirir. Yazılımları, süreçleri veya sistemleri belgelemek için UML ek açıklamaları ve diyagram şablonları sunan araçları kullanın. Bir diyagram çizmenize yardımcı olabilecek çeşitli yazılım belgeleme araçları vardır.

Genellikle aşağıdaki ana kategorilere girerler:

1. Kağıt ve kalem kolaydır. Kağıt kalem alırlar, internetten UML sözdizimi kodunu açarlar ve ihtiyaç duyulan her türlü diyagramı çizerler.
2. Çevrimiçi Araçlar - Grafiğinizi oluşturmak için kullanabileceğiniz birkaç çevrimiçi uygulama vardır. Çoğu, ücretli bir abonelik veya sınırlı sayıda ücretsiz katman çizelgesi sunar.
3. Ücretsiz çevrimiçi araçlar, ücretli araçlarla neredeyse aynıdır. Temel fark, ücretli olanların ayrıca belirli grafikler için öğreticiler ve hazır şablonlar sunmasıdır.
4. Bir masaüstü uygulaması, diyagramlar için kullanılacak tipik bir masaüstü uygulamasıdır ve hemen hemen tüm diğer diyagramlar Microsoft Visio'dur. Gelişmiş özellikler ve işlevsellik sunar. Tek dezavantajı, bunun için ödeme yapmanız gerektiğidir.

Bu nedenle, UML'nin nesne yönelimli yazılımın geliştirilmesiyle ilişkili önemli bir yönü olduğu oldukça açıktır. Sistem programlarının görsel modellerini oluşturmak için grafik gösterimi kullanır.

UML, OO sistemlerini tanımlamak, görselleştirmek, tasarlamak ve belgelemek için birleşik bir grafik modelleme dilidir. UML, OO yaklaşımına dayalı olarak yazılım sistemlerinin modellenmesi sürecini desteklemek, kavramsal ve yazılım kavramları arasındaki ilişkiyi düzenlemek, karmaşık sistemleri ölçekleme problemlerini yansıtmak için tasarlanmıştır. UML'deki modeller, iş analizinden sistem bakımına kadar yazılım sistemi yaşam döngüsünün tüm aşamalarında kullanılır. Farklı kuruluşlar, sorun alanlarına ve kullanılan teknolojilere bağlı olarak UML'yi uygun gördükleri şekilde uygulayabilirler.

UML'nin kısa bir tarihi

90'ların ortalarında, çeşitli yazarlar tarafından, her biri kendi grafik gösterimini kullanan birkaç düzine OO modelleme yöntemi önerildi. Aynı zamanda, bu yöntemlerden herhangi birinin güçlü yönleri vardı, ancak "her taraftan", yani gerekli tüm projeksiyonları gösteren yeterince eksiksiz bir PS modeli oluşturmaya izin vermedi (bkz. Madde 1). Ek olarak, bir OO modelleme standardının olmaması, geliştiricilerin en uygun yöntemi seçmesini zorlaştırdı ve bu da OO yaklaşımının yazılım geliştirmede yaygın olarak kullanılmasını engelledi.

Nesne teknolojileri ve veritabanları alanındaki standartların benimsenmesinden sorumlu kuruluş olan Nesne Yönetim Grubu'nun (OMG) talebi üzerine, acil birleştirme ve standardizasyon sorunu, en popüler üç OO yönteminin yazarları tarafından çözüldü - G Buch, D. Rambo ve A. Jacobson, OMG tarafından 1997 yılında bir standart olarak onaylanan UML 1.1'i oluşturdu.

UML bir dildir

Herhangi bir dil, anlamlı yapılar elde etmek için kelimeleri birleştirmek için bir kelime dağarcığı ve kurallardan oluşur. Bu nedenle, özellikle programlama dilleri düzenlenmiştir, UML gibi. Ayırt edici özelliği, dil sözlüğünün grafik öğelerden oluşmasıdır. Her grafik sembolün belirli bir semantiği vardır, bu nedenle bir geliştirici tarafından oluşturulan bir model, UML'yi yorumlayan bir yazılım aracının yanı sıra bir başkası tarafından açık bir şekilde anlaşılabilir. Bundan özellikle, UML'de sunulan bir PS modelinin, UML'yi destekleyen iyi bir görsel modelleme aracı varsa, otomatik olarak bir OO programlama diline (Java, C ++, VisualBasic gibi) çevrilebileceğini izler. , modeli oluştururken, bu modele karşılık gelen program kodunun bir hazırlığını alacağız.

UML'nin bir metot değil bir dil olduğu vurgulanmalıdır. Hangi öğelerden model oluşturulacağını ve bunların nasıl okunacağını açıklar, ancak hangi modellerin ve hangi durumlarda geliştirilmesi gerektiği hakkında hiçbir şey söylemez. UML'ye dayalı bir yöntem oluşturmak için, onu yazılım geliştirme sürecinin bir açıklamasıyla desteklemek gerekir. Böyle bir sürecin bir örneği, sonraki makalelerde tartışılacak olan Rasyonel Birleşik Süreç'tir.

UML kelime dağarcığı

Model, diyagramlarda gösterilen varlıklar ve aralarındaki ilişkiler şeklinde temsil edilir.

varlıklar Modellerin ana unsurları olan soyutlamalardır. Dört tür varlık vardır - yapısal (sınıf, arayüz, bileşen, kullanım durumu, işbirliği, düğüm), davranışsal (etkileşim, durum), gruplama (paketler) ve açıklama (yorumlar). Her varlık türünün kendi grafik temsili vardır. Diyagramlar incelenirken varlıklar ayrıntılı olarak tartışılacaktır.

İlişki varlıklar arasında çeşitli ilişkiler gösterir. UML, aşağıdaki ilişki türlerini tanımlar:

• Bağımlılık iki varlık arasında böyle bir bağlantı gösterir, birini değiştirirken - bağımsız - diğerinin anlamını etkileyebilir - bağımlı. Bağımlılık, bağımlı varlıktan bağımsız varlığa işaret eden kesikli bir okla gösterilir.
• bağlantı Bir varlıktaki nesnelerin başka bir varlıktaki nesnelerle ilişkili olduğunu gösteren yapısal bir ilişkidir. Bir ilişki, bağlantılı varlıkları birbirine bağlayan bir çizgi olarak grafiksel olarak gösterilir. İlişkilendirmeler nesneler arasında gezinmek için kullanılır. Örneğin, "Sipariş" ve "Ürün" sınıfları arasındaki ilişki, bir yandan belirli bir siparişte belirtilen tüm malları bulmak için, diğer yandan belirli bir ürünün bulunduğu tüm siparişleri bulmak için kullanılabilir. . İlgili programların bu tür navigasyon için bir mekanizma uygulaması gerektiği açıktır. Gezinmek için yalnızca bir yön gerekiyorsa, ilişkilendirmenin sonunda bir okla gösterilir. Bir birlikteliğin özel bir durumu, toplamadır - "bütün" - "parça" biçimindeki bir ilişki. Grafik olarak, varlık-bütünün yanında, sonunda bir elmas ile vurgulanır.
• genelleme Bir üst varlık ile bir alt varlık arasındaki ilişkidir. Esasen bu ilişki, sınıflar ve nesneler için kalıtım özelliğini yansıtır. Genelleme, ebeveyn varlığı gösteren bir üçgen ile biten bir çizgi olarak gösterilir. Çocuk, ebeveynin yapısını (niteliklerini) ve davranışını (yöntemlerini) devralır, ancak aynı zamanda yeni yapı üyelerine ve yeni yöntemlere sahip olabilir. UML, bir varlık birden fazla üst varlıkla ilişkilendirildiğinde birden çok kalıtıma izin verir.
• uygulama- davranışın belirtimini (arayüz) tanımlayan varlık ile bu davranışın uygulamasını tanımlayan varlık (sınıf, bileşen) arasındaki ilişki. Bu ilişki, bileşen modellemede yaygın olarak kullanılır ve sonraki makalelerde daha ayrıntılı olarak açıklanacaktır.

Diyagramlar. UML aşağıdaki diyagramları sağlar:

• Sistem davranışını açıklayan diyagramlar:
• Durum diyagramları,
• Aktivite diyagramları,
• Nesne diyagramları,
• Sıra diyagramları,
• İşbirliği diyagramları
• Sistemin fiziksel uygulamasını açıklayan diyagramlar:
• Bileşen diyagramları
• Dağıtım şemaları

Model kontrol görünümü. Paketler.

Bir modelin bir kişi tarafından iyi anlaşılması için, hiyerarşinin her seviyesinde az sayıda varlık bırakarak hiyerarşik olarak organize edilmesi gerektiğini zaten söylemiştik. UML, bir modelin hiyerarşik bir temsilini organize etmenin bir yolunu içerir - paketler. Herhangi bir model, sınıfları, kullanım durumlarını ve diğer varlıkları ve diyagramları içerebilen bir dizi paketten oluşur. Bir paket, hiyerarşiler oluşturmak için başka paketler içerebilir. UML'de ayrı paket diyagramları yoktur, ancak diğer diyagramlarda görünebilirler. Paket, sekmeli bir dikdörtgen olarak görüntülenir.

UML'nin sağladıkları.

• paketleri tahsis ederek karmaşık bir sistemin hiyerarşik bir açıklaması;
• kullanım durumları aparatını kullanarak sistem için fonksiyonel gereksinimlerin resmileştirilmesi;
• faaliyet ve senaryo şemaları oluşturarak sistem gereksinimlerinin detaylandırılması;
• veri sınıflarını vurgulama ve sınıf diyagramları şeklinde kavramsal bir veri modeli oluşturma;
• kullanıcı arayüzünü tanımlayan sınıfların vurgulanması ve bir ekran navigasyon şeması oluşturulması;
• sistem işlevlerini yerine getirirken nesnelerin etkileşim süreçlerinin açıklaması;
• nesnelerin davranışlarının aktivite ve durum diyagramları şeklinde tanımlanması;
• yazılım bileşenlerinin tanımı ve arayüzler aracılığıyla etkileşimleri;
• sistemin fiziksel mimarisinin bir açıklaması.

Ve son...

UML'nin tüm çekiciliğine rağmen, görsel modelleme araçları olmadan gerçek yazılım modellemesinde kullanmak zor olacaktır. Bu tür araçlar, diyagramları ekranda hızlı bir şekilde sunmanıza, bunları belgelemenize, çeşitli OO programlama dillerinde boş program kodları oluşturmanıza ve veritabanı şemaları oluşturmanıza olanak tanır. Bunların çoğu, program kodlarını yeniden yapılandırma olasılığını içerir - modelin ve kodların tutarlılığını sağlamak için çok önemli olan programların kaynak kodlarını otomatik olarak analiz ederek SS modelinin belirli projeksiyonlarını geri yüklemek ve öncekinin işlevselliğini devralan sistemler tasarlarken sistemler.

Bir nesnenin yaşamı boyunca, nesnenin yaratılmasından yok edilmesine kadar olan davranışını gösterin. Her durum diyagramı bir çeşit otomat temsil eder.

Hareket planı

Açıklama bölümünde, diyagramları okuyabilmeniz için ihtiyaç duyduğunuz temel durum çizelgesi sembollerini keşfedin.

Diğer bölümleri (Örnek, Uygulama) okuduktan sonra, durum diyagramlarını kendiniz çizmeyi deneyebilirsiniz.

Notlar (açıklama)

Bu temel karakter seti durum diyagramları diyagramı okuyabilmek için gereklidir. Diğer bölümleri ("Örnek", "Uygulama") okuduktan sonra, oluşturabileceksiniz. durum diyagramları kendi başına!

Terim	resim	Açıklama
İlk sözde durum		Sistemin ilk durumu
Geçiş		Geçiş, bir durumdan diğerine geçmek anlamına gelir.
Belirtmek, bildirmek		Aktörlerin gözlemlenen sonuçlarına yol açan sistem tarafından gerçekleştirilen eylemleri (seçenekleri içerebilir) gösterir.
Belirtmek, bildirmek aktivite durumu		Bir kullanım durumundaki karmaşık bir adım, başka bir kullanım durumu ile temsil edilebilir. UML terimleriyle, ilk kullanım durumunun ikinciyi içerdiğini söylüyoruz.
Son durum		Sistemlerin veya alt sistemlerin sınırlarını tanımlamanıza olanak tanır.
Dahili faaliyetler		Devletlerin geçiş yapmadan olaylara tepki verebildiği durum, bu durumda olay, koruma ve faaliyetin durum dikdörtgeni içine yerleştirilmesi.
Giriş Etkinliği		Giriş etkinliği, duruma her girdiğinizde yürütülür
Çıktı Etkinliği		Çıkış Etkinliği - Eyaletten her ayrıldığınızda yürütülür.
süper devlet		Çoğu durumda, birkaç devletin ortak geçişleri ve dahili faaliyetleri vardır. Bu gibi durumlarda, onları alt durumlara dönüştürebilir ve genel davranışı bir üst duruma taşıyabilirsiniz.
paralel durumlar		Durumlar, aynı anda çalışan birden fazla eşzamanlı duruma bölünebilir.

Yaratıcılık tekniği nasıl uygulanır?

UML durum diyagramları, birden çok kullanım durumunda tek bir nesnenin davranışını açıklamak için iyidir. Ancak birçok nesnenin etkileşimi ile karakterize edilen davranışı tanımlamak için pek uygun değildirler. Bu nedenle, durum diyagramları ile birlikte diğer teknolojileri kullanmak mantıklıdır. Örneğin, etkileşim diyagramları (Bölüm 4), tek bir kullanım durumunda birden çok nesnenin davranışını ve UML etkinlik diyagramlarını mükemmel bir şekilde tanımlar. birden çok kullanım durumunda birden çok nesnenin temel akışını göstermek için iyidir.

Herkes durum haritalarını doğal olarak görmez. Uzmanların onlarla nasıl çalıştığını izleyin. Ekip üyelerinizin durum çizelgelerinin kendi çalışma tarzları için doğru olmadığını düşünmeleri mümkündür. Bu en büyük zorluk değil; farklı çalışma tekniklerini paylaşmayı unutmamalısınız.

Durum diyagramları kullanıyorsanız, sistemin her sınıfı için bunları çizmeye çalışmayın. Bu yaklaşım genellikle resmi olarak katı bir bütünlük sağlamak için kullanılır, ancak neredeyse her zaman bir enerji kaybıdır. Durum çizelgelerini yalnızca ilginç davranışlar sergileyen sınıflar için kullanın; burada bir durum çizelgesi oluşturmanın işlerin nasıl gittiğini anlamanıza yardımcı olduğu.

Birçok uzman buna inanıyor UI düzenleyicisi ve kontrolleri, bir durum çizelgesi kullanılarak görüntülendiğinde yararlı olan işlevselliğe sahiptir.

Nasıl ögrenilir

Burada, öğrenmenin mümkün olduğu kadar basit bir yolunu sağlamaya çalıştık. UML durum diyagramları.

Diğer birçok dilde olduğu gibi, onu tanımlamak için bir dizi karakter kullanır. Bu sembollerin anlamı, "Açıklamalar (açıklama)" bölümündeki tabloda bulunabilir. Her işaretin kendi adı (terimi) ve yazılışı vardır. Ayrıca, ana özünü hızlı bir şekilde anlamak için her terime kısa bir açıklama verilmiştir.

Ayrıca, "Örnekler" bölümüne gitmenizi tavsiye ederiz. durum diyagramları Elinizi farklı çizelgeleri okumada denemek için. O zaman "Uygulamalar" bölümünü incelemeye değer, çünkü UML'deki diyagram türlerinin sayısı az olsa da, kullanımlarından maksimum faydayı ancak ilgili diyagramları amaçlarına uygun olarak kullanırsanız elde edebilirsiniz.

kullanım örneği

Durum makinesi diyagramları Bir sistemin davranışını açıklamak için iyi bilinen bir teknolojidir. Durum diyagramları 1960'dan beri şu ya da bu şekilde olmuştur ve nesne yönelimli programlamanın ilk günlerinde bir sistemin davranışını temsil etmek için kullanılmıştır. Nesne yönelimli yaklaşımlarda, tek bir nesnenin ömrü boyunca davranışını göstermek için tek bir sınıfın durum diyagramını çizersiniz.

Durum makineleri, hız kontrol sistemleri veya otomatlar hakkında ne zaman yazsalar, kaçınılmaz olarak örnek olarak gösteriliyor.
Gotik kalede gizli kontrol paneli denetleyicisini kullanmaya karar verdik. Bu şatoda, bulunmaları zor olsun diye hazinelerimizi saklamak istiyoruz. Kasanın kilidine erişmek için şamdandan stratejik bir mum çıkarmalıyız, ancak kilit yalnızca kapı kapalıysa görünecektir. Kilit göründükten sonra, anahtarı içine sokabilir ve kasayı açabiliriz. Daha fazla güvenlik için, kasanın ancak mum çıkarıldıktan sonra açılabileceğinden emin olduk. Hırsız bu önlemi almazsa, hırsızı yutacak korkunç bir canavarı serbest bırakırız.

İncirde. 10.1 gösteri durum diyagramı olağandışı güvenlik sistemimi yöneten denetleyici sınıfı. Bir durum diyagramı, oluşturulan denetleyici nesnesinin durumuyla başlar: durumlar Beklemek... Bu, şemada ile gösterilir ilk sözde durum bu bir durum değildir, ancak ilk durumu gösteren bir ok vardır.
Diyagram, denetleyicinin üç durumdan birinde olabileceğini gösterir: Bekle, Kilitle ve Aç... Diyagram ayrıca, denetleyicinin bir durumdan diğerine geçişine göre kuralları gösterir. Bu kurallar geçişler şeklinde sunulur - durumları birbirine bağlayan çizgiler.

Geçiş, bir durumdan diğerine geçmek anlamına gelir. Her geçişin üç bölümden oluşan kendi etiketi vardır:
tetik-imza / etkinlik... Hepsi isteğe bağlıdır. Genellikle, tetik kimliği Durum değişikliğine neden olabilecek tek olaydır.

Koruma, belirtilirse, geçişin gerçekleşmesi için karşılanması gereken bir boole koşuludur. Etkinlik, geçiş sırasında sistemin bazı davranışlarıdır. Herhangi bir davranışsal ifade olabilir. Bir tetikleyici tanımlayıcısının tam biçimi, birden çok olay ve parametre içerebilir. Bekle durumundan (Şekil 10.1) başka bir duruma geçiş, "Bekle durumunda mum çıkarılırsa kilidi görür ve Kilit durumuna geçersiniz" şeklinde okunabilir.

Geçiş açıklamasının üç bölümü de isteğe bağlıdır. Aktiviteyi atlama, geçiş sırasında hiçbir şey olmadığı anlamına gelir. Korumaları atlama, tetikleyici bir olay meydana geldiğinde her zaman bir geçişin yapıldığı anlamına gelir. Tetikleyici tanımlayıcı nadiren kaybolur, ancak olur. Bu, esas olarak faaliyet durumlarında gözlemlenebilen geçişin hemen gerçekleştiği anlamına gelir.

Belirli bir durumda bir olay meydana geldiğinde, bu durumdan yalnızca bir geçiş yapılabilir, örneğin Kilit durumunda (Şekil 10.1), korumalar birbirini dışlayan olmalıdır. Bir olay meydana gelirse, ancak izin verilen geçişler yoksa - örneğin, Bekleme durumunda bir kasanın kapatılması veya kapı açıkken bir mumun çıkarılması - olay yok sayılır.

Son durum ( son durum) durum makinesinin çalışmayı bitirdiği ve bu da denetleyici nesnesinin silinmesine neden olduğu anlamına gelir. Bu yüzden tuzağa düşme dikkatsizliği olanlar için, denetleyici nesnenin varlığı sona erdiği için tavşanı tekrar kafese koymaya, zemini yıkamaya ve sistemi yeniden başlatmaya zorlandığımızı bildiriyoruz.

Durum makinelerinin yalnızca doğrudan gözlemlenen veya üzerinde işlem yapılan nesneleri gösterebileceğini unutmayın. Bu nedenle, kapı açıkken kasaya bir şey koymamızı veya oradan bir şey almamızı beklerken, denetleyicinin bu konuda söyleyecek bir şeyi olmadığı için şemada işaretlemedik.

Geliştiriciler nesneler hakkında konuştuklarında, genellikle nesnelerin durumuna, yani nesnenin alanlarında bulunan tüm verilerin birleşimine atıfta bulunurlar. Bununla birlikte, durum makinesi diyagramındaki durum, daha soyut bir durum kavramıdır; mesele şu ki, farklı durumlar olaylara farklı tepki verme yollarını içerir.

Durum haritasındaki dahili faaliyetler

Devletler, bir geçiş yapmadan olaylara tepki verebilir. iç faaliyetler (iç faaliyetler), bu durumda olay, koruma ve etkinlik durum dikdörtgeninin içine yerleştirilir.

İncirde. 10.2, durumu, editörün metin alanlarında gözlemleyebileceğiniz, yardım sisteminin sembollerinin ve olaylarının dahili faaliyetleriyle birlikte sunar. kullanıcı arayüzü... İç aktivite, kendi kendine geçiş gibidir - aynı duruma geri dönen bir geçiş. Dahili etkinliklerin sözdizimi aynı olay, koruma ve prosedür mantığını takip eder.

İncirde. 10.2 ayrıca özel aktiviteleri de gösterir: girdi ve çıktı faaliyetleri. Giriş Etkinliği bir duruma her girdiğinizde yürütülür; çıktı etkinliği- ne zaman eyaletten ayrılsan. Ancak, iç faaliyetler başlamaz. girdi ve çıktı faaliyetleri; arasındaki fark budur iç faaliyetler vekendi kendine geçişler .

Durum haritasındaki faaliyet durumları

Buraya kadar anlattığımız durumlarda nesne sessizdir ve herhangi bir şey yapmadan önce bir sonraki olayı bekler. Bununla birlikte, nesnenin bir miktar aktivite sergilediği durumlar mümkündür.

Belirtmek, bildirmek Aranıyor incirde. 10.3 böyle bir durum aktivite durumu: devam eden aktivite sembolü ile gösterilir yapmak /; dolayısıyla terim aktivite yapmak (aktif ol)... Arama tamamlandıktan sonra, örneğin yeni ekipmanın gösterilmesi gibi etkinlik olmadan geçişler gerçekleştirilir. (Yeni Donanımı Görüntüle)... Eğer bir iptal olayı ( İptal et), sonra aktivite yapmak sadece kesintiye uğrar ve duruma geri döneriz Donanım Penceresini Güncelle.

Hem do-aktiviteler hem de sıradan aktiviteler, bazı davranışların tezahürünü temsil eder. İkisi arasındaki belirleyici fark, normal faaliyetlerin "anlık" olması ve normal olaylar tarafından kesintiye uğramaması, do-aktivitelerinin ise Şekil 2'de gösterildiği gibi sınırlı bir süre boyunca devam edebilmesi ve kesintiye uğratılabilmesidir. 10.3. Anlıklık, farklı sistemler için farklı yorumlanır; gerçek zamanlı sistemler için bu, birkaç makine talimatı alabilir ve masaüstü yazılımı için birkaç saniye sürebilir.

V UML 1 ortak faaliyetler terimi ile ifade edildi eylem(eylem) ve terim aktivite(aktivite) sadece Faaliyet yapmak.

süper devletler

Çoğu durumda, birkaç devletin ortak geçişleri ve dahili faaliyetleri vardır. Bu gibi durumlarda, bunları alt durumlara dönüştürebilir ve genel davranışı Şekil 2'de gösterildiği gibi bir üst duruma taşıyabilirsiniz. 10.4. Süper durum olmadan, bir geçiş çizmeniz gerekirdi. İptal et(iptal) bir eyalet içindeki her üç eyalet için Bağlantı Ayrıntılarını Girin.

paralel durumlar

Durumlar, aynı anda çalışan birden fazla eşzamanlı duruma bölünebilir. İncirde. 10.5, CD'yi veya radyoyu açabilen ve geçerli saati veya alarm saatini gösterebilen basit bir çalar saati gösterir.

CD/radyo seçenekleri ile güncel saat/sinyal saati paraleldir. Bunu paralel olmayan bir durum diyagramı ile göstermek isteseydiniz, durumları eklemeniz gerektiğinde dağınık bir diyagram olurdu. İki davranış alanını iki durum çizelgesine bölmek, bunu çok daha net hale getirir.

Pirinç. 10.5 ayrıca şunları içerir: arka plan durumu(tarih sözde durumu). Yani saat açıldığında radyo/CD seçeneği saatin kapatıldığı andaki durumuna geçer. Tarihöncesinden çıkan ok, tarihöncesi yokken başlangıçta hangi devletin var olduğunu gösterir.

Durum diyagramlarını uygulama

Bir durum diyagramı üç ana yolla uygulanabilir: yuvalanmış bir anahtar ifadesi, bir Durum modeli ve bir durum tablosu ile. Durum çizelgeleriyle çalışmak için en basit yaklaşım, Şekil 1'de gösterilen gibi iç içe bir anahtar ifadesidir. 10.6.

Bu yöntem basit olmasına rağmen, bu basit durum için bile çok uzundur. Ek olarak, bu yaklaşımla kontrolü kaybetmek çok kolaydır, bu nedenle temel durumlarda bile kullanılmasını önermiyoruz.
Durum modeli, durum davranışını işlemek için bir durum sınıfları hiyerarşisini temsil eder. Bir durum haritasındaki her durum, kendi durum alt sınıfına sahiptir. Denetleyici, her olay için yalnızca durum sınıfına ileten yöntemlere sahiptir. Şekilde gösterilen durum diyagramı. 10.1, Şekil 2'de gösterilen sınıflar kullanılarak uygulanabilir. 10.7.

Hiyerarşinin en üstünde, olayları işleyen, ancak uygulama içermeyen tüm yöntemlerin açıklamasını içeren soyut bir sınıf bulunur.
Her belirli durum için, durumdan geçişi başlatan belirli bir olay için işleyici yöntemini yeniden yazmak yeterlidir.
Bir durum tablosu, bir durum diyagramını veri olarak temsil eder.

Yani, Şek. 10.1 tablo şeklinde sunulabilir. 10.1.
Ardından, çalışma zamanında durum tablosunu kullanan bir yorumlayıcı veya bu tabloya dayalı sınıflar oluşturan bir kod oluşturucu oluştururuz.

Açıkçası, bir durum tablosundaki çalışmaların çoğu bir kez yapılır, ancak daha sonra bir durum sorununun çözülmesi gerektiğinde kullanılabilir. Çalışma zamanı durum tablosu, yeniden derleme yapılmadan değiştirilebilir, bu da biraz uygundur. Durum kalıbının oluşturulması daha kolaydır ve her durum ayrı bir sınıf gerektirse de, yazılması gereken kod miktarı çok azdır.

Verilen uygulamalar pratik olarak minimaldir, ancak nasıl kullanılacağı hakkında bir fikir verir. durum diyagramları... Her durumda, durum modellerinin uygulanması oldukça kalıplaşmış bir programa yol açar, bu nedenle genellikle bunun için bir tür kod üretimine başvurmak en iyisidir.

Site haberlerine abone olun, abonelik formunu sitenin sağ sütununda bulabilirsiniz.

Profesyonel olarak nasıl serbest çalışacağınızı öğrenmek istiyorsanız, sizi "" kursuna davet ediyoruz.