“Bir sincabın hayatında bir gün” veya süreç modellemesinden otomatik servet muhasebesi sistemi “Belka-1.0” tasarımına kadar (Bölüm 2)
Önceki bölümün özeti
В Peri masalı konularına dayalı UML diyagramlarını öğrenme örneklerinden esinlenerek bir "peri masalı" alanı kullandık (örneğin bkz. [1]). Modelleme başlamadan önce Faaliyet diyagramının bazı unsurlarının kullanılması konusunda anlaştık ve bir modelleme sözleşmesi oluşturmaya başladık. Bu anlaşmaları dikkate alarak 1. aşamada Faaliyet diyagramları şeklinde süreci anlattık, 2. aşamada otomasyonun gerekli (ve mümkün) süreç adımlarını belirledik.
Bu süreçlerde ortaya çıkan maddi varlıkların muhasebeleştirilmesi faaliyetini otomatize edeceğimizi hatırlatayım.
...
Denizin üzerinde bir ada yatıyor, (E1, E2)
Adada dolu var (E3, E1)
Altın kubbeli kiliselerle (E4)
Kuleleri ve bahçeleri ile; (E5, E6)
Sarayın önünde bir ladin ağacı yetişiyor, (E7, E8)
Onun altında da kristal bir ev var; (E9)
Orada evcil bir sincap yaşıyor (A1)
Evet, ne macera! (A1)
Sincap şarkı söylüyor, (K1, A1)
Evet sürekli fındık kemiriyor (K2)
Ama fındıklar basit değil, (C1)
Tüm kabuklar altındır, (C2)
Çekirdek saf zümrüttür; (C3)
Hizmetçiler sincabı koruyor, (K3, A2)
Ona çeşitli hizmetçiler olarak hizmet ediyorlar (K4)
Ve bir katip atandı (A3)
Haberlerde fındıklarla ilgili katı bir açıklama var; (P5, C1)
Ordu onu selamlıyor; (P6, A4)
Kabuklardan bir para dökülüyor (P7, C2, C4)
Bırakın dünyayı dolaşsınlar; (P8)
Kızlar zümrüt döküyor (P9, A5, C3)
Depolara ve örtü altına; (E10, E11)
...
(A.S. Puşkin “Çar Saltan'ın, şanlı ve kudretli kahramanı Prens Guidon Saltanovich ve güzel Prenses Kuğu'nun Hikayesi”, )
Bu örnekte, bir Avustralya şirketinden Enterprise Architect ortamını kullanıyorum. [2] ve eğitim oturumları sırasında kullanıyorum [3].
Farklı süreçler olduğunu hatırlatayım, tanışabilirsiniz mesela, [4] ve [5].
Modelleme ve tasarıma uygulanan uygulamalı yaklaşımlar hakkında daha fazla ayrıntı için bkz. [6, 7].
Tüm UML spesifikasyonu için bkz. [8].
Artık sonraki adımlara geçmeye ve sistemin işlevselliğini ve iç organizasyonunu tasarlamaya başlamaya hazırız. Çizimlerin numaralandırılmasına devam edilecektir.
Aşama 3. Otomatik adım, sistemin bir işlevi veya işlevleriyle ilişkilendirilmelidir
Geliştirilmekte olan otomatik sistem (AS), fındıkların sıkı kayıtlarını tutacak şekilde tasarlanmıştır, hatırladınız mı? Vurgulanan her adım için (bkz. Şekil 3, Şekil 4 Otomatikleştireceğimiz ), yaklaşık olarak aşağıdaki yapıyı kullanarak işlevsel bir gereksinimi yazın: "Sistem yeteneği uygulamalıdır..." ve bir Kullanım senaryosu diyagramı geliştirin. Artık aslında modelleme anlaşmamıza yeni kurallar ekliyoruz. Hangi unsurları kullanacağımızı açıklayayım.
“Kullanıcı Rolü” ile “Fonksiyon” arasında “İlişkilendirme” bağlantısını kullanacağız (Şekil 5), yani bu role sahip bir kullanıcı bu fonksiyonu gerçekleştirebilir.
Şekil 5. İlişkilendirme türü bir ilişki kullanma
"Fonksiyon"dan "Gereksinim"e, bu gereksinimin bu işlevler tarafından uygulanacağını göstermek için "Uygulama" bağlantısını (Şekil 6) çizeceğiz; ilişki "çoka çok" olabilir, yani. Bir fonksiyon birden fazla gereksinimin uygulanmasında rol oynayabilir ve bir gereksinimin uygulanması için birden fazla fonksiyona ihtiyaç duyulabilir.
Şekil 6. “Uygulama” tipi ilişkinin kullanılması
Bir işlevin yürütülmesi için başka bir işlevin yürütülmesi gerekiyorsa ve zorunlu olarak "Dahil Et" stereotipiyle "Bağımlılık" bağlantısını kullanacağız (Şekil 7). Belirli koşullar altında ek bir işlevin yürütülmesi gerekiyorsa, o zaman "Genişlet" stereotipiyle "Bağımlılık" bağlantısını kullanacağız. Her şeyin hatırlanması çok kolaydır: "Dahil Et" HER ZAMAN ve "Genişlet" BAZEN'dir.
Şekil 7. “Bağımlılık (dahil etme)” ilişkisini kullanma
Sonuç olarak diyagramımız şuna benzer (Şekil 8).
Şekil 8. Kullanım senaryosu diyagramı (AC'nin işlevsel modeli)
Ayrıca kullanıcı rollerini modellemek için bir Kullanım senaryosu diyagramı kullanılır (Şekil 9).
Şekil 9. Kullanım senaryosu diyagramı (AS kullanıcılarının rolleri)
Aşama 4. AS'nin iç organizasyonunu bir sınıf diyagramı kullanarak tanımlayalım
Sürecimizin girdi ve çıktı eserleri hakkındaki bilgileri kullanarak (bkz. Etkinlik diyagramları - Şekil 2, Şekil 3, Şekil 4), bir sınıf diyagramı geliştireceğiz. “Sınıf” modelleme elemanlarını ve aralarındaki çeşitli bağlantı türlerini kullanacağız.
"Bütün-parça" ilişkisini göstermek için "Toplama" tipinde bir ilişki kullanacağız (Şekil 10): fındık bütündür, kabuklar ve çekirdek ise parçalardır.
Şekil 10. Bütün-parça ilişkisi
Sonuç olarak diyagramımızın bir parçası şunun gibi görünecektir (Şekil 11). Sürecin metin açıklamasında doğrudan vurguladığımız sınıflar renkli olarak işaretlenmiştir.
Şekil 11. Sınıf diyagramı
Sınıf diyagramı aynı zamanda diğer eserleri modellemek için de kullanıldı - yalnızca maddi varlıkların otomatik muhasebe sürecinin kavramsal modeliyle ilgili olanlar değil, aynı zamanda yürütme ortamı - çevre (Şekil 12) ve "komşu" ile de ilgili olanlar. Otomatik süreci etkileyebilecek ancak henüz ilgi odağımızda olmayan süreçler (Şekil 13) (sistemin gelişeceğini ve bu bilgilerin faydalı olacağını varsayıyoruz).
Şekil 12. Sınıf diyagramı (ortam)
Miras ilişkisi, çeşitli binaların, “çocuk” sınıflarının genelleştirici “ana” sınıfı “Bina” altında genelleştirilmesini gösterir.
Şekil 13. Sınıf diyagramı (yapılar hakkında ek bilgi)
“Duruma tepki” “Görsel kontrol verilerine” bağlıdır. Çeşitli bağımlılık ilişkileri için "izleme" stereotipi, süreç açıklamasında açıkça tanımlanmayan ancak bunu otomatikleştirmek için gerekli olan sınıfların, açıklamamızda örneklerine açıkça atıfta bulunulan sınıflara izlenmesini göstermek için kullanılır.
5. Aşama. “İş Kuralları” yolundaki notları inceleyelim
Kurallar belirtildi (bkz. Şekil 2) ):
- adımlardan birini 2 parçaya ayırma ihtiyacı, ikinci bölüm yalnızca belirli koşullar altında yürütülmeye başlar;
- fındık muhasebesini yürütmek üzere belirli bir yetkilinin atanması;
- elemanın süreç açıklamasında açıkça belirtilmediğini gösteren bir teknik (öğelerin beyaz rengi).
Diyagramları geliştirirken tüm bu kuralları zaten kullandığımızı belirtmekte fayda var.
Son açıklamalar
Böylece 5 aşamadan geçtik ve 3 tür diyagram oluşturduk. Modellerimizin modelleme ortamındaki organizasyonu hakkında küçük bir yorum ekleyeceğim. Geliştirilmekte olan modellerin yapılandırılmasına yardımcı olan çok sayıda çerçeve vardır ancak bu makalenin konusu bu değildir, dolayısıyla projemizin düzenli yönetimi için kendimizi aşağıdaki basit paketlerle sınırlayacağız: İş Süreci, Fonksiyonel Model , Eserler, Katılımcılar ve Çevre (Şekil 14).
Şekil 14. Proje paketi yapısı
Böylece, maddi muhasebe sistemini çeşitli yönlerden tanımlayan tutarlı modeller geliştirdik: otomatikleştirilmiş bir iş süreci modeli, işlevsel bir model ve kavramsal düzeyde sistemin iç organizasyon modeli.
Kaynakların listesi
- Web sitesi "UML2.ru". Analist Topluluğu Forumu. Genel bölüm. Örnekler. UML diyagramları olarak biçimlendirilmiş masal örnekleri. [Elektronik kaynak] Erişim modu: İnternet:
- Sparx Sistemleri web sitesi. [Elektronik kaynak] Erişim modu: İnternet:
- Modelio web sitesi. [Elektronik kaynak] Erişim modu: İnternet:
- Büyük Ansiklopedik Sözlük. Süreç (yorumlama). [Elektronik kaynak] Erişim modu: İnternet:
- Web sitesi "Etkili Yönetim Organizasyonu". Blog. Kategori "İş Süreci Yönetimi". Bir iş sürecinin tanımı. [Elektronik kaynak] Erişim modu: İnternet:
- Fikri faaliyet eserinin tescili ve tevdii hakkında 18249 numaralı sertifika. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. “Enterprise Architect kullanarak bir konu alanının modellenmesi” başlıklı bir öğretim yardımının taslağı // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. İş süreci modellemesi. — M .: KURS, SIC INFRA-M, EBS Znanium.com. — 2017.
- OMG Birleşik Modelleme Dili (OMG UML) Spesifikasyonu. Sürüm 2.5.1. [Elektronik kaynak] Erişim modu: İnternet:
Kaynak: habr.com