UML'yi yazılım geliştirmede kullanma yolları.

UML modelleme içindir. UML yazarları kendi yavrularını aşağıdaki gibi tanımlarlar.

UML dili yazılım sistemlerinin geliştirilmesi sırasında oluşturulan tüm eserlerin belirtimi, görselleştirilmesi, tasarımı ve belgelenmesi için genel amaçlı bir grafik modelleme dilidir.

Bu tanıma tamamen katılıyoruz ve sadece anahtar kelime seçimini onaylamakla kalmıyor, aynı zamanda listelendikleri sıraya da büyük önem veriyoruz.

1.2.1. Şartname

Tipik olarak, uygulama geliştirme sürecinde en az iki aktör yer alır: müşteri(belirli bir kişi veya kişi veya kuruluş grubu) ve geliştirici(bu, yalnız bir programcı, geçici bir proje ekibi veya yazılım geliştirme konusunda uzmanlaşmış tüm bir kuruluş olabilir). İki karakter olması nedeniyle, çoğu, karşılıklı anlayış derecesine bağlıdır.

Bir uygulama geliştirmenin kilit adımlarından biri, geliştirilmekte olan uygulamanın hangi gereksinimleri karşılaması gerektiğini belirlemektir. Bu aşamanın bir sonucu olarak, farklı olarak adlandırılan ve yaklaşık olarak aynı anlama gelen resmi veya gayri resmi bir belge (eser) ortaya çıkar: sorun bildirimi, gereksinimler, görev tanımı, dış özellikler, vb.

Amaç olarak benzer, ancak belki biçim ve içerik olarak farklı olan eserler, özellikle geliştirmede birçok aktörün dahil edilmesi durumunda, gelişimin diğer aşamalarında da ortaya çıkar. Bunlar için çeşitli isimler de kullanılmaktadır: fonksiyonel özellikler, uygulama mimarisi, vb. Bu tür tüm yapıtları spesifikasyonlar olarak adlandıracağız.

Şartname bir şeyin nasıl çalıştığının veya çalıştığının bildirimsel bir açıklamasıdır.

Spesifikasyonların üç yorumu dikkate alınmalıdır.

• Spesifikasyonun kaynağı olan aktör anlamına gelen (örneğin, müşteri).
• Spesifikasyonun tüketicisi olan aktör tarafından kastedilen şey (örneğin, geliştirici).
• Belirtilen nesnenin doğası tarafından nesnel olarak koşullandırılan şey.

Spesifikasyonların bu üç yorumu örtüşmeyebilir ve ne yazık ki, uygulamanın gösterdiği gibi, çoğu zaman örtüşmezler ve önemli ölçüde. Müşteri, nesnel ihtiyaçlarının farkında olmayabilir veya bunları yanlış yorumlayabilir veya içinde bulundukları çıkmazın doğası konusunda yanlış yönlendirilebilir, özel bir ofis uygulamasıyla iş hastalıklarının nedeni yerine semptomları tedavi etmeye çalışabilir. Geliştirici, müşterinin konu alanını anlamayabilir ve şartname ifadesini tamamen yanlış yorumlayabilir. Geliştirici, spesifikasyonların formülasyonunda yer alıyorsa, teknik terminolojinin kötüye kullanılması müşteriyi tamamen şaşırtabilir.

Ana amaç UML- sağlamak, bir yandan, tercihen resmi, diğer tarafta, yeterince rahat ve üçüncü taraftan, oldukça çok yönlü, spesifikasyonların yorumlanmasında tutarsızlık riskini bir dereceye kadar azaltır.

1.2.2. görselleştirme

Bir kez görmek, yüz kez duymaktan daha iyidir diye ünlü bir söz vardır. Ekleyeceğiz: dahası, yeniden anlatımı binlerce kez okuyun. İnsan algısının özellikleri, resimli metnin çıplak metinden daha kolay algılanmasını sağlayacak şekildedir. Ve metin içeren resimler (buna "çizgi roman" denir) daha da kolaydır. UML modelleri resimler şeklinde gösterilebilir ve bu resimler net, sezgisel, neredeyse açık bir şekilde yorumlanır ve oluşturulması kolaydır. Aslında, bu tezin geliştirilmesi ve detaylandırılması, kitabın geri kalanının içeriğinin çoğunu oluşturuyor. Kendimizden geçmeyeceğiz ve hiçbir açıklama yapmadan sadece bir örnek vereceğiz.

Bir şey belirsiz mi?

Bu nedenle, UML'nin ikinci en önemli amacı, insanlar arasında yeterli bir iletişim aracı olarak hizmet etmektir. Tabii ki, UML modellerinin görselleştirilmesi, yalnızca insanlar tarafından oluşturulacak veya anlaşılacaksa önemlidir - UML'nin bu amacının bilgisayarlarla hiçbir ilgisi yoktur.

Bir UML modelinin grafiksel gösterimi, modelin kendisiyle aynı değildir. Bu önemli nokta, UML ile ilk tanıtıldığında genellikle gözden kaçar.

1.2.3. Tasarım

Orijinalde bu UML amacı, dikkatli bir "tasarım" terimi ile aktardığımız yapı kelimesi ile tanımlanır. Buradaki nokta, UML'nin yalnızca soyut uygulama modellerini tanımlamayı değil, aynı zamanda program kodu gibi bu uygulamaları oluşturan yapay öğeleri doğrudan manipüle etmeyi amaçlamasıdır. Başka bir deyişle, UML'nin amaçlarından biri, örneğin, mümkün olduğu modeller oluşturmaktır. otomatik kod oluşturma(veya kod parçacıkları) ilgili uygulamaların. Ayrıca, UML modellerinin doğası, ters işlemin de mümkün olduğu şekildedir: bitmiş bir uygulamanın kodundan otomatik olarak bir model oluşturmak.

İngilizce'de, bitmiş bir uygulamanın koduna dayalı bir modelin otomatik yapımına tersine mühendislik denir ve genellikle Rusça'ya "tersine mühendislik" olarak çevrilir. Bu çeviriyi kategorik olarak sevmiyoruz: bu ne tür bir tasarım ve neden tam tersi? İyi bir alternatif var: "programların mühendislik analizi", ancak henüz dağıtım almadı.

Bir önceki paragrafta söylenenler, her ifadeden sonra kelimenin tam anlamıyla "bir dereceye kadar", "belirli bir dereceye kadar" çekinceler gerektirir. En can sıkıcı şey, şu anda "derece" ve "ölçü" nü doğru bir şekilde belirtmenin mümkün olmamasıdır. Nedeni, kimsenin bunu yapmaya zahmet etmemesi değil, bunun çok zor bir iş olması ama umutsuz da değil. UML'yi destekleyen araçlar sürekli gelişiyor, bu nedenle gelecekte UML'nin üçüncü amacı öne çıkabilir.

Sonsuz hata ayıklamaktan bıkmış bazı geliştiriciler için UML'yi öğrenmeye değer gibi görünebilir ve tüm programlama sorunları çözülecektir. Ne yazık ki, bu böyle değil.

1.2.4. belgeler

UML modelleri, hem elektronik belge biçiminde hem de basılı kopya biçiminde saklanabilen ve kullanılabilen eserlerdir. UML'nin son sürümlerinde bu amaca daha iyi uyması için çok şey yapıldı. Özellikle, modellerle çalışırken pratik birlikte çalışabilirlik sağlayan UML modellerinin XMI belgeleri biçiminde temsili belirtilir. Başka bir deyişle, UML modelleri kendi başlarına yalnızca hayran kalacağınız şeyler değildir - bunlar, resim basmaktan otomatik olarak insan tarafından okunabilir metin açıklamaları oluşturmaya kadar çeşitli şekillerde kullanılabilen belgelerdir.

