“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 1)
"Sincap"ın bununla ne alakası var?
"Sincap"ın bununla ne alakası olduğunu hemen açıklayacağım. İnternette peri masallarından alınan bir konu alanına dayalı UML öğrenmek için eğlenceli projelere rastlamak (örneğin, [1]), öğrencilerimin başlangıçta yalnızca üç tür diyagramı çalışabilmeleri için benzer bir örnek hazırlamaya karar verdim: Etkinlik Diyagramı, Kullanım Durumu Diyagramı ve Sınıf Diyagramı. “Çeviri zorlukları” konusundaki anlaşmazlıkları önlemek için diyagramların adlarını kasıtlı olarak Rusçaya çevirmiyorum. Ne olduğunu biraz sonra açıklayacağım. Bu örnekte Avustralyalı bir şirketin Enterprise Architect çerçevesini kullanıyorum [2] – makul bir fiyata iyi bir araç. Ve eğitim oturumlarımın bir parçası olarak kullanıyorum [3], UML2.0 ve BPMN standartlarını destekleyen, görsel yetenekler açısından gereksiz zil ve ıslıklar olmadan, ancak dilin temellerini öğrenmek için oldukça yeterli olan iyi bir ücretsiz nesne yönelimli tasarım aracıdır.
Bu süreçlerde ortaya çıkan maddi varlıkların muhasebeleştirilmesi faaliyetini otomatize edeceğiz.
...
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 arada konseptten yayına kadar 10 yıl!)
Satırların sağında yazılan kodlar hakkında biraz. “A” (“Aktör”den), satırın süreçteki bir katılımcı hakkında bilgi içerdiği anlamına gelir. “C” (“Sınıf”tan) – süreçlerin yürütülmesi sırasında işlenen sınıf nesneleri hakkında bilgi. “E” (“Ortam”dan) – süreçlerin yürütülmesi için ortamı karakterize eden sınıf nesneleri hakkında bilgi. “P” (“Süreç”ten) – süreçlerin kendisi hakkında bilgi.
Bu arada, bir sürecin kesin tanımının, yalnızca farklı süreçlerin olması nedeniyle de olsa, metodolojik anlaşmazlıkların nedeni olduğu iddia ediliyor: iş, üretim, teknolojik vb. ve benzeri. (örneğin, öğrenebilirsiniz, [4] ve [5]). Tartışmayı önlemek için şunu kabul edelim: Süreçle zaman içinde tekrarlanabilirliği ve otomasyon ihtiyacı açısından ilgileniyoruzyani Proses operasyonlarının herhangi bir kısmının yürütülmesinin otomatik bir sisteme aktarılması.
Etkinlik diyagramının kullanımına ilişkin notlar
Sürecimizi modellemeye başlayalım ve bunun için Activity diyagramını kullanalım. Öncelikle yukarıdaki kodların modelde nasıl kullanılacağını anlatayım. Grafik bir örnekle açıklamak daha kolaydır, ancak aynı zamanda Etkinlik diyagramının bazı (ihtiyacımız olanların neredeyse tamamını) öğelerini analiz edeceğiz.
Aşağıdaki parçayı analiz edelim:
...
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)
...
P1 ve P2 olmak üzere iki süreç adımımız, A1 katılımcımız ve üç farklı sınıfa ait nesnelerimiz var: C1 sınıfından bir nesne adıma girdidir, C2 ve C3 sınıflarından nesneler P2 adımının aktivitesinin bir sonucu olarak çıktı olarak sunulur. işlem. Diyagram için aşağıdaki modelleme elemanlarını kullanıyoruz.
Sürecimizin bir parçası buna benzer bir şekilde temsil edilebilir (Şekil 1).
Şekil 1. Etkinlik diyagramı parçası
Alanı düzenlemek ve Etkinlik diyagramını yapılandırmak için, UML gösteriminin klasik kullanımı açısından standart olmayan bir yaklaşım kullanacağız. Ancak bunun birkaç nedeni var. İlk olarak, modellemeye başlamadan hemen önce sözde derleyeceğiz. modelleme anlaşmasıGösterimi kullanmanın tüm özelliklerini kaydettiğimiz. İkincisi, bu yaklaşım, yazılım sistemleri oluşturmak için gerçek projelerde iş modelleme aşamasında defalarca başarıyla uygulandı; sonuçlar, küçük yazar ekibimiz tarafından ilgili telif hakkı nesnesine [6] kaydedildi ve ayrıca bir eğitim kılavuzunda da kullanıldı [7]. XNUMX]. Aktivite diyagramı için diyagram alanının “yüzme şeritleri” kullanılarak yapılandırıldığını tanımlıyoruz. Parça adı, o parçaya yerleştirilecek grafik öğelerinin türüne karşılık gelecektir.
"Giriş ve çıkış eserleri": Bu parça, kullanılan veya bazı işlem adımlarının yürütülmesinin sonucu olan Nesneler öğelerini içerecektir.
"İşlem adımları": Burada Etkinlik öğelerini (süreç katılımcılarının eylemleri) yerleştireceğiz.
"Katılımcılar": sürecimizdeki eylem uygulayıcılarının rollerini belirtecek öğeler için bir yol; onlar için aynı modelleme öğesi olan Object'i kullanacağız - bir nesne, ancak buna "Aktör" stereotipini ekleyeceğiz.
Bir sonraki parçanın adı "İş kuralları" ve bu parçaya, sürecin adımlarını yürütmek için kuralları metin biçiminde yerleştireceğiz ve bunun için Not modelleme öğesini - bir notu kullanacağız.
Burada duracağız ama yolu da kullanabiliriz "Araçlar" Süreç otomasyonunun düzeyi hakkında bilgi toplamak. Bir yol da işe yarayabilir "Katılımcıların pozisyonları ve bölümleri"Rolleri süreç katılımcılarının pozisyonlarına ve departmanlarına bağlamak için kullanılabilir.
Az önce anlattığım her şey bir parça modelleme kurallarıAnlaşmanın bu kısmı, bir diyagramı düzenleme kuralları ve buna bağlı olarak onu yazma ve okuma kuralları ile ilgilidir.
"Yemek tarifi"
Şimdi sistemi özel olarak modelleme seçeneğini ele alalım Etkinlik diyagramından. Bu seçeneklerden sadece biri, elbette tek olmadığını belirtmek isterim. Etkinlik diyagramı, süreç modellemeden otomatik sistem tasarımına geçişteki rolü açısından bizi ilgilendirecektir. Bunu yapmak için, yalnızca beş aşamadan oluşan ve yalnızca üç tür diyagramın geliştirilmesini sağlayan bir tür tarif olan metodolojik önerilere bağlı kalacağız. Bu tarifi kullanmak, otomatikleştirmek istediğimiz sürecin resmileştirilmiş bir tanımını elde etmemize ve sistem tasarımı için veri toplamamıza yardımcı olacaktır. Ve UML eğitiminin başlangıcındaki öğrenciler için bu, UML'de ve modern modelleme araçlarında bulunan tüm çeşitli görsel araç ve teknikler arasında boğulmalarına izin vermeyecek bir tür can simididir.
Burada aslında tarifin kendisi var ve ardından “peri masalı” konu alanımız için oluşturulmuş şemaları takip edin.
Aşama 1. Süreci Etkinlik diyagramı şeklinde açıklıyoruz. 10'dan fazla adımı olan bir işlem için, diyagramın okunabilirliğini artırmak amacıyla işlem adımı ayrıştırma ilkesini uygulamak mantıklıdır.
Aşama 2. Nelerin otomatikleştirilebileceğini seçin (adımlar örneğin bir diyagramda vurgulanabilir).
Aşama 3. Otomatik adım, sistemin bir işlevi veya işlevleriyle ilişkilendirilmelidir (ilişki çoktan çoğa olabilir), bir Kullanım senaryosu diyagramı çizin. Bunlar sistemimizin fonksiyonlarıdır.
Aşama 4. AS'nin iç organizasyonunu bir sınıf diyagramı kullanarak tanımlayalım - Sınıf. Etkinlik diyagramındaki “Giriş ve Çıkış Nesneleri (Belgeler)” yüzme yolu, bir nesne modeli ve varlık-ilişki modeli oluşturmanın temelini oluşturur.
5. Aşama. “İş Kuralları” yolundaki notları inceleyelim, yavaş yavaş işlevsel olmayan gereksinimlere dönüşen çeşitli kısıtlamalar ve koşullar sağlarlar.
Ortaya çıkan diyagram seti (Etkinlik, Kullanım Durumu, Sınıf) bize oldukça katı bir gösterimle resmileştirilmiş bir açıklama verir; net bir okumaya sahiptir. Artık teknik spesifikasyonları geliştirebilir, gereksinim spesifikasyonlarını açıklığa kavuşturabilirsiniz, vb.
Modellemeye başlayalım.
Aşama 1. Süreci Faaliyet diyagramı şeklinde tanımlayın
Diyagram alanını “yüzme” şeritleri kullanarak yapılandırdığımızı hatırlatmak isterim; her şerit aynı türden elemanları içerir (Şekil 2). Yukarıda anlattığımız diyagram elemanlarına ek olarak ek elemanlar da kullanacağız, bunları anlatalım.
Karar (Karar), diyagramdaki sürecimizin dallanma noktasını ve birleşen iplikleri (Birleştirme) yeniden birleşme noktalarını belirtir. Geçiş koşulları geçişlerin üzerinde köşeli parantez içinde yazılmıştır.
İki senkronizör (Çatal) arasında paralel süreç dallarını göstereceğiz.
Sürecimizin yalnızca bir başlangıcı olabilir - bir giriş noktası (İlk). Ancak birkaç tamamlama (Final) olabilir, ancak bizim özel diyagramımız için geçerli değildir.
Oldukça fazla ok var, çok sayıda eleman ve bağlantıyla önce sürecin aşamalarını tanımlayabilir, ardından bu aşamaların ayrıştırmasını gerçekleştirebilirsiniz. Ancak netlik sağlamak için, "peri masalı" sürecimizi tamamen tek bir diyagramda göstermek istiyorum, elbette okların "birbirine yapışmamasını" sağlamamız gerekiyor, bağlantılı olanı doğru bir şekilde izlemek mümkün olabilir neye.
Şekil 2. Faaliyet diyagramı - sürecin genel görünümü
Çünkü Şiirsel dizelerde sürecin bazı ayrıntıları atlanmış, onarılması gerekmiş, beyaz arka plana sahip öğelerle gösteriliyor. Bu ayrıntılar, Depolama ve İşleme için Aktarma/Alma adımını ve çeşitli giriş ve çıkış yapıtlarını içerir. Bu adımın da süreci tam olarak ortaya çıkarmadığını belirtmekte fayda var çünkü iletim adımını ve alım adımını ayrı ayrı belirlememiz, hatta kabuklar için ayrı bir adım eklememiz ve ayrıca öncelikle tüm bu maddi değerlerin geçici olarak bir yerde saklanması gerektiğini vb. düşünmemiz gerekir. ve benzeri.
Ayrıca fındıkların kökeni sorusunun cevapsız kaldığını da belirtelim - nereden geliyorlar ve sincaplara nasıl ulaşıyorlar? Ve bu soru (notta kırmızı yazı tipiyle vurgulanmıştır - Not öğesi) ayrı bir çalışma gerektirir! Bir analist bu şekilde çalışır - parça parça bilgi toplar, varsayımlarda bulunur ve konunun uzmanlarından "tamam" veya "tamam değil" alır - sistemler oluştururken iş modelleme aşamasında çok önemli ve basitçe yeri doldurulamaz insanlar.
Ayrıca işlem adımı P5'in iki bölümden oluştuğunu unutmayın.
Ve her bir parçayı ayrıştırıp daha ayrıntılı olarak ele alacağız (Şekil 3, Şekil 4), çünkü bu belirli adımlarda gerçekleştirilen faaliyetler otomatikleştirilecektir.
Şekil 3. Etkinlik şeması – detaylandırma (bölüm 1)
Şekil 4. Etkinlik şeması – detaylandırma (bölüm 2)
Aşama 2. Nelerin otomatikleştirilebileceğini seçin
Otomatikleştirilecek adımlar diyagramlarda renkli olarak vurgulanmıştır (bkz. Şekil 3, Şekil 4).
Hepsi süreçteki bir katılımcı tarafından gerçekleştirilir - Katip:
- Fındığın ağırlığına ilişkin bilgiyi beyana girer;
- Fındığın aktarımına ilişkin bilgileri ekstreye girer;
- Bir cevizin kabuğa ve çekirdeğe dönüştüğü gerçeğini kaydeder;
- Fındık çekirdeğine ilişkin bilgiyi ifadeye girer;
- Listeye fındık kabukları ile ilgili bilgileri girer.
Yapılan işin analizi. Sıradaki ne?
Bu nedenle pek çok hazırlık çalışması yaptık: Otomatikleştireceğimiz süreç hakkında bilgi topladık; modelleme konusunda bir anlaşma yapılmaya başlandı (şu ana kadar sadece Faaliyet diyagramının kullanılması açısından); sürecin bir simülasyonunu gerçekleştirdi ve hatta birkaç adımını ayrıştırdı; Otomatize edeceğimiz süreç adımlarını belirledik. Artık sonraki adımlara geçmeye ve sistemin işlevselliğini ve iç organizasyonunu tasarlamaya başlamaya hazırız.
Bildiğiniz gibi pratik olmadan teori hiçbir şeydir. Kesinlikle kendi ellerinizle “modellemeyi” denemelisiniz, bu aynı zamanda önerilen yaklaşımı anlamak için de faydalıdır. Örneğin, bir modelleme ortamında çalışabilirsiniz. [3]. Genel süreç diyagramının adımlarının yalnızca bir kısmını ayrıştırdık (bkz. Şekil 2). Pratik bir görev olarak, Modelio ortamındaki tüm diyagramları tekrarlamanız ve "Depolama ve İşleme için Aktarma/Alma" adımının ayrıştırmasını gerçekleştirmeniz istenebilir.
Henüz belirli modelleme ortamlarında çalışmayı düşünmüyoruz ancak bu, bağımsız makalelere ve incelemelere konu olabilir.
Yazının ikinci bölümünde 3-5. aşamalarda gerekli olan modelleme ve tasarım tekniklerini inceleyeceğiz; UML Use-case ve Class diyagramlarını kullanacağız. Devam edecek.
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.
Kaynak: habr.com