XMI (XML Meta Veri Değişimi), modelleri serileştirmek ve değiştirmek için tasarlanmış XML diline (şema ve etiketlerin kullanılmasına yönelik bir dizi kural) dayalı harici bir veri biçimidir.

Bir önceki paragrafın son cümlesini açıklayın. Standart, modelin dahili temsilinde, her modelleme öğesinin, bu öğenin resmi olmayan bir metinsel açıklamasının saklanabileceği bir yere sahip olmasını gerektirir. Çoğu araç bu gereksinimi karşılar: diyagramdaki her satır veya şekil için kelimenin tam anlamıyla, bu belirli satır veya şeklin anlamını ve amacını açıklayan metin girebilirsiniz. Ayrıca, birçok araç, tam olarak modellenen sistemin tanıdık metin açıklamaları olarak kullanılabilen bu metin açıklamalarından bütün, oldukça anlamlı ve iyi biçimlendirilmiş metin belgelerini bir araya getirebilir. Ne yazık ki pratikte bu harika fırsat hak ettiğinden daha az kullanılıyor. Gerçek şu ki, programcıların program koduna anlamlı yorumlar yazmaktan hoşlanmamaları ve tembel olmaları gibi, mimarlar da diyagramları için metinsel açıklamalar yazmaktan hoşlanmazlar ve çok tembeldirler.

1.2.5. UML ne DEĞİLDİR

UML'nin tüm çocuklar için her derde deva olduğunu düşünmemelisiniz. ∇ programlama hastalıkları UML'nin amacını ve kapsamını net bir şekilde anlamak için UML'yi diğer ilgili fenomenlerle karşılaştırmak yararlıdır.

∇ Bilgi teknolojileri en az yarım asırlık bir geçmişe sahiptir - bu, yeni bir insan faaliyeti alanı için henüz emekleme dönemidir.

Her şeyden önce, UML bir programlama dili değildir(kod oluşturma önerilmemesine rağmen, bkz. bölüm 1.2.3). UML grafiksel bir dil değildir, ancak pratik programlama dillerinin büyük çoğunluğu metin tabanlı dillerdir. Daha da önemlisi, UML modellerinin tanımlı olmamasıdır. operasyonel anlambilim, yani modellerin bilgisayarda yürütülme şekli tanımlanmamıştır. Bu oldukça bilinçli bir şekilde yapıldı, aksi takdirde UML bir tür hesaplanabilirlik modeline bağımlı olacaktı, kavramlarının soyutlama seviyesinin önemli ölçüde düşürülmesi gerekecekti ve asıl amacını yerine getirmeyecekti: uygulamaları ve uygulamaları belirlemenin bir aracı olarak hizmet etmek. herhangi bir soyutlama düzeyinde ve çeşitli konu alanlarında diğer sistemler.

İkincisi, UML bir araç özelliği değildir(Magic Draw, Rational Rose Enterprise, Visual Paradigm, Enterprise Architect, vb. gibi araçlar ima edilmiş ve kullanılabilir olsa da). Dilin kendisi hiçbir şekilde araçlar tarafından nasıl desteklenmesi gerektiğini dayatmaz. UML'nin bir bilgisayarda uygulanmasıyla ilgili tüm sorunların çözümü, tamamen araç geliştiricilerin insafına kalmıştır.

Üçüncüsü, UML, uygulama geliştirme süreci için bir model değildir(bir geliştirme süreci modeline ihtiyaç duyulmasına ve farklı yazarlar tarafından önerilen birçok farklı model olmasına rağmen). Tabii ki, UML yazarlarının kendi süreç modeli vardır - yardımcı olamayacakları ancak dili geliştirirken akıllarında bulundurdukları Rational Unified Process (RUP), ancak yine de RUP'un doğrudan etkisini ortadan kaldırmak için her şeyi yaptılar. ve UML'yi herhangi bir süreç modelinde ve hatta onsuz kullanılabilir hale getirin.

Bu kitabın yazarları, UML ile dilin pragmatiğinin tanımını etkilemeyen ama etkileyen yazılım geliştirme süreç modeli (bkz. yapıldı.

1.2.6. UML'yi kullanma yolları

Yukarıdan, UML'nin sırasıyla çeşitli sorunları çözmek için tasarlandığı, farklı şekillerde kullanılabileceği ve pratik olarak kullanılabileceği görülebilir. Ardından, UML'nin kullanılabileceği çeşitli yolları listeleyeceğiz.

resim çizme. UML grafik araçları, diğer her şeye bakılmaksızın kullanılabilir ve kullanılmalıdır. Kağıda kurşun kalemle diyagramlar çizmek bile düşüncelerinizi düzene koymanıza ve modellenen uygulama veya diğer sistem hakkında temel bilgileri kendiniz yakalamanıza olanak tanır.

Bilgi değişimi. UML'yi kullanan ve anlayan insan topluluğu hızla büyüyor. UML kullanırsanız, başkaları tarafından anlaşılacaksınız ve diğerlerini "bir bakışta" anlayacaksınız.

Sistem özellikleri. UML'yi kullanmanın en önemli yolu budur. UML her durumda kesinlikle yeterli bir belirtim aracı olmasa da, dil geliştikçe UML'nin uygulanabilir olmadığı durumlarda bu tür istisnaların giderek daha az olacağını umuyoruz.

Mimari çözümlerin yeniden kullanımı. Daha önce geliştirilmiş çözümleri yeniden kullanmak, verimliliği artırmanın anahtarıdır. Bu konudaki görüşümüz Bölüm 5.2'de sunulmuştur. Ne yazık ki, UML modelleri şimdiye kadar çok sınırlı bir ölçüde yeniden kullanılmıştır.

"Diyagram çizme" kullanım durumu, düşünmek, insanlar arasında fikir paylaşmak, belgelemek ve benzeri amaçlarla UML diyagramları çizmeyi ifade eder. Bu durumda Kullanıcı için önemli olan sonuç, çizelgelerin kendisinin görüntüsüdür. Genel olarak konuşursak, dilin bu kullanım durumunda, destekleyici bir araca gerçekten ihtiyaç yoktur. Bazen keçeli kalemle elle diyagramlar çizip ardından dijital kamera ile fotoğraf çekmek daha pratik olabilir.

Modelleme kullanım durumu, UML üst modeli tarafından sağlanan modelleme öğeleri açısından bir sistem modelinin oluşturulmasını ve değiştirilmesini içerir. Bu durumda önemli bir sonuç, model açıklamasıyla birlikte makine tarafından okunabilen bir yapıdır. Kısaca, böyle bir esere model olarak değineceğiz, model üretme etkinliğine modelleme olarak atıfta bulunacağız ve modelleme konusuna mimar olarak atıfta bulunacağız.

Kullanım senaryosu geliştirme ("Uygulamaların geliştirilmesi"), uygulamanın UML açısından ayrıntılı olarak modellenmesi, uygulanması ve test edilmesi anlamına gelir. Bu durumda Geliştirici kullanıcısı için anlamlı olan sonuç, belirli bir Programlama Sistemi tarafından desteklenen bir dilde derlenebilen veya aracın çalışma zamanı ortamı tarafından hemen yorumlanabilen çalışan bir uygulamadır. Bu kullanım durumu, uygulanması en zor olanıdır.

Modern araçlar, bu kullanım durumlarını eşit derecede değil destekler. Tüm araçlar (kötü veya iyi) her tür UML diyagramını görselleştirebilir, bazı araçlar daha fazla kullanıma izin veren bir model oluşturmanıza izin verir, ancak yalnızca birkaç araç yürütülebilir kod oluşturabilir ve ardından hiçbir şekilde, tüm diyagramlar. Yukarıdaki kullanım durumlarının eşit olmamasının ve modern araçlarda değişen derecelerde desteğe sahip olmasının birçok pratik ve organizasyonel nedeni vardır. Bu nedenlerden bazılarını sonraki bölümlerde ele alacağız.

Şu anda Rational Software, bileşen mimarisine sahip bilgi sistemlerinin nesne yönelimli analizi ve tasarımı alanında tartışmasız liderdir. Bu şirket tarafından birleştirilmiş bir modelleme dilinin kullanımına dayalı olarak geliştirilen metodoloji (UML - Birleşik Modelleme Dili şu anda OMG tarafından standart olarak benimsenmiştir), bir dizi görsel modelleme aracı, işbirlikçi geliştirme (ana programlama dilleri) tarafından desteklenmektedir. ​​C ++, Java, Visual Basic, SmallTalk, vb. ve ayrıca popüler geliştirme ortamları - MS Visual Studio, Delphi, PowerBuilder), yazılım sistemleri oluşturma yaşam döngüsünü kapsayan otomatik test ve belgeler.

Rational Software'in bir ürünü olan Rational Rose'a ek olarak, UML standartlarını destekleyen popüler görsel modelleme araçları arasında Paradigm Plus (PLATIN Technology'den bir yazılım ürünü), SELECT (SELECT Software), Oracle Designer (Oracle), Together Control Center (Borland) bulunur. , AllFusion Component Modeler (Computer Associates) ve Microsoft Visual Modeler (Rational Software&Microsoft Corporation).

Rasyonel Gül. Rational Software Cogr'dan nesne yönelimli bilgi sistemleri için popüler bir görsel modelleme aracı. Ürünün çalışması evrensel modelleme dili UML'ye (Universal Modeling Language) dayanmaktadır. Rational Rose, benzersiz modelleme dili sayesinde, bilgi sistemlerinin tasarımındaki hemen hemen her sorunu çözebilir: iş süreci analizinden belirli bir programlama dilinde kod oluşturmaya kadar. Yalnızca Rose hem yüksek hem de düşük seviyeli modeller geliştirmenize izin verir, böylece soyut tasarım veya mantıksal tasarım uygular.

Rational Rose, ADA, Java, C, C++, Basic dillerinde ileri ve geri mühendisliği destekler. COM, DDL, XML teknolojilerini destekler. Oracle ve SQL şemaları oluşturmanıza izin verir.

Rational Rose, belirli programlama dilleri için kendi modüllerinizi oluşturmanıza olanak tanıyan açık bir API'ye sahiptir.

Yourdon'u seçin. Bu sistem Select Software Tools Ltd. tarafından geliştirilmiştir. (İngiltere). Select Yourdon, modül kodlamasına kadar tüm ilk geliştirme sürecini kapsayan gereksinim analizi ve yazılım sistemi tasarım aşamalarını destekler. Aşağıdaki yapısal yöntemler (şemalar) desteklenir:

• varlık ilişkisi diyagramları;
• Yourdon/Ward & Mellor ve Hatley notasyonuna dayalı veri ve kontrol akış diyagramları;
• durum geçiş diyagramları;
• mini proses özellikleri;
• Konstantin'in yapısal diyagramları;
• Jackson yapısal diyagramları.

İlk üç tür diyagram ve mini süreç belirtimi, yazılım gereksinimlerini analiz etmek ve formüle etmek için kullanılabilir, son ikisi - yazılım mimarisini ve bireysel modüllerini tasarlamak için kullanılabilir. Proje veritabanı, sözde Veri Sözlüğü'nde yoğunlaşmıştır. Sistem, hem tek kullanıcılı çalışmayı hem de bir geliştirici ekibinin ağ çalışmasını destekler.

Oracle Tasarımcısı. Oracle Designer araç takımı, Web ve istemci/sunucu uygulamaları için kurumsal uygulama sistemleri geliştirmek için entegre bir çözüm sunar. Oracle Designer, iş süreci modellemeden uygulamaya kadar yazılım geliştirme yaşam döngüsünün her aşamasında yer alır. Tek bir havuzun kullanılması, ölçeklenebilir, platformlar arası dağıtılmış uygulamaların hızlı gelişimi için bileşenlerinden herhangi birinin kullanılmasını mümkün kılar.

Oracle Designer'ın görevi, kullanıcıların ihtiyaçları hakkında veri toplamak ve esnek grafik uygulamalarının oluşturulmasını otomatik hale getirmektir. Oracle Designer sadece uygulama oluşturmak için değil, sistemin çalışması sırasında kaçınılmaz olarak meydana gelen değişiklikleri takip etmek için de kullanılır.

Çok kullanıcılı veri havuzuyla entegre grafiksel proje tanımı modelleri, Oracle Designer ile çalışmayı çok daha kolay hale getirir. Araçlar, geliştirme yaşam döngüsünün tamamını kapsayan genel kabul görmüş metodolojiler temelinde oluşturulmuştur. Bu, ürünün yalnızca belirli bir görev için gerekli olan kısımlarını kullanarak yazılım geliştirmeye yönelik esneklik ve açık bir yaklaşım sağlar. Geliştirme süreci RAD, JAD, bilgi tasarımı, şelale, yinelemeli ve şirkete özel yaklaşımları destekler.

Microsoft Görsel Modelleyici. Microsoft Corporation ile birlikte Rational Software tarafından geliştirilen bir görsel modelleme aracı olan Microsoft Visual Modeler (MSVM), bileşen tabanlı uygulamalar tasarlamak için UML tabanlı modelleme sağlar. MSVM kullanılarak oluşturulan modeller, Visual Basic 6.0 ve Visual C++ geliştirme ortamlarında uygulanan projeler için otomatik olarak nesne kodu oluşturabilir.

Microsoft Visual Modeler, kurumsal geliştiricilerin herhangi bir ağa yüklenebilen ölçeklenebilir, çok katmanlı iş uygulamaları oluşturmasına olanak tanıyan Windows Dağıtılmış İnternet Uygulamaları (Windows DNA) mimarisini destekler.

Microsoft Visual Modeler'ın en son sürümü, hem Visual Basic geliştiricileri hem de Visual C++ geliştirme desteği için güncellenmiş özellikler de dahil olmak üzere, görsel modelleme ile Visual Studio geliştirme ortamı arasında benzeri görülmemiş bir entegrasyon düzeyi sunar.

Windows DNA, Visual Studio ve Microsoft Visual Modeler (MSVM), yeni nesil n katmanlı, bileşen tabanlı uygulamaları oluşturmak için doğru altyapı ve tasarım araçları kombinasyonunu sağlar.

MSVM, geliştiricilerin uygulamalarının organizasyonunu grafiksel bir şekilde görselleştirmelerine olanak tanıyarak Windows DNA'sına dayalı karmaşık, katmanlı iş uygulamaları oluşturmayı kolaylaştırır.

Microsoft Visual Modeler'daki yeni özellikler arasında Microsoft Visual SourceSafe sürüm kontrol sistemi ile entegrasyon; Microsoft Visual Manager (VCM) entegrasyonu ve Visual Basic geliştirmesi için geliştirilmiş Microsoft Repository desteği. Ekip geliştirmeyi desteklemek için Visual Modeler uzantıları, modelleri VCM aracılığıyla bir havuzda yayınlama yeteneğini içerir; modeller daha sonra tasarım ekibinin üyeleri arasında görüntülenebilir ve paylaşılabilir. Bileşenler, sürükle ve bırak tekniği kullanılarak VCM aracılığıyla depodan içe aktarılabilir. Benzer şekilde, COM arabirim bileşenleri Windows Gezgini'nden alınabilir.

Dünyanın önde gelen görsel modelleme aracı olan Rational Rose ailesindeki öğrenmesi en kolay araç olan Microsoft Visual Modeler, ortak bir kod tabanını paylaşır ve Visual Basic ve/veya kullanan programcılar için ölçeklenebilir, entegre, tamamen birlikte çalışabilir görsel modelleme çözümleri sunar. veya Visual C++. Visual Modeler, görsel modelleme konusunda deneyimi olmayan geliştiricilerin bile kolayca ustalaşabileceği ve başarılı bir şekilde modeller oluşturabileceği şekilde tasarlanmış Birleşik Modelleme Dilini (UML) destekler.

AllFusion ürün ailesi. Component Modeler, Computer Associates'ten AllFusion Modeling Suite'in temel bileşenidir. Paket ayrıca şunları içerir: İş sürecini, veri akışını ve iş akışı modellemeyi kullanımı kolay tek bir araçta birleştiren Process Modeler (eski adıyla BPwin); Veritabanı modelleme için ERwin Data Modeler (eski adıyla ERwin) ve veri modellerinin tutarlılığını ve kalitesini iyileştirmek için Data Model Validator (eski adıyla ERwin Examiner). Component Modeler ve ERwin Data Modeler, veritabanı geliştiricilerinin ve analistlerinin ilişkisel veritabanlarındaki bilgileri nesne yönelimli uygulamalar tarafından kullanılmaya uygun bir forma dönüştürmelerini sağlamak için birlikte çalışır. Process Modeler iş süreci modelleri, bir organizasyonun iş süreçleri için en uygun desteği sağlamak için ERwin Data Modeler veri modelleriyle senkronize edilebilir.

AllFusion ailesi, süreç ve proje yönetimi, modelleme ve geliştirme, bilgi yayınlama ve görselleştirme araçlarından oluşur. AllFusion yazılım ailesi, giderek karmaşıklaşan ve değişen e-iş dünyasının ihtiyaçlarını karşılamak için kritik uygulama yaşam döngüsü süreçlerini otomatikleştirme yeteneğini geliştirir.

Mevcut nesne yönelimli analiz ve tasarım (OOAD) yöntemlerinin çoğu, hem bir modelleme dili hem de modelleme sürecinin bir tanımını içerir. modelleme dili projeleri tanımlamak için yöntem tarafından kullanılan bir gösterimdir (çoğunlukla grafiksel).

gösterim modellerde kullanılan grafik nesnelerin bir koleksiyonudur; bir modelleme dilinin sözdizimidir. Örneğin, sınıf diyagramı gösterimi, sınıf, ilişkilendirme ve çokluk gibi öğelerin ve kavramların nasıl temsil edildiğini tanımlar.

İşlem projenin geliştirilmesinde izlenecek adımların bir açıklamasıdır.

Birleşik Modelleme Dili UML(Birleşik Modelleme Dili), 80'lerin sonlarında ve 90'ların başında ortaya çıkan OOAP yöntemlerinin neslinin halefidir.

UML dili yazılım bileşenlerinin, iş süreçlerinin ve diğer sistemlerin belirtimi, görselleştirilmesi, tasarımı ve belgelenmesi için tasarlanmış genel amaçlı bir görsel modelleme dilidir. UML dili, çeşitli amaçlar için karmaşık sistemlerin kavramsal, mantıksal ve grafiksel modellerini oluşturmak için etkin bir şekilde kullanılabilecek basit ve güçlü bir modelleme aracıdır.

UML dilinin yapıcı kullanımı, karmaşık sistemleri modellemenin genel ilkelerinin ve özellikle nesne yönelimli tasarım (OOP) sürecinin özelliklerinin anlaşılmasına dayanır. Karmaşık sistemlerin modellerini oluşturmak için ifade araçlarının seçimi, bu modeller kullanılarak çözülebilecek görevleri önceden belirler. Aynı zamanda, karmaşık sistemlerin modellerini oluşturmak için temel ilkelerden biri, modele yalnızca tasarlanan sistemin, doğrudan sistemin işlevlerinin performansıyla veya amaçlananla doğrudan ilgili olan yönlerini dahil etmeyi öngören soyutlama ilkesidir. amaç. Bu durumda, ortaya çıkan modeli analiz etme ve inceleme sürecini aşırı karmaşıklaştırmamak için tüm küçük ayrıntılar atlanır.

Karmaşık sistemlerin modellerini oluşturmak için başka bir ilke, çoklu model prensibi. Bu ilke, tek bir modelin karmaşık bir sistemin çeşitli yönlerini yeterince tanımlayamayacağı iddiasıdır. OOP metodolojisine uygulandığında, bu, karmaşık bir sistemin oldukça eksiksiz bir modelinin, her biri sistemin davranışının veya yapısının bazı yönlerini yeterince yansıtan birbiriyle ilişkili bir dizi görüşe (görüşlere) izin verdiği anlamına gelir. Aynı zamanda, karmaşık bir sistemin en genel temsilleri, statik ve dinamik temsiller olarak kabul edilir ve bunlar da daha özel temsillere bölünebilir.) Karmaşık bir sistem olgusu, tam olarak şu gerçeğinde yatmaktadır: tek temsillerinin tümü, simüle edilmiş sistemin tüm özelliklerini yeterince ifade etmek için yeterlidir.

Uygulamalı sistem analizinin bir başka ilkesi, karmaşık sistem modellerinin hiyerarşik inşası ilkesidir. Bu ilke, sabit temsiller çerçevesinde farklı soyutlama veya ayrıntı seviyelerinde bir model oluşturma sürecini ele almayı öngörür. Bu durumda, karmaşık bir sistemin ilk veya ilk modeli en genel temsile (meta-temsil) sahiptir. Böyle bir model ilk tasarım aşamasında oluşturulur ve modellenen sistemin birçok detayını ve yönünü içermeyebilir.

UML'nin yaratılması aslında 1994'ün sonunda başladı. Grady B uh ve James Rambo Rational Software çatısı altında Booch ve OMT (Object Modeling Technique) yöntemlerini birleştirmek için çalışmalara başladı. 1995'in sonunda, Unified Method, sürüm 0.8 olarak adlandırdıkları ilk birleşik yöntem belirtimini oluşturmuşlardı. Daha sonra 1995 yılında OOSE yönteminin (Nesneye Yönelik Yazılım Mühendisliği) yaratıcısı onlara katıldı. Ivar Jacobson. Böylece, UML doğrudan bir birlik ve birleşmedir Booch, Rambo ve Jacobson yöntemleri , ancak onlara yeni özellikler ekler.

UML'nin geliştirilmesindeki ana hedefler şunlardı:

– kullanıcılara anlamlı modeller geliştirmelerine ve paylaşmalarına olanak tanıyan, kullanıma hazır, anlamlı bir görsel modelleme dili sağlamak;

– temel kavramları genişletmek için genişletilebilirlik ve uzmanlaşma mekanizmaları sağlamak;

– belirli programlama dillerinden ve geliştirme süreçlerinden bağımsızlığı sağlamak;

– bu modelleme dilini anlamak için resmi bir temel sağlamak (dil, gereksiz formalizm olmaksızın hem doğru hem de anlaşılır olmalıdır);

– nesne yönelimli araçlar için pazarın büyümesini teşvik etmek;

– En iyi uygulamaları entegre edin.

UML dili nesne yönelimli yöntem ve teknolojiler alanında bir standartlar organizasyonu olan OMG (Object Management Group) tarafından yürütülen standardizasyon sürecindedir, artık standart bir modelleme dili olarak kabul edilmekte ve yazılım endüstrisinde geniş destek almıştır.

UML dili neredeyse tüm büyük yazılım şirketleri (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase, vb.) tarafından benimsenmiştir. Buna ek olarak, neredeyse tüm dünya CASE araçları üreticileri, Rational Software'e (Rational Rose) ek olarak, ürünlerinde UML'yi destekler (Paradigma Plus 3.6, System Architec, Visual Basic için Microsoft Visual Modeler, Delphi, PowerBuilder, vb.). UML'nin tam açıklaması http://www.omg.urg, http://www.rational.com ve http://uml.shl.com adreslerinde bulunabilir. UML'nin Rusça tanımı, M. Fowler ve K. Scott'ın kitabında yer almaktadır, daha sonraki sunumda dilin terminolojisi bu çeviriye karşılık gelmektedir.

UML'nin yaratıcıları, onu yazılım sistemlerini, organizasyonel, ekonomik, teknik vb. tanımlamak, temsil etmek, tasarlamak ve belgelemek için bir dil olarak sunar.

UML, çeşitli türlerde standart diyagramlar ve gösterimler içerir.

UML'deki diyagram- Bu, çoğunlukla köşeler (varlıklar) ve kenarlar (ilişkiler) ile bağlantılı bir grafik olarak gösterilen bir dizi öğenin grafiksel bir temsilidir. Bir sistemi farklı perspektiflerden görselleştirmek için diyagramlar çizilir.

Diyagram- bir anlamda sistemin izdüşümlerinden biri. Kural olarak, en önemsiz durumlar dışında, diyagramlar sistemi oluşturan öğelerin özet bir görünümünü verir. Aynı öğe tüm diyagramlarda bulunabilir veya yalnızca birkaçında (en yaygın seçenek) bulunabilir veya hiçbirinde olmayabilir (çok nadir).

Teorik olarak diyagramlar, varlıkların ve ilişkilerin herhangi bir kombinasyonunu içerebilir. Ancak pratikte, bir yazılım sisteminin mimarisini oluşturan en yaygın beş türe karşılık gelen nispeten az sayıda tipik kombinasyon kullanılır.

UML aşağıdakileri ayırt eder: grafik türleri:

– durum diyagramlarını kullan(kullanım senaryosu diyagramları) - kuruluşun iş süreçlerini modellemek için (sistem gereksinimleri);

– sınıf diyagramları(sınıf diyagramları) - sistem sınıflarının statik yapısını ve aralarındaki ilişkileri modellemek için. Bu tür diyagramlar sınıfları, arabirimleri, nesneleri ve işbirliklerini ve bunların ilişkilerini gösterir. Nesne yönelimli sistemleri modellerken, bu tür diyagramlar en sık kullanılır. Sınıf diyagramları, tasarım açısından sistemin statik görünümüne karşılık gelir;

– sistem davranış diyagramları(davranış şemaları);

– etkileşim diyagramları(etkileşim şemaları) - nesneler arasında mesaj alışverişi sürecini modellemek için. İki tür etkileşim diyagramı vardır: dizi diyagramları(sıra şemaları) ve işbirlikçi diyagramlar(işbirliği şemaları). Etkileşim diyagramları nesneler arasındaki ilişkileri temsil eder; özellikle nesnelerin değiş tokuş edebileceği mesajları gösterir. Etkileşim diyagramları, bir sistemin dinamik görünümünü ifade eder. Aynı zamanda, sıra diyagramları mesajların zamansal sıralamasını yansıtır ve işbirliği diyagramları mesaj alışverişinde bulunan nesnelerin yapısal organizasyonunu yansıtır. Bu diyagramlar izomorfiktir, yani birbirlerine dönüştürülebilirler;

– durum diyagramları(durum şeması diyagramları) - bir durumdan diğerine geçiş sırasında sistem nesnelerinin davranışını modellemek için. Durumları, geçişleri, olayları ve eylem türlerini içeren bir otomatı temsil ederler. Durum diyagramları, bir sistemin dinamik görünümüne atıfta bulunur; bir arabirim, sınıf veya işbirliğinin davranışını modellerken özellikle önemlidir. Reaktif sistemleri modellemek için çok yararlı olan olayların sırasına bağlı olarak bir nesnenin davranışına odaklanırlar;

– aktivite diyagramları(etkinlik diyagramları) - çeşitli kullanım durumları veya modelleme faaliyetleri çerçevesinde sistemin davranışını modellemek için. Bu durum diyagramının özel bir durumudur; sistem içinde bir aktiviteden diğerine kontrol akışının geçişlerini temsil eder. Aktivite diyagramları sistemin dinamik görünümüne atıfta bulunur; işleyişini modellemede çok önemlidirler ve nesneler arasındaki kontrol akışını yansıtırlar;

– uygulama şemaları: bileşen diyagramları(bileşen diyagramları) - sistemin bileşenlerinin (alt sistemlerin) hiyerarşisini modellemek için; yerleştirme şemaları(dağıtım şemaları) - sistemin fiziksel mimarisini modellemek için. Bileşen diyagramı, bir dizi bileşenin organizasyonunu ve aralarında var olan bağımlılıkları gösterir. Bileşen diyagramları, bir sistemin uygulama açısından statik görünümünü ifade eder. Bir bileşen genellikle bir veya daha fazla sınıfa, arabirime veya işbirliğine eşlendiğinden, bunlar sınıf diyagramlarıyla ilişkilendirilebilirler.

Nesne yönelimli modelleme dilleri, 70'lerin ortalarından 80'lerin sonlarına kadar olan dönemde, araştırmacıların nesne yönelimli programlama dillerinin yeni özelliklerini ve giderek karmaşıklaşan uygulamaların gereksinimlerini dikkate alma ihtiyacı ile karşı karşıya kaldıklarında ortaya çıktı. , analiz ve tasarıma çeşitli alternatif yaklaşımlar geliştirmeye zorlanmıştır.

1989'dan 1994'e kadar, farklı nesne yönelimli yöntemlerin sayısı ondan ellinin üzerine çıktı. Ancak birçok kullanıcının ihtiyaçlarına tam olarak uygun bir modelleme dili seçmekte zorlanması sözde “yöntem savaşı”na neden oldu. Bu savaşlar sonucunda dillerin özel bir önem kazandığı yeni nesil yöntemler ortaya çıkmıştır. Booch, yaratıldı Grady Boochem (Grady Booch) OOSE(Nesneye Yönelik Yazılım Mühendisliği), tarafından geliştirilen Ivar Jacobson (Ivar Jacobson) ve STD(Nesne Modelleme Tekniği), yazar James Rambo (James Rumbaugh). Ayrıca dillerden de bahsetmek gerekir Füzyon, Schlaer-Mellora(Shlaer-Mellor) ve Coada Yordona(Koad Yourdon). Bu yöntemlerin her biri, her birinin yalnızca güçlü yönleri değil, aynı zamanda zayıf yönleri de olmasına rağmen, oldukça eksiksiz ve eksiksiz olarak kabul edilebilir.

Booch yönteminin ifade olanakları, özellikle modelin tasarım ve yapım aşamalarında önemlidir. OOSE, gereksinim analizi ve formülasyonunun yanı sıra üst düzey tasarım için çok uygundur. OMT-2, büyük miktarda verinin işlenmesine yönelik bilgi sistemlerinin analizi ve geliştirilmesi için özellikle yararlı olduğunu kanıtladı.

1990'ların ortalarında, kritik bir yeni fikir kitlesi oluşmaya başladı. Grady Kasap(Rational Software Corporation), Ivar Jacobson(İtiraz) ve James Rambo(General Electric), bu alanda en umut verici olarak dünya çapında tanınan yöntemlerini birleştirme girişiminde bulundu. Dillerin ana yazarları olarak Booch, OOSE ve OMT, ortaklar yeni bir tane yaratmaya çalıştı, Birleştirilmiş Modelleme Dili ve üç düşünce tarafından yönlendirildi.

İlk olarak, geliştiricilerin arzusu ne olursa olsun, her üç yöntem de zaten ters yönde gelişmiştir. İstenmeyen farklılıkları ortadan kaldırmaya yardımcı olacak ve sonuç olarak gelecekte kullanıcılar için rahatsızlık yaratacak olan bu evrimi ayrı ayrı değil birlikte sürdürmek akıllıcaydı.

İkincisi, yöntemleri birleştirerek, tüm projeleri tek bir olgun dile dayandırmayı mümkün kılacak ve araç üreticilerinin daha üretken faaliyetlere odaklanmasını sağlayacak olan nesne yönelimli modelleme aracı pazarına istikrar getirmek daha kolay olacaktır.

Son olarak, böyle bir işbirliğinin her üç yöntemi de geliştirmesi ve tek başına ele alındığında pek uygun olmayan sorunlara çözümler sunması beklenebilirdi.

– nesne yönelimli yöntemler kullanarak konseptten yürütülebilir yapaylığa kadar tüm sistemleri modelleyin;

– kritik görevleri gerçekleştirmek için tasarlanmış karmaşık sistemlerde bulunan ölçeklenebilirlik sorununu çözmek;

- Sadece insanların değil, bilgisayarların da kullanabileceği bir modelleme dili oluşturmak.

Nesne yönelimli analiz ve tasarım için bir dil icat etmek, bir programlama dili geliştirmekten çok da farklı değildir. Her şeyden önce, görevi sınırlamak gerekiyordu. Dil, gereksinimleri belirleme becerisini içermeli mi? Dil görsel programlamaya izin vermeli mi? ikinci olarak, ifade gücü ve sadelik arasında bir denge bulmak gerekiyordu. Çok basit bir dil, onunla çözülen görevlerin aralığını sınırlar ve çok karmaşık, deneyimsiz bir geliştiriciyi bunaltabilir. Ek olarak, mevcut yöntemleri birleştirirken, onların yardımıyla halihazırda geliştirilmiş olan ürünlerin mevcudiyetini de hesaba katmak gerekiyordu. Çok fazla değişiklik yapmak mevcut kullanıcıları yabancılaştırabilir ve dil gelişimine direnerek yazarlar yeni kullanıcıları çekme ve dili daha basit ve kullanımı daha kolay hale getirme yeteneğini kaybeder. UML'yi oluştururken geliştiriciler bu sorunlara en iyi çözümü bulmaya çalıştılar.

Resmi olarak, UML'nin oluşturulması Ekim 1994'te başladı. Rumbaugh, Butch'ın çalıştığı Rational Software'e taşındığında. Orijinal hedef, Booch ve OMT yöntemlerini birleştirmekti. İlk deneme Birleşik Yöntemin 0.8 sürümü(Birleşik Yöntem), o zamanki adıyla, ortaya çıktı. Ekim 1995 . Aynı zamanda, Jacobson Rational'a geçti ve UML projesi OOSE'yi içerecek şekilde genişletildi. ortak çabalar sonucunda Haziran 1996 ortaya çıktı UML sürüm 0.9. Yaratıcılar, yıl boyunca büyük yazılım mühendisliği şirketlerinden geri bildirim topladılar. Bu süre zarfında, bu şirketlerin çoğunun UML'yi işletmeleri için stratejik öneme sahip bir dil olarak gördükleri ortaya çıktı. Sonuç olarak, UML'nin tam bir tanımı için çalışmak için kaynaklara katkıda bulunmak isteyen kuruluşları içeren bir UML konsorsiyumu kuruldu.

Dil sürümü 1.0 Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments ve Unisys'in ortak çabalarının bir sonucu olarak ortaya çıktı. UML 1.0çok çeşitli görevlere uygulanabilen, iyi tanımlanmış, etkileyici, güçlü bir dil olduğu ortaya çıktı. Ocak 1997'de, standart bir modelleme dili oluşturmak için bir yarışma için Object Management Group'a (OMG) sunuldu.

Ocak ve Haziran 1997 arasında, UML konsorsiyumu, Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software ve Taskon gibi OMG çağrısına yanıt veren hemen hemen her şirketi kapsayacak şekilde genişledi. UML spesifikasyonlarını resmileştirmek ve diğer standart gruplarıyla koordine etmek için Semantik Grup, MCI Systemhouse'dan Cris Kobryn ve Rational'den Ed Eykholt liderliğinde kuruldu. UML'nin (1.1) gözden geçirilmiş bir versiyonu Temmuz 1997'de tekrar OMG'ye sunuldu. Eylül ayında, Analiz ve Tasarım Grubu ve OMG Mimarlık Komitesi toplantılarında sürüm onaylandı ve 14 Kasım 1997'de tüm OMG üyelerinin genel toplantısında standart olarak kabul edildi.

UML'nin geliştirilmesiyle ilgili daha fazla çalışma, Chris Kobrin liderliğindeki OMG Revizyon Görev Gücü (RTF) tarafından gerçekleştirildi. AT Haziran 1998 UML 1.2 yayınlandı ve sonbahar 1998– UML 1.3.

UML modelleme dili

UML(Birleşik Modelleme Dili), yazılım geliştirme alanında nesne modelleme için bir grafik tanımlama dilidir. Bir sistem modeli oluşturmak için grafik gösterimi kullanır. Bu dil, yazılım sistemlerini tanımlamak, görselleştirmek, tasarlamak ve belgelemek için oluşturulmuştur ve ayrıca iş süreçlerini, sistem tasarımını modellemek için de kullanılır.

Birleşik Modelleme Dili UML'nin Açıklaması

UML'nin Kısa Tarihi (Yaratıcılar: Grady Kasap, Ivar Jacobson ve James Rambo)

UML'nin kavramsal modeli (kavramsal model şunları içerir: dilin temel yapı taşları; bunların birleşimi için kurallar; tüm dil için ortak olan bazı mekanizmalar)

Modelleme için diyagram türleri:

Durum diyagramlarını kullanın (sistemin işlevsel amacını veya sistemin ne yapması gerektiğini açıklar)

Sınıf diyagramları (nesne yönelimli programlama sınıflarının terminolojisinde bir sistem modelinin statik yapısını temsil etmek için kullanılır; bu tür diyagramlar, nesneler ve alt sistemler gibi konu alanının tek tek varlıkları arasındaki çeşitli ilişkileri yansıtabilir ve bunların iç yapılarını tanımlayabilir. ve ilişki türleri)

Etkileşim diyagramları (sistemdeki nesneler arasındaki etkileşimi tanımlar ve iki ana diyagram türüne ayrılır: sıra diyagramları ve işbirlikçi diyagramlar)

Durum diyagramları (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ımlamak için kullanılır, yani bir nesnenin durumundaki tüm değişiklikleri dış etkilere tepkisi olarak modeller)

Faaliyet diyagramları (işlemleri gerçekleştirme sürecini modellemek için kullanılır)

Uygulama diyagramları (sistemin bileşenlerini temsil eder ve fiziksel modeline atıfta bulunur)

Bileşen diyagramları (sistemin fiziksel temsilinin özelliklerini açıklar ve 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 belirlemenizi sağlar)

Yerleşim diyagramları (sistemin yazılım ve donanım bileşenleri arasındaki fiziksel ilişkileri yansıtır ve ayrıca dağıtılmış bir sistemdeki nesnelerin hareket yollarını göstermek için kullanılır)

Dipnot: Bu dersin konusu UML - Birleşik Modelleme Dilidir. Bir önceki dersimizde UML'nin ne olduğundan, tarihçesinden, amacından, dili kullanma şekillerinden, tanımının yapısından, terminolojisinden ve notasyonundan bahsetmiştik. Bir UML modelinin bir dizi diyagram olduğu not edilmiştir. Bu derste şu soruları ele alacağız: neden birkaç tür diyagrama ihtiyacımız var; diyagram türleri; OOP ve sıra diyagramı

Bu dersin ana materyalinin tartışmasına geçmeden önce, neden herhangi bir diyagram oluşturduğunu konuşalım. Herhangi bir sistemin (yalnızca yazılımın değil) modelinin geliştirilmesi, her zaman oluşturulmasından veya güncellenmesinden önce gelir. Bu, en azından sorunun çözülmekte olduğunu daha net bir şekilde hayal etmek için gereklidir. Düşünceli modeller, hem geliştirme ekibi içindeki etkileşim için hem de müşteri ile karşılıklı anlayış için çok önemlidir. Sonuçta, kodda uygulanmadan önce projenin "mimari olarak tutarlı" olduğundan emin olmanızı sağlar.

Karmaşık sistemlerin modellerini oluşturuyoruz çünkü onları tam olarak tanımlayamayız, "bir bakışta onlara bir göz atın". Bu nedenle, yalnızca belirli bir görev için gerekli olan sistemin özelliklerini seçiyor ve bu özellikleri yansıtan modelini oluşturuyoruz. Nesneye yönelik analiz yöntemi, gerçek karmaşık sistemleri en uygun şekilde tanımlamayı mümkün kılar. Ancak sistemler daha karmaşık hale geldikçe, iyi bir simülasyon teknolojisine ihtiyaç duyulmaktadır. Bir önceki derste söylediğimiz gibi, "standart" bir teknoloji olarak birleşik bir sistem kullanılır. modelleme dili(Birleşik Modelleme Dili, UML), sistemlerin belirtimi, görselleştirilmesi, tasarımı ve belgelenmesi için bir grafik dildir. UML'yi kullanarak, yalnızca konseptini değil, aynı zamanda belirli uygulama özelliklerini de yansıtan, oluşturulan sistemin ayrıntılı bir modelini geliştirebilirsiniz. UML modeli çerçevesinde sistemle ilgili tüm temsiller diyagram adı verilen özel grafik yapılar şeklinde sabitlenir.

Not. Hepsini değil, sadece bazı grafik türlerini ele alacağız. Örneğin, diyagram türlerine yalnızca kısa bir genel bakış olan bu derste bileşen diyagramı ele alınmamıştır. Belirli bir uygulama modeli için grafik türlerinin sayısı hiçbir şekilde sınırlı değildir. Basit uygulamalar için istisnasız her türden diyagram oluşturmaya gerek yoktur. Bazıları basitçe eksik olabilir ve bu gerçek bir hata olarak kabul edilmeyecektir. Belirli bir türdeki diyagramların mevcudiyetinin belirli bir projenin özelliklerine bağlı olduğunu anlamak önemlidir. Diğer (burada tartışılmayan) diyagram türleri hakkında bilgiler UML standardında bulunabilir.

Neden Birden Fazla Grafik Türüne İhtiyacınız Var?

Önce terminolojiyi tanımlayalım. Bu dersin önsözünde sistem, model ve diyagram kavramlarını tekrar tekrar kullandık. Yazar, her birimizin bu kavramların anlamını sezgisel olarak anladığımızdan emindir, ancak bunu tamamen açıklığa kavuşturmak için sözlüğe tekrar bakalım ve aşağıdakileri okuyalım:

sistem- ortak bir işleyiş amacı ile birleştirilmiş bir dizi birbirine bağlı kontrollü alt sistem.

Evet, çok bilgilendirici değil. O zaman alt sistem nedir? Durumu netleştirmek için klasiklere dönelim:

sistem Belirli bir amaca ulaşmak için düzenlenen ve muhtemelen farklı bakış açılarından bir dizi model kullanılarak tanımlanan bir dizi alt sistem olarak adlandırılır.

Eh, yapabileceğiniz bir şey yok, bir alt sistemin tanımını aramanız gerekiyor. orada da yazıyor alt sistem bazıları diğer öğelerin davranışını belirleyen bir dizi öğedir. Ian Sommerville kavramı şu şekilde açıklıyor:

alt sistem işleyişi diğer alt sistemlerin hizmetlerine bağlı olmayan bir sistemdir. Yazılım sistemi, bir dizi nispeten bağımsız alt sistem olarak yapılandırılmıştır. Alt sistemler arasındaki etkileşimler de tanımlanır.

Ayrıca çok net değil, ama daha iyi. "İnsan" dilinde konuşan sistem, nispeten kendi kendine yeterli olan bir dizi daha basit varlık olarak temsil edilir. Bu, bir program geliştirme sürecinde standart "küplerden" - görsel bileşenlerden nasıl bir grafik arabirim oluşturduğumuzla veya program metninin kendisinin de bir işlevselliğe göre birleştirilen alt rutinleri içeren modüllere nasıl bölündüğüyle karşılaştırılabilir. özelliğidir ve aşağıdaki programlarda yeniden kullanılabilirler.

Sistem kavramını anlayın. Tasarım sürecinde sistem göz önünde bulundurulur. farklı bakış açılarındançeşitli temsilleri diyagramlar şeklinde görünen modeller yardımıyla. Yine, okuyucunun kavramların anlamı hakkında soruları olabilir. modeller ve diyagramlar. Güzel ama çok net olmayan bir tanım düşünüyoruz anlamsal olarak kapalı bir sistem soyutlaması olarak modeller durumu açıklığa kavuşturmak pek mümkün değil, o yüzden "kendi kelimelerimizle" açıklamaya çalışalım.

modeli- bu, bu görev için sistemin yalnızca en önemli özelliklerini gösteren belirli bir (maddi veya değil) nesnedir. Modeller farklıdır - somut ve soyut, yapay ve doğal, dekoratif ve matematiksel...

Birkaç örnek verelim. Çocukluğumuzda büyük bir tutkuyla oynadığımız, hepimizin aşina olduğu plastik oyuncak arabalar, malzeme yapay dekoratif gerçek araba modeli Tabii ki, böyle bir "arabada" motor yok, deposunu benzinle doldurmuyoruz, şanzıman içinde çalışmıyor (ayrıca hiç yok), ancak model olarak bu oyuncak tam olarak yerine getiriyor. fonksiyonlar: çocuğa araba hakkında bir fikir verir, çünkü karakteristik özelliklerini gösterir; dört tekerleğin, bir gövdenin, kapıların, pencerelerin, araba kullanma yeteneğinin vb. varlığıdır.

Tıbbi araştırmalarda, hayvan testleri genellikle insanlarda ilaçların klinik denemelerinden önce gelir. Bu durumda, hayvan gibi davranır. malzeme doğal insan modelleri.

Yukarıda gösterilen denklem de bir modeldir, ancak bu matematiksel bir modeldir ve maddesel bir noktanın yerçekimi etkisi altındaki hareketini tanımlar.

Sadece bir diyagramın ne olduğunu söylemek için kalır. Diyagram bir dizi öğenin grafiksel bir temsilidir. Genellikle köşeleri (varlıklar) ve kenarları (ilişkileri) olan bir grafik olarak gösterilir. Birçok diyagram örneği vardır. Bu, okul yıllarından hepimizin aşina olduğu bir blok diyagram ve kullanım kılavuzlarında görebildiğimiz çeşitli ekipmanların kurulum şemaları ve bir disk üzerinde ağaç komutunu çalıştırarak görebileceğimiz bir dosya ve dizin ağacıdır. Windows konsolu ve çok daha fazlası. Günlük yaşamda diyagramlar bizi her yönden kuşatır, çünkü bir resmi algılamak bizim için bir metinden daha kolaydır...

Ancak yazılım tasarımına geri dönelim (ve sadece değil). beri bu sektörde diyagramları kullanarak sistemi farklı bakış açılarından görselleştirebilirsiniz.. Örneğin diyagramlardan biri, kullanıcının sistemle etkileşimini, diğeri - sistemin çalışması sırasında sistemin durumlarındaki değişimi, üçüncüsü - sistemin öğeleri arasındaki etkileşimi vb. Tanımlayabilir. Bir karmaşık sistem bir dizi küçük ve neredeyse bağımsız model - diyagramlar olarak temsil edilebilir ve gösterilmelidir ve bunların hiçbiri sistemi tanımlamak ve sistemin tam bir resmini elde etmek için yeterli değildir, çünkü her biri sistemin işleyişinin belirli bir yönüne odaklanmaktadır. sistem ve farklı bir ifade soyutlama seviyesi. Başka bir deyişle, her model, tasarlanan sistemle ilgili belirli, belirli bir bakış açısına karşılık gelir.

Bir önceki paragrafta model kavramı konusunda çok gevşek olmamıza rağmen, yukarıdaki tanımlar bağlamında anlaşılmalıdır. tek bir diyagram bir model değildir. Diyagramlar sadece modeli görselleştirmenin bir yoludur ve ikisi birbirinden ayrılmalıdır. Bir tek bir dizi diyagram bir sistem modeli oluşturur ve onu en eksiksiz şekilde açıklar, ancak bağlamdan çıkarılmış bir diyagram değildir.

Grafik türleri

UML 1.5 tanımlı on iki tür çizelgeüç gruba ayrılır:

• dört tür diyagram uygulamanın statik yapısını temsil eder;
• beşi sistemin davranışsal yönlerini temsil eder;
• üçü sistem çalışmasının fiziksel yönlerini temsil eder (uygulama şemaları).

UML 2.1'in mevcut sürümü çok fazla değişiklik yapmadı. Diyagramların görünümü biraz değişti (çerçeveler ve diğer görsel iyileştirmeler ortaya çıktı), gösterim biraz iyileşti, bazı diyagramlar yeni isimler aldı.

Ancak tam sayı kanonik diyagramlar bu bizim için kesinlikle önemsizdir, çünkü hepsini değil, sadece bazılarını ele alacağız - belirli bir uygulamanın belirli bir modeli için diyagram türlerinin sayısının kesin olarak sabit olmaması nedeniyle. Basit uygulamalar için istisnasız tüm diyagramları oluşturmaya gerek yoktur. Örneğin, yerel bir uygulama için bir dağıtım şeması oluşturmak gerekli değildir. Diyagram listesinin geliştirilmekte olan projenin özelliklerine bağlı olduğunu ve geliştiricinin kendisi tarafından belirlendiğini anlamak önemlidir. Meraklı okuyucu hala tüm UML diyagramları hakkında bilgi edinmek istiyorsa, onu UML standardına yönlendireceğiz (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Bu kursun amacının kesinlikle UML'nin tüm olanaklarını anlatmak değil, sadece bu dili tanıtmak, bu teknoloji hakkında bir ön fikir vermek olduğunu hatırlayın.

Bu nedenle, aşağıdaki gibi çizelge türlerine kısaca bakacağız:

• durum şemasını kullan;
• sınıf diyagramı;
• nesne diyagramı;
• dizi diyagramı;
• etkileşim diyagramı;
• durum diyagramı;
• etkinlik şeması;
• dağıtım şeması.

Sonraki derslerde bu diyagramlardan bazıları hakkında daha ayrıntılı olarak konuşacağız. Şimdilik ayrıntılara odaklanmayacağız, ancak okuyucuya ana diyagram türlerinin amacı hakkında ilk fikir vermek için en azından diyagram türlerini görsel olarak ayırt etmeyi öğretme hedefini belirledik. Öyleyse başlayalım.

Vaka Şemasını Kullan

Herhangi bir (yazılım dahil) sistem, çalışmaları sırasında insanlar tarafından kullanılacağı ve / veya diğer sistemlerle etkileşime gireceği gerçeği dikkate alınarak tasarlanır. Sistemin çalışması sırasında etkileşimde bulunduğu varlıklara denir. aktörler ve her aktör sistemin kesin olarak tanımlanmış, öngörülebilir bir şekilde davranmasını bekler. Bir ektörün daha kesin bir tanımını vermeye çalışalım. Bunu yapmak için UML için harika bir görsel kelime hazinesi kullanıyoruz Zicom Mentor:

Hektor (oyuncu)- bu, emsaller veya varlıklar (sistem, alt sistem veya sınıf) ile etkileşime girerken gerçekleştirilen mantıksal olarak ilişkili roller kümesidir. Bir aktör, varlığın dışında bir şeyi temsil eden bir kişi veya başka bir sistem, alt sistem veya sınıf olabilir.

Grafiksel olarak, vektör ya " küçük adam", çocuklukta çizdiklerimize benzer, ailemizin üyelerini tasvir eden veya karşılık gelen klişe ile sınıf sembolü, resimde gösterildiği gibi. Her iki sunum biçimi de aynı anlama sahiptir ve diyagramlarda kullanılabilir. "Stereotipleştirilmiş" form daha çok sistem aktörlerini temsil etmek için veya aktörün gösterilmesi gereken özelliklere sahip olduğu durumlarda kullanılır (Şekil 2.1).

Dikkatli okuyucu hemen şu soruyu sorabilir: Hector neden oyuncu değil de?? Katılıyoruz, "ektor" kelimesi bir Rus insanının kulağını biraz keser. Bunu söylememizin nedeni basit - ector kelimesinden oluşuyor eylem, yani çeviride eylem. "Ektor" kelimesinin gerçek çevirisi - aktör- çok uzun ve kullanımı rahatsız edici. Bu nedenle, söylemeye devam edeceğiz.

Aynı dikkatli okuyucu, ector tanımında "emsal" kelimesinin parladığını fark edebilir. Bu ne? Şimdi bahsettiğimizi hatırlarsak, bu soru bizi daha da ilgilendirecektir. durum şemasını kullan. Böyle,

Emsal (kullanım durumu)- kullanıcının bakış açısından sistem davranışının belirli bir yönünün açıklaması (Butch).

Tanım oldukça anlaşılır ve kapsamlıdır, ancak aynı tanım kullanılarak daha da geliştirilebilir. Zicom Mentor"öm:

kullanım durumu- aktör tarafından gözlemlenen sonuca yol açan, sistem tarafından gerçekleştirilen ardışık olaylar dizisinin (varyantlar dahil) tanımı. Kullanım durumu, aktörler ve sistem arasındaki etkileşimi tanımlayarak bir varlığın davranışını temsil eder. Bir emsal, belirli bir sonucun "nasıl" elde edildiğini değil, sadece "ne" olduğunu gösterir.

Emsaller çok basit bir şekilde belirtilir - içinde adının belirtildiği bir elips şeklinde. Kullanım durumları ve aktörler çizgilerle birbirine bağlıdır. Genellikle satırın bir ucunda pirinç tasvir edilir. 2.3

Bir organizasyonun işini anlatmak gibi bir görevle karşı karşıyaysanız, elinizde çok miktarda düzensiz bilgi var demektir. Kayboldunuz ve tüm bunlara hangi taraftan yaklaşacağınızı bilmiyorsunuz, aşağıdaki eylem dizisini tavsiye ediyorum:

2. Ne tür bir iş süreci modeli oluşturmanız gerektiğini belirleyin ve modellemede kullanılabilecek metodolojilerin bir listesini seçin (aşağıdaki kılavuzu kullanın);

3. Model türünüz için modelleme metodolojilerini ve notasyonları karşılaştırın ve size uygun metodolojiyi seçin:

• Üst düzey iş süreçlerini ve veri akışlarını modellemek için metodolojiler;
• İş akışlarını modelleme metodolojileri;
• Bilgi yapısını modellemek için metodolojiler.

4. Modeli oluşturun.

Gösterimler ve Metodolojiler Kılavuzu

En yaygın organizasyon modellerini (yönetim modelleri - en üst düzeyde iş süreçleri, iş akışı ve bilgi modeli modelleri - bilgi yapısı) oluşturmak için kullanılan her türlü metodoloji ve notasyonda kafanız karışmaması için bir rehber ve onun yapısını sunuyorum. daha fazla detaylandırma.

Klasik Metodolojiler

Esas olarak diyagramların adı ve kullanılan nesne türleri ile ilgili farklılıklarına rağmen, iş süreçlerini tanımlamaya yönelik modern metodolojiler neredeyse aynıdır ve klasik standartlarda küçük değişiklikleri temsil eder.