API Belgeleri¶

Ulakbus Wiki¶

Geliştiriciler¶

Ulakbus’e Katkıda Bulunmak¶

Ulakbus kaynak kod depoları, geliştiriciler tarafından yaygın şekilde kullanılan Github üzerinde bulunmaktadır. Github git kaynak kod ve sürüm takip sisteminin yanısıra, oldukça etkili proje yönetim ve geliştrici topluluğu inşa etme araçları sunmaktadır. Kolay kullanılabilir arayüzeyi sayesinde dağıtık, çok aktörlü bir yazılım geliştirme faaliyetini kolaylıkla sürdürülebilir hale getirmektedir.

Github hesabınıza giriş yaptıktan sonra, Ulakbus depolarımızı fork ederek geliştirmeye başlayabilirsiniz. Bir Github hesabınız yoksa, github.com adresinden edinebilirsiniz.

Github İş Akışı¶

Başlangıç için Github İş Akışı hakkında şu belgeye göz atmanızı şiddetle tavsiye ederiz: Understanding the GitHub Flow

Bu belgede Github üzerinde açık kaynak kodlu projelere nasıl katkı sağlayacağınıza dair bilgiler bulunmaktadır. Konua yabancı olanlar için karmaşık gözükse de, aslında oldukça basit olan süreç, bu belgede görsel bir şekilde anlatılmıştır.

Belgede adı geçen fork & pull request yöntemi, bizim de Ulakbus projesine katkı kabul etme yöntemimizdir. Bu yönteme göre geliştirme döngüsü adımları şu şekildedir:

Depoyu fork et,

Uygun bir branch açıp geliştir,

Pull request ile Ulakbus depolarına gönder

Birinci adım arayüzeyde bulunan Fork butonu yardımıyla kolaylıkla gerkeçleştirilir. Böylelikle Ulakbus kod deposunun o anki halini kendi depolarınız arasına girer. Kendinize ait bir depo olduğu için dilediğiniz gibi yönetme ve yazma hakkına sahip olursunuz.

Geliştirme faaliyeti bu adımdan sonra başlar. Aşağıda Git İpuçları ve Kod Yazma İpuçları bölümlerinde geliştirme faaliyeti süresince dikkat etmeniz gereken hususları ve Ulakbus projesi olarak beklentilerimizi okuyabilirsiniz. Bu bölümlerde yer alan kimi maddeler, genel yazılım geliştirme prensipleri ile ilgili hatırlatmalardır. Bazıları ise Ulakbus projesinin çekirdek ekibi tarafından da uygulanan, projemize özel hususlardır.

Geliştirme aşaması tamamlanan kod, fork edilen kod deposuna, başka bir ifadeyle upstream depo``ya yani Ulakbus'e ``pull request ile gönderilir.

Github üzerinde çalışmak ile ilgili daha fazla detayı şu bağlantılarda bulabilirsiniz:

Git İpuçları¶

Git’in dağıtık yapısı birlikte çalışabilirliği kolaylaştırmaktır. Öte yandan git kullanırken commit mesajları, branch isimleri, commit sıklığı ve içeriği, merge / rebase alışkanlıkları gibi usüle ilişlin konularda mümkün olduğunca ortak olmak proje yönetimini kolaylaştırmaktadır. Bu sebeple Ulakbus projesine katkı yaparken sizlere yardımcı olacak aşağıdaki ipuçlarını dikkatle okumanızı öneririz.

Git Kurulumu¶

Linux (Ubuntu): sudo apt-get install git

MacOS X: http://help.github.com/mac-git-installation/

İlk kurulumun hemen arından git’e kendinizi tanıtmayı unutmayınız:

git config --global user.name "Emo Coder"
git config --global user.email "emo@zetaops.io"

Git hakkında şu bağlantılardan detaylı bilgi alabilirsiniz:

Eğer tasarımcıysanız aşağıdaki bağlantıda tasarımcıların git kullanımı konusunda iyi bir makale bulabilirsiniz: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/

Branch Kullanmak¶

Branch kullanmayı alışkanlık haline getirin. Ana branch’e (master) doğrudan push etmeyin.

Branch adları eğer bir özellik geliştirmesi yapıyorsanız feature/, bir hata ile ilgileniyorsanız bugfix/ ön ekini taşımalıdır: feature/yeni_ozellik veya bugfix/xyz_hatasi

Branchlerinizi düzenli şekilde rebase ederek, temel branchlerdeki değişikliklerden uzaklaşmamasını sağlayınız. Ulakbus resmi depoları Git Flow kullanmaktadır. Bu sebeple Ulakbus resmi deposu temel branch’i develop adını taşır. Eğer kendi deponuza Ulakbus projesini upstream olarak eklediyseniz upstream/develop ile bu branch’e erişebilirsiniz.

Git Flow Ulakbus projesinde kullanılan branch yönetim modeli ve aracıdır. Bu modeli kullanmak yukarıda bahsedilenlerin yanısıra başka birçok faydayı beraberinde getirir. Zorunlu olmamakla birlikte, git kullanım alışkanlıklarınızı pozitif şekilde değiştireceğine inandığımız bu aracı ve metodu kullanmanı daha fazla uyumluluk için öneririz. Git Flow konusunda detaylı bilgileri bu dökümanın en altında bulabilirsiniz.

Commit Mesajları¶

Mesajlarını yazarken aşağıdaki etiketlerden faydalanabilirsiniz (bakınız: http://keepachangelog.com/):

ADD - Yapılan değişiklik yeni bir özellik ekliyorsa,

CHANGE - Mevcut bir işlevsellikte değişiklik yapılıyorsa,

DEPRECATE - daha önce mevcut olan bir özelliğin geliştirilmesinden vazgeçiliyorsa,

REMOVE - Vazgeçilen özellikler tamamen çıkarılıyorsa,

FIX - Herhangi bir hata gideriliyorsa,

SECURITY - Güvenlik ile ilgili bir değişiklik yapılıyorsa.

REFACTOR - Kod işlevsellikler değiştirilmeden optimizasyon gibi amaçlar ile değiştiriliyorsa

Commit mesajlarınızın ilk satırı mümkün olduğunca kısa ve çalışmalarınızı özetlemelidir. 50 - 70 karakter arası.

Detaylar commit summary bölümünde bulunmalıdır.

Geliştirme faaliyetleriniz için gereken tüm depolarda issue açıp, commit mesajlarınızda zetaops/ulakbusGH-145 şeklinde referanslar veriniz.

Upstream Depo Eklemek¶

Fork ettiğiniz Ulakbus deposunu kendi git deponuzun upstream deposu olarak tanımlamak, ana depodaki değişikliklere istenildiğinde daha kolay erişebilmek için faydalı olabilir. Örneğin:

git remote add upstream https://github.com/zetaops/ulakbus.git

Kendi remote deponuza origin adiyla, ulakbus depolarına da upstream adıyla erişebilirsiniz. Upstream branchleri kendi branchlerinizi rebase etmek, kod karşılaştırması yapmak, yeni geliştirilen özellikleri gözden geçirmek amacıyla kullanabilirsiniz.

git rebase upstream/master
git diff upstream/master..master
git checkout upstream/feature/yeni_ozellik

komutları ile upstream kullanabilirsiniz.

Kod Yazma İpuçları¶

İşlevselliğin yanısıra, kodun nasıl yazıldığı, ne kadar optimize yazıldığı ve dökümantasyonu oldukça önemlidir. Bu amaçla aşağıdaki ipuçları Ulakbus depolarına kod katkısı yaparken işleri herkez açısından kolaylaştıracaktır.

PEP8 Python dili için evrensel bir standarttır. Lütfen PEP8 klavuzuna uyunuz.

Kod içi dökümantasyonu Google Style Python Docstrings yönergeleri ile yapmaktayız. Nasıl kullanılacağı https://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_google.html adresinde bulunmaktadır.

ULAKBUS Geliştirme Ortamının Kurulumu¶

Ulakbus için geliştirme ortamının kurulması aşağıdaki bileşenlerin herbirinin ayrı ayrı kurulup yapılandırılmasını kapsar:

Pythton Virtualenv

Riak KV

Zato ESB

Redis

Git CVS

Bu servislerin elle kurulumu ve yapılandırılması yeni başlayanlar için biraz karmaşık gelebilir. Ayrıca biraz uzun bir süreçtir. Bu amaçla hızlı başlangıç için bir Vagrant[1] box hazırladık. Bunu indirip kullanmaya başlayabilirsiniz:

[1] https://www.vagrantup.com/

mkdir ulakbus-devbox
cd ulakbus-devbox
vagrant init zetaops/ulakbus

Vagrant box(sanal makine, guest) temel olarak iki türlü kullanılabilir:

Vagrant ile yaratılmış sanal makine içinde geliştirme
Sanal makine servislerini kullanarak kendi makinenizde geliştirme

Birincisinde backend sunucusu ve python ortamı box içindedir. Tüm geliştirme işlemleri box içinden yürütülür.

İkinci kullanımda ise box sadece Riak, Redis ve Zato gibi servisler için kullanılır. Servis portları Vagrantfile konfigürasyonu ile host makine ile paylaşılır. Böylelikle box içinde çalışan servislere host makineden erişmek mümkün hale gelir.

Python ortamı ise host makinede (kendi işletim sisteminiz üzerinde) bulunur. Bu hız ve üretkenlik açısından birincisine göre daha verimlidir. Eğer PyCharm gibi bir IDE kullanıyorsanız host makinede çalışmak, özellikle detaylı DEBUG için avantajlıdır.

Git depolarınıza her durumda host makine üzerinden erişmenizi öneririz. Host makinedeki depolarınızı box ile paylaşarak ilgili dizinlere bağlayabilirsiniz. `git pull` `git push` gibi git operasyonları da bu durumda host makine üzerinden gerçekleştirilmelidir.

Host makine üzerindeki bir git deposu üzerinde box içerisinden işlem yaptığınızda doğrulama, yetkilendirme hataları almanız olasıdır.

Hem git depolarının hem de portların nasıl paylaşılacağı aşağıda bağlantısı verilen örnek Vagrantfile icinde mevcuttur. Bu dosyada çok küçük değişiklikler yaparak istediğiniz gibi bir vagrant box (sanal makine, guest) elde edebilirsiniz. Örnek Vagrantfile:

https://raw.githubusercontent.com/zetaops/ulakbus.org/master/source/Vagrantfile.sample

Yukarıdaki komutları kullanarak bir box oluşturduğunuzda ilgili dizin altına - örnekte ulakbus-devbox - bir Vagranfile yazılır. Bu dosyayı bir text düzenleme aracı ile açıp düzenleyebilirsiniz.

Port yönlendirmek için Vagrantfile içinde aşağıdaki satırlara benzeyen bölümü bulup, istediğiniz portları ekleyip çıkarabilirsiniz:

# config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.network "forwarded_port", guest: 9001, host: 9001

Örnek dosyada hangi portun ne için kullanıldığı yorum satırları olarak eklenmiştir.

Dizinleri paylaşmak için ise Vagrantfile içerisinde aşağıdakine benzeyen bölümleri bulup düzenleyebilirsiniz:

# config.vm.synced_folder "../data", "/vagrant_data"
config.vm.synced_folder "~/dev/zetaops/ulakbus", "/app/ulakbus", owner: "ulakbus", group: "ulakbus"

Bu satır host makinenizde kullanıcı dizininiz altında, dev/zetaops/ulakbus yolunda bulunan ulakbus dizinini box içerisinde /app/ulakbus yolunda bulunan ulakbus dizinine bağlar. Box içindeki dizinin sahibi ve grubunu ulakbus yapar.

Gerekli düzenlemeleri yaptıktan sonra Vagrantbox oluşturduğunuz dizin içerisinde şu komut ile başlatabilirsiniz:

vagrant up

Başlayan makineye giriş yapmak için şu komutu kullanabilirsiniz:

vagrant ssh

Giriş yaptıktan sonra servislerin başlayıp başlamadığını, bağlanan dizinlerin güncel olup olmadığını kontrol edebilisiniz:

sudo service redis-server status
sudo service riak ping
sudo service zato status

Eğer geliştirme işlemlerini box içerisinde yapacaksanız, ulakbus kullanıcısına geçip python ortamınızı etkinleştirerek başlayabilirsiniz. En başından sırasıyla komutlar (# ile başlayan yorum kısımları olmadan):

vagrant up                         # vagrantbox başlat
vagrant ssh                        # vagrantbox giriş
sudo su - ulakbus                  # ulakbus kullanıcısına geçip home dizinine geç
source ulakbusenv/bin/activate     # ulakbus environment etkinleştir

Bu komutun ardından komut satırı promptu değişecek ve şu hale gelecektir:

(ulakbusenv)ulakbus@ulakbus:~$

Eğer deneyiminiz yoksa virtualenv ile ilgili şu bağlantılara bakabilirsiniz: virtualenv hakkında detaylı bilgi için:

http://istihza.com/forum/viewtopic.php?t=2164

http://docs.python-guide.org/en/latest/dev/virtualenvs/

Bu işlemlerin ardından ilk adım, modellerin db şemalarını senkronize etmek, belirtilen dizinden fixture dosyalarını yüklemek ve iş akışları izinlerini güncellemektir.

$ python manage.py migrate --model all

$ python manage.py load_fixture --path fixtures/

Bu işlem uzun sürebilir. Komut satırı yönetim aracı hakkında detayları ilgili belgeden öğrenebilirsiniz.

python manage.py update_permissions

Eğer geliştirmeyi kendi makinenizde yapmayı tercih ederseniz şu adımları izleyebilirsiniz:

$ virtualenv ulakbusenv                 # ulakbusenv python ortamı yarat
$ source ulakbusenv/bin/activate        # python ortamını etkinleştir
$ cd ~/ulakbus                          # ulakbus git deposuna gir
$ git pull                              # son değişiklikleri uzak depodan çek
$ pip install -r requirments.txt        # ulakbus bagimliliklarini kur
# ulakbus python kutuphane dizinine ekle
$ ln -s ~/ulakbus ~/ulakbusenv/lib/python2.7/site-packages/

Vagrant Box Güncellemek¶

Ulakbus aktif olarak geliştirilmeye devam etmektedir. Bu sebeple vagrantbox içinde kullanılan bileşenlerin sürümlerinin değişmesi, yenilerinin eklenmesi veya başka sebepler ile değişmektedir. Bu değişiklikleri https://atlas.hashicorp.com/zetaops/boxes/ulakbus adresinden takip edebilirsiniz.

Vagrantbox güncellemek isterseniz öncelikle indirdiğiniz box imajını güncellemelisiniz: Bunun için önce Vagrantfile bulunan dizine geçiniz. Bu dizinde

$ vagrant box outdated

Komutunu çalıştırıp mevcut box eski mi değil mi kontrol edin. Daha sonra mevcut box destroy edip yeniden init edebilirsiniz.

$ vagrant box destroy
$ vagrant update

İşlem bitince

$ vagrant up

Ayrıca mevcut box birden fazla sürüme sahip olabilir. --box-version ile yeni bir sürüm ekleyebilir veya mevcut sürümleri kaldırabilirsiniz:

$ vagrant box list                           # Vagrant için yüklü olan box listesi
$ vagrant box remove --box-version 0.1.9 zetaops/ulakbus   # ulakbus isimli box'ın 0.1.9 sürümünü kaldırır.

Sonraki Adımlar¶

Geliştirme ortamını başarıyla kurduktan sonra şu belgelerle devam edebilirsiniz:

Ulakbus Geliştirelim

ZEngine ile İş Akışı Temelli Uygulama Geliştirme

Ayrıca Git ve Github iş akışımız hakkında bilgi alabileceğiniz Ulakbus Depolarına Katkı Yapmak belgemize göz atabilir, geliştirme sürecimizin aktif bir parçası olabilirsiniz.

Eğer bir sorunla karşılaşırsanız, destek sayfamızda yer alan kanallardan destek alabilirsiniz. Destek için iletişim kurmadan önce lütfen sorununuzun ne olduğunu açık ve sarih olarak bildirmeniz gerektiğini unutmayınız. “- Bu çalışmıyor” şeklindeki sorularınıza alabileceğiniz en iyi cevap sessizlik olacaktır.

Nasıl soru sorulacağını akıllıca soru sorma yolları belgesinden öğrenebilirsiniz.

Kolay gelsin o/

Geliştirme Ortamı Kurulumu(Frontend)¶

Geliştirme Ortamının Hazırlanması¶

git clone git@github.com:zetaops/ulakbus-ui.git reposunu indirin.
git kullanımını bilmiyorsanız, aşağıdaki bağlantılardan yardım alabilirsiniz.
- https://git-scm.com/doc
- https://try.github.io/levels/1/challenges/1
Nodejs’yi indirin ve kurun.
- https://nodejs.org/download/
- Debian, Ubuntu, FreeBSD vs diğer dağıtımlarda kurulum için nodejs sayfasından faydalanabilirsiniz.
Bower’ı kurunuz npm install bower
bower.json içinde listelenen paketleri yüklemek için bower install komutunu çalıştırınız.
package.json içinde listelenen paketleri yüklemek için npm install komutunu çalıştırınız.
Tüm paketlerin yüklenmesininin ardından aşağıdaki komut sayesinde http server ‘ı çalıştırabilirsiniz.

npm start

Uygulamayı sunmak için başka http server kullanabilirsiniz.

Geliştirme Döngüsü¶

Şu an gerekli repo’ya sahipsiniz, npm ve bower kurulumunu gerçekleştirdiniz ve geliştirmeye başladınız.

Daha ileri programlama teknikleri kullanımları için, http://www.extremeprogramming.org/introduction.html sitesinde gösterilen geliştirme döngülerini takip etmenizi öneririz.

Kodlarken aşağıdaki adımları izleyiniz.

Yeni bir tane branch oluşturun. Örnek olarak(e.g: search_func)
git checkout <branch>
git pull --rebase
Verilen görev için bir branch oluşturup master branch’i rebase ettikten sonra, kodunuzu yazabilirsiniz.
Kodunuzu denemek için testler yazınız.
Testlerinizi çalıştırınız.
Push yapmadan önce tekrardan master branch’i rebase edin git pull --rebase
Şimdi push yapabilirsiniz git push origin <branch>

Test¶

~/_test.js dosyaları, Jasmine içindeki birim test dosyalarıdır , çalıştırmak için aşağıdaki komutları çalıştırabilirsiniz:

npm test

Bu komut testleri bulacak ve sonucu ekrana yazdıracak.

e2e-tests klasörü altındaki e2e-testlerini çalıştırmak için protractor kullanınız. Aşağıdaki komutu çalıştırabilirsiniz.

protractor e2e-tests/protractor.conf.js

Prensipler¶

Git:¶

Asla master branch üzerinde çalışmayın. İlgili issue üzerinden yeni branch açınız.
Hiçbir zaman MASTER BRANCH’e doğrudan commit etmeyin!
Bir kerede çok fazla sayıda değişiklik commit etmeyiniz. Mümkün oldukça az sayıda değişikliği commit ediniz.

Kod:¶

DRY - don’t repeat yourself(kendini tekrarlama)!!! Bunu okuyunuz. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Kodunuzu yazarken açıklamalarda bulununuz.
Kodunuz düzenli ve açık olsun.
Değişken isimleri ve nesneler açıklayıcı şekilde olmalıdır.

Test:¶

Daha etkili testler yazmak için http://www.softwaretestinghelp.com/how-to-write-effective-test-cases-test-cases-procedures-and-definitions/ sitesinden yardım alabilirsiniz.

Testler olabildiğince kodunuzu kapsamalı.

Okunması Gerekenler:¶

Ulakbüs’ü Geliştirelim¶

Aşağıdaki adımları izleyerek Ulakbüs projesine öğrencilerin ön kayıt yaptırmasını ve sonrasında öğrenci işleri personelinin gerekli belgeleri kontrol edip kayıt işlemini tamamlamasını içeren bir iş akışı için gerekli işlevleri ekleyeceğiz.

Doğrulaması için öğrenciye “Önceki Eğitim Bilgileri” gösterilir.
Doğrulaması için Puan Türü ve Puanı gösterilir.
Öğrencinin kişisel bilgilerini girebileceği bir form gösterilir.
Öğrenciye ön kayıt işleminin başarıyla tamamlandığını gösteren bilgi mesajı gösterilir.
Öğrenci işleri personeli tarafından öğrencinin getirdiği belgelerin kontrol edilerek teslim

alındığı bilgisinin sisteme girileceği “Belge Kabul” ekranı gösterilir. * Tüm belgeler tamamlanınca personelin “Onayla” düğmesine basmasıyla iş akışı tamamlanmış olur.

Geliştirme ortamının kurulumu¶

Geliştirmeye başlamak için öncelikle Camunda Modeller, git ve Vagrant araçlarına ihtiyacımız olacak. Camunda Modeller ile iş akışı diagramlarımızı hazırlayacağız. (link eklenecek) Ulakbüs projesinin parçası olarak, geliştiriciler için hazırlanan vagrant sanal makinası ile gerekli ortam hazır olarak gelmektedir. (belgeye link verilecek)

View, Task ve Model dosyalarının konumları¶

View, task ve model modülleri, proje kök dizininde yer alan views, tasks ve models dizinleri altında konumlanırlar.

İş akışlarının tasarlanması.¶

Ulakbüs projesinin üzerine inşa edildiği ZEngine frameworkü BPMN 2.0 standardıyla tanımlanmış olan iş akışı ögelerinin uygulama işlevselliği için elzem olan kısımlarını desteklemektedir. Bunlardan UserTask, ServiceTask ve Exclusive (XOR) Gateway’ler en çok kullanacağımız ögelerin başında gelmektedir.

BPMN standardı bu öglerin temel işlev ve ilişkilerini tanımlamış olsa da, iş akışlarının işletilmesi noktasında birçok tercihi uygulama geliştiricilere bırakmıştır.

Yukarıda maddelendirdiğimiz iş akışının BPMN 2.0 uyumlu bir diagram şekline getirilmiş halini aşağıda görebilirsiniz.

Öğrenci (ogrenci) lane’inin boş bir yerine tıklayarak bu lane’in özelliklerini görüntüleyebilirsiniz. Extensions bölümüne girebileceğiniz parametereler ve işlevleri aşağıda listelenmiştir.

relations parametresi iş akışında rol alan kullanıcıların birbirleri ile olan ilişkilerini kısıtlayıcı şekilde tanımlamak için kullanılır. Yukarıdaki örnekte advisor laneninin kullanıcısının student lane’inin kullanıcısının danisman ı olması gerektiği belirtilmiştir. Bu alana girilen parametrelerin geçerli Python kodu olması ve True mantıksal değerini döndürmesi gerekmektedir. Tanımlanması isteğe bağlıdır.

owners parametresi tanımlandığı lane’in olası kullanıcılarını sınırlandırmak için kullanılır. Eğer bu parametre tanımlanmış ise, sadece bu parametrede belirtilen kullanıcılara iş akışına katılmaları için mesaj gönderilecektir. Bu alan tanımlanmamış ise, lane’in iznine sahip olan tüm kullanıcılara mesaj gönderilecektir.

Örneğimizde, advisor lane’ini işletecek kişinin student lane’ini işleten kişinin danışmanı olması gerektiği kesin olarak belirtilmiştir. Bu alandaki ifadelerin “iterable” olması gerekmektedir, bu nedenle [student.ogrenci.danisman.personel] şeklinde tek ögeli bir liste şeklinde girilmiştir. Bu listenin elemanları ya User nesnesi olmalı, ya da geriye ilgili user nesnesini döndüren bir get_user() metoduna sahip olmalıdırlar.

Modellerin tanımlanması.¶

Yukarıda gösterdiğimiz “Önkayıy / Kayıt ” akışı için “ogrenci_kayit.py” gibi geçerli bir isimle models dizinine kaydedip, models/__init__.py içine import etmemiz yeterli olacaktır.

from pyoko import Model, ListNode, field
from ogrenci import Ogrenci
from personel import Personel

class OgrenciProgram(Model):
    ogrenci_no = field.String("Öğrenci Numarası", index=True)
    giris_tarihi = field.Date("Giriş Tarihi", index=True, format="%d.%m.%Y")
    mezuniyet_tarihi = field.Date("Mezuniyet Tarihi", index=True, format="%d.%m.%Y")
    giris_puan_turu = field.Integer("Puan Türü", index=True, choices="giris_puan_turleri")
    giris_puani = field.Float("Giriş Puani", index=True)
    aktif_donem = field.String("Dönem", index=True)
    durum = field.Integer("Durum", index=True, choices="ogrenci_program_durumlar")
    basari_durumu = field.String("Başarı Durumu", index=True)
    ders_programi = DersProgrami()
    danisman = Personel()
    program = Program()
    ogrenci = Ogrenci()


    class Meta:
        app = 'Ogrenci'
        verbose_name = "Öğrenci Programı"
        verbose_name_plural = "Öğrenci Programları"

    class Belgeler(ListNode):
        tip = field.Integer("Belge Tipi", choices="belge_tip", index=True)
        aciklama = field.String("Ek Açıklama", index=True, default="-", required=False)
        tamam = field.Boolean("Belge kontrol edildi", index=True, required=True)

    def __unicode__(self):
        return '%s %s - %s / %s' % (self.ogrenci.ad, self.ogrenci.soyad,
                                    self.program.adi, self.program.yil)

Puan Türü ve Puan Bilgileri Ekranı¶

class YerlestirmeBilgisiForm(forms.JsonForm):
    class Meta:
        include = ["giris_puan_turu", "giris_puani"]

    ileri_buton = fields.Button("İleri", cmd="save")

class YerlestirmeBilgisi(CrudView):
    class Meta:
        model = "OgrenciProgram"

    def yerlestirme_bilgisi_form(self):
        ogrenci = Ogrenci.objects.get(user = self.current.user)
        ogrenci_program = OgrenciProgram.objects.get(ogrenci = ogrenci, durum = 1)
        self.form_out(YerlestirmeBilgisiForm(ogrenci_program, current = self.current))

Önceki Eğitim Bilgileri Ekranı¶

class OncekiEgitimBilgileriForm(forms.JsonForm):
    class Meta:
        include = ["okul_adi", "diploma_notu", "mezuniyet_yili"]

    kaydet = fields.Button("Kaydet", cmd="save")


class OncekiEgitimBilgileri(CrudView):
    class Meta:
        model = "OncekiEgitimBilgisi"

    def onceki_egitim_bilgileri(self):
        ogrenci = Ogrenci.objects.get(user = self.current.user)
        onceki_egitim_bilgisi = OncekiEgitimBilgisi.objects.filter(ogrenci = ogrenci)
        self.form_out(OncekiEgitimBilgileriForm(onceki_egitim_bilgisi[0], current=self.current))

    def kaydet(self):
        ogrenci = Ogrenci.objects.get(user = self.current.user)
        self.set_form_data_to_object()
        self.object.ogrenci = ogrenci
        self.object.save()

Öğrenci Önkayıt Ekranı¶

class OnKayitForm(forms.JsonForm):
    class Meta:
        include = ['kan_grubu', 'baba_aylik_kazanc', 'baba_ogrenim_durumu', 'baba_meslek',
                   'anne_ogrenim_durumu', 'anne_meslek', 'anne_aylik_kazanc', 'masraf_sponsor',
                   'emeklilik_durumu', 'kiz_kardes_sayisi', 'erkek_kardes_sayisi',
                   'ogrenim_goren_kardes_sayisi', 'burs_kredi_no', 'aile_tel', 'aile_gsm',
                   'aile_adres', 'ozur_durumu', 'ozur_oran']

    kaydet_buton = fields.Button("Kaydet", cmd="kaydet")

class OnKayit(CrudView):
    class Meta:
        model = "Ogrenci"

    def on_kayit_form(self):
        ogrenci = Ogrenci.objects.get(user = self.current.user)
        self.form_out(OnKayitForm(ogrenci, current = self.current))

Belge Kayıt Ekranı¶

class BelgeForm(forms.JsonForm):
    class Meta:
        include = ["Belgeler"]

    kaydet = fields.Button("Kaydet", cmd="save")
    onayla = fields.Button("Ön Kayıt Onayla", cmd="onayla")

class KayitBelgeler(CrudView):
    class Meta:
        model = "OgrenciProgram"

    def belge_form(self):
        ogrenci = Ogrenci.objects.get(user=self.current.user)
        ogrenci_program = OgrenciProgram.objects.get(ogrenci = ogrenci)
        self.form_out(BelgeForm(ogrenci_program, current = self.current))

    def onayla(self):
        ogrenci = Ogrenci.objects.get(user = self.current.user)
        ogrenci_program = OgrenciProgram.objects.get(ogrenci = ogrenci, durum = 1)
        ogrenci_program.durum = 2
        ogrenci_program.save()

ZEngine ile İş Akışı Temelli Uygulama Geliştirme¶

İş akışı ve iş akışı temelli uygulama¶

İş akışları bir kurumun yürüttüğü işlerin belirli bir notasyona göre görselleştirilmesi amacıyla kullanılırlar. İşlerin kim tarafından, hangi sırayla, hangi koşullara bağlı olarak yürütüleceğinin ilgili personel tarafından üzerinde uzlaşılmış bir standartta ifade edilmesi, iş süreçlerinin kişiler arasında daha kolay ve doğru biçimde anlatılabilmesini sağladığı gibi sürecin iyileştirilmesi için yapılacak değişiklikleri tasarlamayı da kolaylaştırmaktadır.

İş akışı tabanlı uygulamalar, belirli bir dilde yazılmış akış diagramlarının, iş akışı motoru (workflow engine) tarafından işletilmesi temeline dayanırlar. İş akış motoru kullanıcı girdileri ve çevre değişkenlerini, iş akışında tanımlanmış koşullara karşı işletir. İlgili koşulun yönlendirdiği adımının (workflow step) etkinleştirilmesi, bu adımla ilişkilendilimiş uygulama metodlarının çalıştırılması ve kullanıcı etkileşimleri arasında akışın durumunun (workflow state) saklanması yine iş akışı motorunun görevidir.

ZEngine Web Çatısı¶

ZEngine, Zetaops tarafından Python dili kullanılarak geliştirilen, Ulakbüs projesinin de üzerine inşa edildiği, BPMN 2.0 iş akışlarını destekleyen servis odaklı bir web çatısıdır. Falcon, SpiffWorkflow ve Pyoko olmak üzere üç temel öge üzerine kurulmuş olan ZEngine, iş akışı tabanlı web servislerinin Python nesneleri ile kolayca inşa edilmesini sağlayan, ölçeklenebilir ve güvenli bir platform sunar.

Falcon¶

Falcon, WSGI standardını destekleyen, REST mimarisinde servisler oluşturmak için geliştirilmiş aşırı hızlı ve hafif bir web çatısıdır.

SpiffWorkflow¶

Spiffworkflow Python ile yazılmış BPMN 2 notasyonunu destekleyen güçlü bir iş akışı motorudur. ZEngine altında kullanılan sürümüne ihtiyaç duyulan ek işlevlerin eklenmesi ve bakımı Zetaops tarafından yapılmaktadır.

Pyoko¶

Riak KV için tasarlanmış bir ORM (Object Relational Mapper) aracı olan Pyoko, Riak KV’nin Solr arama motoru ile olan entegrasyonunu tümüyle desteklemekte ve bu iki ürünün tek bir API üzerinden ilişkisel bir veri tabanı rahatlığında kullanılabilmesini olanaklı kılmaktadır.

Uygulamanın konusunu oluşturan varlıklar (entities) Pyoko modelleri olarak tasarlanmakta, bu modeller altında saklanan verilere erişim yine modellerde tanımlanan yetki koşullarına uygun olarak yönetilmektedir. Bir varlıkla doğrudan ilişkili metodlar kendi modelinin altında tanımlanebilmekte, böylece uygulamanın kod organizasyonu kolaylaşmaktadır.

Pyoko, veritabanında saklanacak verilerin Python nesneleri olarak tanımlanmasına imkan vermenin yanı sıra, bu veri varlıkları arasında ilişkisel veritabanlarındakine benzer bağlantılar oluşturmasını sağlar. Veri girdilerinin model tanımına uygunluğunun kontrolü ve kullanıcıların bu verilerle yetkileri dahilinde etkileşime geçebilmelerini garanti edilmesi de Pyoko sayesinde veri katmanı seviyesinde çözülebilen uygulama ihtiyaçlarıdır.

Modellerde iç içe sınıflar şeklinde ifade edilen veri varlıkları, veritabanına JSON biçiminde kaydedilir, okunurken tekrar Python nesnelerine dönüştürlürler.

NoSQL olarak da anılan Anahtar/Değer (K/V) tipindeki veri tabanlarında, ilişkisel veri tabanlarındaki (RDBMS) join kavramı olmadığından, henüz tasarım aşamasındayken verilerin nasıl sorgulanacağı iyi düşünülmeli ve mümkün mertebe tek sorguda ihtiyaç duyulan tüm verinin alınabileceği bir veri varlığı yapısı tasarlanmalıdır. Bu işlemin kolaylaştırılması ve uygulamanın iş mantığının veri senkronizasyonu amaçlı kodlarla dolmasını engellemek için Pyoko verileri yazma anında birleştirir (write-time join, auto-denormalization).

Veri Modelleri¶

Pyoko karmaşık veri yapılarının nesnel şekilde ifade edilebilmesi için Model, Node ve ListNode adında üç temel nesne tipi sunmaktadır. Bu nesneleri, ihtiyacımız doğrultusunda iç içe ya da birbirleriyle ilişkilendirerek kullanabiliriz. Bu nesneler üzerinde saklanacak verileri tanımlamak için ise String, Boolean, Integer, Date gibi çeşitli veri alanları tanımlanmıştır.

Aşağıda, bu belgenin devamında birlikte hazırlayacağımız ve konusu “öğrencinin ders seçmesi, danışman öğretmeninin bu dersi onaylaması” olan bir iş akışın gerektirdiği veri modelinin minimal bir örneği listelenmiştir.

15. Satırda olduğu gibi bir modelden başka bir modele referans verdiğimizde bu iki model arasında OneToMany tipinde bir bağ kurmuş oluruz.

17. Satırda öğrencinin aldığı dersler ListNode tipindeki Lectures nesnesi ile ifade edilmiştir. ListNode, liste benzeri veri yapılarını ifade etmek için kullanılan, yinelenebilir (iterable) bir nesnedir.

18. Satırda olduğu gibi ListNode içinde başka bir modele referans verildiğimizde, iki model arasında ilişkisel veritabanlarındaki ManyToMany benzeri bir ilişki tanımlamış oluruz.

from pyoko import Model, ListNode, field

class Lecturer(Model):
    name = field.String("Adı", index=True)


class Lecture(Model):
    name = field.String("Ders adı", index=True)
    credit = field.Integer("Kredisi", default=0, index=True)


class Student(Model):
    name = field.String("Adı", index=True)
    join_date = field.Date("Kayıt tarihi", index=True)
    advisor = Lecturer()

    class Lectures(ListNode):
        lecture = Lecture()
        confirmed = field.Boolean("Onaylandı", default=False)

Bu modeller üzerinde kayıt ekleme, sorgulama, silme, güncelleme işlemlerinin nasıl yapılacağını belgenin devamında “özelleştirilmiş ekranların oluşturulması” bölümünde inceleyebilirsiniz.

Workflow Metodları (Views & Tasks)¶

Workflow tabanlı bir uygulamada, uygulamanın tüm işlevselliği iş akışı adımları üzerinden çalıştırılacak şekilde hazırlanır. Bu işlevler BPMN diagramında UserTask ve ServiceTask adımlarının ilgili alanlarına girilen metod ve sınıf çağrıları ile yerine getirilir. İş akışı motoru, kullanıcı girdilerini (TaskData), o an işlettiği akış diagramında tanımlı ExclusiveGateway gibi karar kapılarına karşı işleterek akışı yönlendirir. Etkinleştirilen akış adımlarıyla ilişkili metod çağrıları sonucuna göre akış sonraki adıma devam edebilir ya da akışın durumu kaydedilip işlem çıktısı akışı tetikleyen kullanıcıya geri döndürülebilir.

Bir web uygulamasının işlevlerini yerine getirmesi için yazılan kodların büyük bir kısmı istemci (web tarayıcı) ile etkileşimi sağlayan API çağrıları üzerinden çağırılırken (views), bazı işlemler de arkaplanda çalışan görevler (tasks) ile yürütülür. Bu belgede task olarak anılacak bu arkaplan görevleri, doğası gereği tamamlanması uzun sürebilecek çeşitli hesaplamalar olabileceği gibi, dış servislere bağımlı olduklarından, kullanıcı deneyimini etkilememeleri için arkaplanda çalıştırılması gereken anlık görevler de olabilirer.

İster view ister task tipinde olsunlar, workflow metodarının tüm girdi & çıktı işlemleri current.input ve current.output sözlükleri üzerinden yapılır.

def say_hello(current):
    if current.user.first_login:
        current.output["msg"] = ("Welcome %s, Thank you for registering "
                                 "to our site." % current.input['name'])
        current.user.first_login = False
        current.user.save()

Current Nesnesi¶

İş akışı motoru bir view ya da task metodunu “Current” adını verdiğimiz merkezi bir nesneyi parametre olarak vererek çağırır. Current nesnesi akışın durumu (workflow state), kullanıcı oturumu, girdi ve çıktı kapıları gibi bir workflow metodunun ihtiyaç duyabileceği tüm ögeleri barındırır.

Current nesnesi, workflow metodlarından işimize yarayabilecek aşağıdaki ögeleri içerir. Bunlardan session, user, auth gibi sadece view metodlarında işlevsel olanlar arkaplanda çalışan task metodlarında geçersizdirler.

input İstemciden gelen JSON verisinin çözümlenip (decode) Python sözlüğü şekline getirilmiş hali.

output İstemciye gönderilecek veri sözlüğü. Bu sözlük otomatik olarak JSON verisi şekline dönüştürülür.

session Kullanıcı oturumunu içeren sözlük benzeri bir nesnedir. Bu nesne üzerinde herhangi bir yazma/okuma işlemi yapıldığında, değişiklikler otomatik olarak oturuma kaydedilir. Kullanıcı henüz sisteme giriş yapmamış olsa bile oturumu mevcuttur ve giriş yaptıktan sonra aynı oturum devam eder.

auth Kullanıcı yetkilendirmesi ile ilgili metodları barındıran AuthBackend nesnesidir. get_user(), get_permissions(), has_permission(), authenticate() metodlarını içerir. ZEngine bu nesnenin referans sürümünü içerir ancak kendi uygulamamızda kullanıcı ve yetki sistemimize uygun şekilde özelleştirilmiş bir AuthBackend nesnesi kullanmamıza izin verir.

user Sisteme giriş yapmış kullanıcıyı veren vekil (lazy proxy) kullanıcı nesnesidir. Asıl kullanıcı bilgileri, bu nesneye erişildiği anda veritabanından çekilir.

task_data İş akışının karar adımlarında tanımlı koşullar bu sözlüğün içerdiği veriler ile işletilir.

workflow_name İşletilmekte olan iş akışının adı.

workflow İşletilmekte olan iş akışı nesnesi.

task Etkin durumdaki iş akışı adımı (Task) nesnesi.

is_auth Kullanıcının sisteme giriş yapma durumunu belirten bool tipinde bir özelliktir.

has_permission(perm_code_name) Kullanıcının adı verilen yetkiye sahip olup olmadığını boolean tipinde döndürür.

get_permissions() Kullanıcının sahip olduğu tüm yetkileri döndürür.

Yetkiler ve Rol Tabanlı Erişim Kontrolü¶

ZEngine Pyoko’dan miras aldığı satır ve hücre seviyesinde erişim kontrolüne ek olarak, sisteme yüklenmiş iş akışlarının tüm adımlarını birer yetki olarak tanımlar. Otomatik olarak türetilen iş akışı yetkilerine ek olarak, CustomPermission nesnesi ile, kendi view metodlarımızda kontrol edebileceğimiz ek yetkiler de tanımlayabilirz. Tüm bu yetkiler Role ve AbstractRole modelleri ile ifade edilen kullanıcı rolleri üzerinden ilgili User’a tanımlanır.

Note

ZEngine web çatısı User ve Permission nesnelerinden ibaret basit bir referans yetki sistemi ile gelmektedir. Bu belgede, Ulakbüs projesi kapsamında geliştirmekte olduğumuz rol ve özellik tabanlı gelişmiş yetkilendirme sisteminden bahsedilecektir.

Ulakbüs projesinde ihtiyaç duyulan kapsamlı yetkilendirme ihtiyaçlarını karşılayabilmek için yukarıda ilişkisel şekilde görselleştirilmiş yetki modelleri tanımlanmıştır.

AbstractRole nesnesi “Tıp Fakültesi Öğrenci İşleri Müdürü” gibi belirli bir makamı temsil ederken, Role nesnesi ise AbstractRole’ün bir kullanıcı ile ilişkilendirilmesi sonucu bu makamı fiilen işgal eden bir kişiyi ifade etmektedir.

Permission nesnesinin hem Role ile hem de AbstractRole ile ManyToMany tipinde ilişkili olması sayesinde, bir kullanıcıya sahip olduğu makamın getirdiği standart yetkilere ek yetkilerin tanıması da mümkün olabilmektedir.

LimitedPermissions nesnesi IP adres ve saat bazlı olarak Permission, Role ve AbstractRole nesneleri ile ManyToMany tipinde ilişkilidir. Bu ilişki sayesinde seçilen rol ya da makamın, seçilen yetkileri belirli saatlere, istemci IP’lerine yada belirli saatlerler için belirli IP’lere göre kısıtlanabilir ya da verilebilir.

Student ve Employee nesnelerinin User ile OneToOne şeklinde ilişkili olmaları, bir kullanıcının aynı anda hem öğrenci hem de personel statüsünde olabilmesine olanak vermektedir. Benzer şekilde User ile Role nesnesi arasındaki OneToMany tipindeki ilişki, bir kullanıcının birden fazla rolü yani makamı olabilmesine imkan vermektedir. Birden fazla rolü olan bir kullanıcı giriş yaptığında son çıkış yaptığı rolün ana ekranı ile karşılaşır, isterse kullanıcı menüsünden hesabına kayıtlı diğer bir role geçiş yapabilir. Kullanıcı belirli bir anda, sadece o anda etkin durumda olan rolünün yetkileri ile işlem yapabilir.

Satır ve Hücre Seviyesinde Erişim Kontrolü¶

Pyoko, model tanımları içerisinde satır ve hücre seviyesinde erişim kontrolü yapılmasına izin verir. Burada satır seviyesinden kasıt, kullanıcının yetkisinin izin vermediği kayıtlara erişememesidir. Hücre seviyesinde ise, kullanıcının bir modelin altındaki kayıtların sadece bazı alanlarına erişimesine izin verip, bazı alanlardaki verilere erişimi kısıtlanabilir.

Satır ve hücre seviyesinde erişim kontrolünün veri katmanı seviyesinde çalışabilmesi için, model nesnelerinin kullanıcı yetkilerini içeren Current nesnesi ile ilklendirilmeleri gerekmektedir. Bu işlevler isteğe bağlı özellikler olduklarından, bu gereklilik sadece aşağıdaki gibi model içinde yetki kısıtlaması yapıldığı durumlarda geçerlidir.

class Personel(Model):
    name = field.String(index=True)
    section = field.String(index=True)
    phone = field.String(index=True)
    address = field.String(index=True)

    @staticmethod
    def row_level_access(current, objects):
        if not current.has_permission("access_to_other_sections"):
            return objects.filter(section=current.user.section)

    class Meta:
        field_permissions = {
            'can_see_private_data': ['phone', 'address']
        }

Yukarıdaki Personel modelinin 6. satırında tanımlanan row_level_access() metodu, modelin ilklendirilmesi (initialization) aşamasında çağırılır. 7. satırda kullanıcının kendi bölümü dışındaki kullanıcı kayıtlarına erişim yetkisi olup olmadığı kontrol edilip, eğer yoksa 8. satıda objects nesnesinin üzerine yazarak etkin kullanıcı tarafından bu model üzerinde yapılacak tüm sorguların sadece kendi bölümündeki kullanıcı kayıtlarıyla sınırlanması sağlanır.

Hücre seviyesinde erişim kısıtlaması yapmak için META sözlüğü içerisinde field_permissions adında bir sözlük tanımlayıp, anahtarı yetki adları, değeri de kısıtlanacak alan adlarını içeren bir liste tanımlamamız yeterlidir. Yukarıda 12. satırda tanımlanan kısıtlama sayesinde, can_see_private_data yetkisine sahip olmayan kullanıcıların phone ve address alanlarını okuyup yazmaları engellenmiş olur.

Aşağıda veri tabanındaki tüm kişileri listelemeye çalışan view metodu, etkin kullanıcının gerekli yetkiye sahip olmaması durumunda, sadece kendi bölümündeki kullanıcıları görüntüleyebilecektir. Benzer şekilde kullanıcı kişilerin özel bilgilerini görüntüleme yetkisine sahip değilse de person_list listesinin phone sütunu boş kalacaktır.

def show_person_list(current):
    for person in Person(current).objects.filter():
        current.output['person_list'].append({'name': person.name,
                                              'id': person.key,
                                              'phone': person.phone})

Ulakbüs UI - API ilişkisi¶

Bu belge Ulakbus UI ve API bileşenlerinin etkileşimini göstermek için hazırlanmıştır.

API kullanılarak hazırlanan view, model ve jenerik fonksiyonlarda hangi tip verinin kullanıcı arayüzünde nasıl gösterildiğini bu belgede bulabilirsiniz.

UI hakkında¶

Ulakbus kullanıcı arayüzü tek sayfalı bir tarayıcı uygulamasıdır.
Sayfadaki data dinamik olarak Ulakbus API tarafından sağlanır ve arayüzde işlenir.
Veri sunucu tarafında render edilmez, yani bir html dosyasına işlenerek gönderilmez.
Sunucu tarafından gönderilen tüm verilerin yapısı JSON‘dır.

Kullanıcı arayüzünü hazırlamak için AngularJS kütüphanesi kullanılmıştır.

UI tamamıyla statik dosyalardan oluşmaktadır. index.html dosyası tarayıcı tarafından işlendikten sonra uygulama başlar.

Sayfa hazır olduktan sonra app.js dosyası çalışıp gerekli modülleri ve bağımlılıkları tanımlar.
Uygulamanın ana modülü ulakbus modülüdür.

app_routes.js dosyasında uygulamanın sayfaları ve kullanacakları controller’lar ve template’leri düzenlenmiştir.
Bu dosyaya göre istenen sayfa ilgili template ve controller ile yorumlanır.

UI başlangıcı¶

Uygulamanın bağlandığı kararlı api sunucusu http://api.ulakbus.net adresinde bulunur. Geliştirme ortamı için http://nightly.api.ulakbus.net adresinde bulunur.
Kararlı api sunucusu varsayılan sunucudur.
Yerel yada başka bir adresteki sunucuyu kullanmak için başlangıç adresinde “backendurl” parametresi ile adresi girmeniz gerekmektedir. Yerel geliştirme ortamında nightly sunucusuna bağlanmak için adres satırına http://localhost/?backendurl=http://nightly.api.ulakbus.net yazmanız yeterlidir.

Uygulama başlatılıp tüm modül tanımlarmaları yapıldıktan sonra tarayıcı kullanıcıyı /dashboard adresine yönlendirir. Uygulamanın en başında kullanıcının login durumu kontrol eder ve kullanıcı mevcut değil ise /login ekranına yönlendirilir.

Login işlemi¶

Login işlemi için http://api.ulakbus.net/login adresine kullanıcı parametreleriyle XHR istegi gönderilir.
Gelen yanıt JSON nesnesinde cmd parametresini baz alarak işlemin sonucunu değerlendirilir. cmd, upgrade veya retry gelebilir.

upgrade yanıtıyla birlikte ws://api.ulakbus.net/ws adresinde websocket açılır. Kullanıcı /dashboard‘a yönlendirilir. Geri kalan tüm iletişim websocket üzerinden yönetilir.

Yanlış bilgi girildiğinde retry yanıtı alınır ve kullanıcı tekrar /login sayfasına yönlendirilir. Başka aksiyon alınmaz.

Dashboard¶

Kullanıcı login olduktan sonra dashboard ekranına geldiği anda {view: 'dashboard'} isteği yapılır. bu isteğin yanıtında kullacının bilgisi ve de kulanıcı menüleri gelir.

Ulakbus uygulaması iş akışı tabanlı bir uygulamadır. BPMN 2.0 standartlarını kullanır.
İş akış şemaları yani workflow lar bpmn formatında backend API’da oluşturulur.
Bu iş akış şemaları kendilerine ait model ve view metotlarını kullanarak tanımlanan işi belirlenen adımlarla gerçekleştirirler.

Api response¶

Kullanıcı kendine ait işakışlarına menüler aracılığıyla ulaşır. Kullanıcı bir iş akışı başlattığında api ye başlattığı iş akışının model ve workflow bilgisini gönderir. Api den gelen bilgiler ile UI tarafından yorumlanır. Yorumlama işlemi CRUDListFormController tarafından yapılmaktadır.

Gelen yanıt içerisinde yer alan client_cmd parametresine göre yorumlama tipi seçilir. client_cmd değeri show, list, form, reload veya reset olabilir.

form gönderilen datanın forms nesnesi taşıdığı ve kullanıcı arayüzünün bunu form olarak yorumlaması gerektiği durumlarda kullanılır.
list sayfada listelenmesi istenen bir data olduğunda kullanılır. Bu data table olarak listelenir.
show komutu sayfada detay bilgileriyle gösterilmek istenen bır data olduğunda kullanılır.
reload komutu sayfada gösterilen datada bir değişiklik olduğu ve datanın API’dan yeniden istenmesi gerektiği durumlarda kullanılır.
reset komutu datanın ek parametreler olmadan yeniden çekilmesi için kullanılır.

Bu komutlar oluşturulan iş akışlarının ilgili adımlarında kullanılarak arayüzün istenen şekilde davranması için gereklidir.

Diğer yanıt parametreleri forms, meta, objects, pagination, reload_cmd, token, callbackID, notify, is_login olabilir.

reload_cmd anahtarı "client_cmd": "reload" olması durumunda arayüzün backend API’dan isteyeceği komutu taşır. UI post datası içinde cmd anahtarında bu değeri gönderir.
token anahtarında iş akış şemasının (workflow) redis’te tutulan token değeri vardır. İş akışı tamamlanmadığı sürece bu token request nesnesinde API’a gönderilir.
callbackID UI tarafından üretilip gönderilmektedir. Yanıt içerisinde bulunuyorsa UI tarafından yapılan bir isteğin yanıtı olduğu anlamına gelmektedir. Uygulama genelinde yapılan isteklerde Javascript Promise alt yapısı kullanılarak asenkron istek yapılmaktadır. Bekleyen promise resolve edilerek iş akışının devamı sağlanmaktadır.
meta anahtarında arayüzde istenen yapılandırmalar yer alır. Boolean değer taşırlar. Bunlar şunlardır;
- allow_search Listeleme ekranında arama kutusunun gösterilmesi için kullanılır.
- allow_selection Listeleme ekranında tablonun solunda selectBox yer alması için kullanılır.
- allow_sort Listeleme ekranındaki sıralama özelliği için kullanılır.
- allow_filter Listelenen datanın filtrelemesi için kullanılır.
- allow_actions ListNode tipinde listelenen data için en sağdaki işlemler kolonunun gösterilmesi için kullanılır.
- translate_widget Katalog verilerin düzenleneceği ekran için oluşturulan widget’dır. Aynı zamanda çeviri işlemleri için kullanılacaktır. Boolean tipinde değer alır.
_debug_queries anahtarı geliştiriciler için yardımcı bir anahtardır. Veritabanına yapılan sorguların süresi ve kaç adet sorgu yapıldığı gibi değerler bu anahtarda yer alır. Aktif olması için API ortamında çevre değişkeni DEBUG=1 olarak atanmalıdır.
is_login anahtarı kullanıcının giriş yapıp yapmadığını gösteren bir anahtardır. Bu anahtar false değer taşıdığında arayüz login sayfasına yönlendirir.
notify ayayüzde bildirim göstermek için kullanılır. Gönderilen bildirimler pencerenin sağ üstünde yer alır ve bir süre sonra kaybolur.
pagination anahtarı listeleme gösterimlarinde sayfalama bilgisini bulundurur.

Ulakbüs UI Öğeleri¶

Ulakbüs kullanıcı arayüzünde sunulan temel öğeler şunlardır;

Form öğesi - Ekleme ve düzenleme işlemleri
Liste öğesi - Listeleme, arama, filtre ve silme işlemleri
Detay öğesi - Tek nesne detay ve rapor ekranları

Bu öğe türleri API’ın iş akışlarında sunduğu temel içerik türleridir.
Bu içerik türlerinin kullanıcı arayüzünde doğru biçimde yorumlanması için API yanıtı içerisinde gönderilecek anahtar değerler belirlenmiştir.
Bu anahtarlar aşağıdaki tablodaki gibidir;

İçerik türü	Anahtar
Form	`forms`
Liste	`objects`
Detay	`object`

İçerik türleri aynı sayfa içerisinde bulunabilir. Bu koşulda

detay
form
liste

sırasına uygun şekilde aynı sayfada listelenir

Form Öğesi¶

Ulakbus UI form işlemlerini gerçekleştirmek için angular-schema-form extend edilmiştir.

Kullanılan form nesneleri angular-schema-form’un beklediği formatta olmalı ya da değilse extend edilerek custom type yaratılmalıdır.

Örnek bir forms nesnesi aşağıdaki gibidir:

{
    "forms":{
        "constraints":{},
        "model":{ "ad":null, "soyad":null },
        "grouping":{},
        "form":[
            { "helpvalue":null, "type":"help" },
            "ad",
            "soyad",
            {
                "titleMap":[
                    { "name":"Bay", "value":1 },
                    { "name":"Bayan", "value":2 }
                ],
                "type":"select",
                "key":"cinsiyet",
                "title":"Cinsiyet"
            },
            "e_posta",
            "dogum_tarihi",
            "save_edit",
            "nufus_kayitlari_id",
        ],
        "schema":{
            "required":[ "ad", "soyad" ],
            "type":"object",
            "properties":{
                "ad":{ "type":"string", "title":"Adı" },
                "soyad":{ "type":"string", "title":"Soyadı" },
                "e_posta":{ "type":"string", "title":"E-Posta" },
                "save_edit":{ "cmd":"save::add_edit_form", "type":"button", "title":"Kaydet" },
                "nufus_kayitlari_id":{
                    "list_cmd":"select_list",
                    "title":"Nüfus Bilgileri",
                    "wf":"crud",
                    "add_cmd":"add_edit_form",
                    "type":"model",
                    "model_name":"NufusKayitlari"
                },
                "dogum_tarihi":{ "type":"date", "title":"Doğum Tarihi" },
                "cinsiyet":{ "type":"select", "title":"Cinsiyet" }
            },
            "title":"Personel"
        }
    }
}

forms’un öğeler ise şunlardır:

form

Bu anahtar altında formda gösterilmesi istenen inputlar bir liste halinde yer alır.

schema

schema anahtarının alt özellikleri vardır. Bunlardan required bir liste halinde doldurulması gerekli alanları gösterir.

properties anahtarında form anahtarında belirtilen alanların özelliklerinin yer aldığı anahtardır.

{
    "e_posta":{ "type":"string", "title":"E-Posta" }
}

type alanında inputun tipi ve title alanında bu inputun başlığı yer alır.

İlişkisel veri tipleri olan ListNode, Node ve Model için bu anahtarlarda wf, add_cmd, list_cmd, model_name değerleri bulunmaktadır. Bu değerler form sayfası oluşturulurken dikkate alınır.

Formlarda birden fazla buton değişik işleri yapabilsin diye bu input alanlarına cmd değeri eklenmiştir. Bu değer form submit edilirken cmd anahtarında API’a gönderilir.

Ek işlevsellik isteyen alanlar için (Node, ListNode, Model, select, file, submit, date, text_general, etc.) template’ler oluşturulmuştur.

Field tipleri şunlar olabilir:

button

submit

file

select

date

int

boolean

string

typeahead

text_general

float

model

Node

ListNode

model

Bu anahtarda form alanlarının değerleri tutulmaktadır.
Düzenlenecek form için bu anahtardaki değerler dolu olarak döner ve inputlara atanır.
Boş değer dönmesi o anahtar için daha önceden bir kayıt yapılmadığını gösterir.

grouping

Form inputlarının sayfa yerleşimlerini düzenleyebilmek için eklenmiş bir özelliktir.
Grid sistem baz alınarak gruplanan elemanlara alan değerleri atanır. layout değeri 12 birimlik alanda kaç birim olarak yer alacağını gösterir.
Aşağıda bu özelliğin bir örneği görülebilir:

{
    "grouping": [
        {
            "group_title": "Gorev",
            "items": ["gorev_tipi", "birim", "aciklama"],
            "layout": "4",
            "collapse": false
        }
    ]
}

constraints

Form inputlarının birbirlerine göre bağımlılıklarının denetlendiği ve düzenlendiği anahtardır. Geliştirme aşamasındadır.

Liste öğesi¶

Liste öğesinde kaydedilen nesneler listelenir.

Listelenecek öğeler objects anahtarında döner. Dönen listede ilk nesne listenin başlık değerlerini oluşturur.
İkinci nesneden itibaren fields anahtarında liste halinde aynı sırayla ilk nesnedeki başlıkların karşılığı değerler yer almaktadır.
actions anahtarında o satır için gerçekleştirilebilecek işlemler yer almaktadır. İşlemlerin gösterim şekilleri show_as anahtarında gönderilir.
İşlemler varsayılan olarak satırın sonundaki işlemler alanında gösterilir.
Eğer satırdaki bir hücreye uygulanması isteniyorsa hangi alana uygulanacağı bir liste içinde işlem nesnesinin fields anahtarında belitrilir.
Gerçekleştirilecek işlemin ne olacağı işlemin cmd anahtarında yer alır. mode anahtarı normal (varsayılan), new (yeni sayfada) ve modal (bir modal içinde) değerlerini alabilir.
pagination anahtarında sayfalama uygulandıysa sayfa başına kaç nesne olduğu per_page, toplam nesne sayısı total_objects, toplam sayfa sayısı total_pages, ve o an hangi sayfada olunduğu page bilgisi yer alır.

Liste sayfasıyla birlikte gönderilen "forms" anahtarında o sayfada ayrıca form işlemlerinin yapılması sağlanmaktadır. Aşağıdaki örnekte o anki modele yeni bir kayıt eklemek için forms anahtarının kullanıldığı görülmektedir.

{
    "forms":{
        "constraints":{},
        "model":{ "add": null },
        "grouping":{},
        "form":[ "add" ],
        "schema":{
            "required":[ "add" ],
            "type":"object",
            "properties":{
                "add":{
                    "cmd":"add_edit_form",
                    "type":"button",
                    "title":"Ekle"
                }
            },
            "title":"Personeller"
        }
    },
    "pagination":{
        "per_page":8,
        "total_objects":26,
        "total_pages":3,
        "page":1
    },
    "objects":[
        [ "Adı", "Soyadı", "TC No", "Durum" ],
        {
            "fields":[
                "Işık",
                "Ülker",
                "19189958696",
                null
            ],
            "actions":[
                {
                    "fields":[
                        0
                    ],
                    "cmd":"show",
                    "mode":"normal",
                    "show_as":"link"
                },
                {
                    "cmd":"add_edit_form",
                    "name":"Düzenle",
                    "show_as":"button",
                    "mode":"normal"
                },
                {
                    "cmd":"delete",
                    "name":"Sil",
                    "show_as":"button",
                    "mode":"normal"
                }
            ],
            "key":"1234qwer"
        }
    ]
}

Detay öğesi¶

Detay öğesinde gösterilmek istenen nesne anahtar değer olarak sıralanır. Örnekte bir kişi kaydının anahtar değerleri görülmektedir.

{
    "object":{
        "Cep Telefonu":"+90 (259) 6925396",
        "Cinsiyet":"Erkek",
        "Soyadı":"Arsoy",
        "TC No":"63488661696",
        "Adı":"Kutun",
        "Doğum Tarihi":"03.04.1969",
        "E-Posta":"daslan@arsoy.com"
    }
}

UI Menu ve Diğer Öğeler¶

Kullanıcı arayüzündeki menüler API tarafından dinamik olarak giriş yapan kullanıcının yetkileri baz alınarak oluşturulur.

/menu url’ine yapılan sorguda dönen ogrenci, personel, other anahtarlarındaki değerler kategorilerine göre ayıklanarak menüye eklenir.

Ulakbus için iki ana işlem yapılacak kullanıcı tipi bulunmaktadır. Bunlar personel ve öğrencidir. Bu anahtarların sorguda dönme durumuna göre yönetim panelinde öğrenci ve personel arama inputları görüntülenir.
quick_menu anahtarında dönen menu nesneleri yönetim panelinde hızlı erişim için yer alır.

Menu sorgusunda ayrıca settings ve current_user anahtarları dönmektedir.

settings anahtarı API tarafından kullanıcı arayüzü konfigürasyonu için kullanılacak değerleri içerir. Şu anda static url path bu ayarlarda yer almaktadır.
current_user anahtarında giriş yapan kullanıcı bilgileri, rolleri, o anda hangi rolde işlem yaptığı ve kullanıcı avatarı yer almaktadır.

{
    "ogrenci":[
        {
            "kategori":"Seçime Uygun Görevler",
            "text":"Devam Durumu",
            "model":"DersKatilimi",
            "param":"ogrenci_id",
            "wf":"crud"
        }
    ],
    "personel":[
        {
            "kategori":"Seçime Uygun Görevler",
            "text":"Kimlik ve Iletisim Bilgileri",
            "model":"Personel",
            "param":"object_id",
            "wf":"kimlik_ve_iletisim_bilgileri"
        }
    ],
    "settings":{
        "static_url":"http://ulakbus.3s.ulakbus.net/"
    },
    "other":[
        {
            "kategori":"Genel",
            "text":"Personeller",
            "model":"Personel",
            "param":"other_id",
            "wf":"crud"
        }
    ],
    "current_user":{
        "username":"test_user",
        "is_staff":true,
        "surname":"Stallman",
        "name":"Richard",
        "roles":[
            {
                "role":"Role BaseAbsRole | test_user"
            },
            {
                "role":"Role W.C. Hero test_user"
            }
        ],
        "role":"BaseAbsRole",
        "is_student":false,
        "avatar":"http://ulakbus.3s.ulakbus.net/abcd.jpg"
    },
    "is_login":true,
    "quick_menu":[
        {
            "kategori":"Genel",
            "text":"Programlar",
            "model":"Program",
            "param":"other_id",
            "wf":"crud"
        }
    ]
}

Logout İşlemi¶

Logout işlemi de Ulakbüs için bir iş akışıdır. Logout için {wf: "logout"} bilgisi API’a gönderilir. Gelen yanıt ardından websoket kapatılır, oturum sonlanır.

Geliştirmeye Başlamak¶

Yukarıda anlatılan API-UI veri karşılıkları gözönünde bulundurularak geliştirme yapmaya başlayabilirsiniz.

Yazılım Geliştirme ve Test Döngüsü¶

Yazılım Geliştirme Modeli¶

Yazılım geliştirme modeli döngüsel artımlı (iterative and incremental) modele bağlı XP olacaktır. Şekil 1’de gösterilmektedir.

Şekil 1 - XP geliştirme şeması

Geliştirme ve Test Döngüsü¶

Extreme Programming modeline uygun şekilde 3 haftalık dönemlerde küçük sürüm planı yapılacak ve yazılım geliştirme ve test döngüsü bu sürüm planına bağlı olarak ilerleyecektir.

Sürüm planına dahil edilen işler (issue) geliştiriciler tarafından uygun bir branchte çözülecektir. Geliştiriciler, geliştirme faaliyetleri boyunca aşağıda detayları belirtilen otomatik ve manuel testleri build aşamasından önce uygulayacaklar, ancak bu testlerden geçen kaynak kod sonraki aşamaya geçebilecektir. Kurulum ve yayınlama aşamasında ise bu aşamanın testleri yapılacak ve sonuçlar geliştiricilere bildirilecektir. Ayrıca geliştirilen özelliğe göre kabul testleri de bu aşamada yapılacaktır. Bu geliştirme döngüsü 3 hafta boyunca artımlı şekilde ilerleyecektir.

Bu 3 haftanın sonunda ise sürüm adayı (release candidate) çıkartılacak ve bunun üzerinde kabul testleri ve önceden hazırlanmış test senaryoları, kullanılabilirlik, performans, güvenlik gibi testler yapılacaktır. Bu testlerin kabul sınırları içinde geçilmesi halinde sürüm ortaya çıkartılacaktır.

Bunlara ek olarak her gece, gecelik derlenmiş kod (nightly builds) yayınlanacak, yazılımın tüm bileşenlerine ait tüm otomatik testler bu aşamada gerçekleşecektir.

Sürüm Planı¶

Sürüm planı 3 hafta geliştirme + 1 hafta kabul test süreçleri şeklinde planlanır. 7 ay boyunca toplam 7 sürüm çıkarılacaktır. Sürüm planı ihtiyaç analizi isterleri ve YTA belgesi ışığında yeni özelliklerin planlanması, önceki sürümden kalan hataların kapatılması, topluluk geri bildirimlerinden seçilen işlerin (issues) tamamlanması hedefleriyle yapılır.

Depolar¶

Her bileşen kendi deposunda yaşam döngüsüne devam eder. Birbirlerini etkileyen issuelar için referans verilir. Başlıca geliştirme depolarımız:
SpiffWorkFlow: İş akışı kütüphanesi geliştirme deposudur. Orjinalden fork edilmiştir.
Pyoko: Pyoko Riak/Solr ORM geliştirme deposudur. Zetaops tarafından geliştiriliyor.
Zengine: Zengine Framework geliştirme deposudur. Zetaops tarafından geliştiriliyor.
Zaerp (Ulakbus): Ana uygulama backend geliştirme deposudur. Zetaops tarafından geliştiriliyor.
Zaerp-UI (Ulakbus-ui): Ana uygulama frontend geliştirme deposudur. Zetaops tarafından geliştiriliyor.
ZCloud: Bulut araçları geliştirme deposudur. Zetaops tarafından geliştiriliyor.

Yardımcı kütüphaneler ile fork edilmiş kütüphaneler haricindeki depo isimleri, daha sonra Ulakbim tarafından verilecek isimlerle değiştirilecektir.

Topluluk¶

Roller:¶

Geliştiriciler

Depolara kod katkısında bulunacak topluluk üyeleridir. Geliştirici Rehberleri ve Git Workflow[**] Belgesinde açıklanan akışa uygun şekilde geliştirme faaliyetlerine katılırlar.

[**] Bu belgeye referans verilecek.

Beta Test Edicileri

Patch ve Minor sürümleri test ederek geri bildirimlerde bulunarak geliştirme faaliyetine katkıda bulunurlar.

Analiz Uzmanları Yüksek Öğrenim Kanunu, Akademik Birimlerin Yönetmelikleri, akademinin yerleşik teammülerini bilen, projenin kapsamına detaylarıyla hakim topluluk üyeleridir. Topluluğun talep ettiği yeni özellikler, iş akışlarının değiştirilmesi, kanun ve yönetmeliklerdeki değişikliklerin projeyi nasıl etkileyeceği gibi konularda tavsiyelerde bulunurlar.

Topluluk Moderatörleri Topluluğun tartışmalarını kolaylaştırmak, konu başlıklarını bağlantılandırmak, tartışmaların gidişatını sorularla belirli hedeflere yönlendirmek gibi görevleri olan topluluk üyeleridir.

Geliştirici ve Katkıcı Rehberleri:¶

Geliştirme Ortamı Kurulum Rehberi
UI Geliştirci Rehberi
Zaerp Geliştirici Rehberi
Workflow ve Spiff WF Rehberi
Zato ve Servis Yazma Rehberi
Git Workflow

Test Döngüsünün Amaçları¶

Yazılım geliştirme döngüsünün denetlenebilir, kolay yönetilebilir ve ölçülebilir hale gelmesini sağlamak,
Problemleri somutlayarak, çok sayıda yazılımcının daha kolay işbirliği yapabilmesine yardımcı olmak,
Her bir yazılım parçasını çok yönlü şekilde zamanında test ederek, geliştirme döngüsünün sonraki aşamalarına en az hata ile devam etmek,
Bir bileşende yapılan geliştirmenin diğer bileşenleri nasıl etkilediğini zamanında görebilmek,
Kod kalitesini arttırmak,
Kod yazım desenleri açısından bütünlük sağlamak ve okunabilirliği arttırmak,
Kurulum sırasında yazılım bileşenleri ve birbirlerine olan bağımlılıkları doğrulamak,
Yazılımın farklı platformlarda ve farklı ortam değişkenleriyle başarılı bir şekilde kurularak, beklenen şekilde çalıştığından emin olmak,
Yazılımın beklenen şekilde çalışmasının ardından, önceden belirlenmiş çeşitli yük testleri altında aynı şekilde davranmaya devam ettiğinden emin olmak,
Ortaya çıkan ürünün, ister belgesindeki işlevleri karşılayıp kaşılamadığını doğrulamak,
Ürünün kullanım kolaylığı, kullanıcı deneyimi, performans açısından tatmin edici ve standartları karşıladığından emin olmaktır.

Sürüm Planına Bağlı Geliştirme Döngüsü Testleri¶

Eşli Gözden Geçirme (Peer Code Review)¶

Geliştiriciler, kodlarını çalıştıkları branchtan, master brancha merge etmeden önce bir diğer geliştirici ile birlikte gözden geçireceklerdir. Bu gözden geçirme sırasında aşağıdaki kontrol listesine uygunluk aranacaktır:

Kod Stili: Kod, Statik analiz araçları tarafından yakalanamayan method ve değişken isimlerinin proje standartlarına uygunluğu gibi kriterlere karşı incelenir.
Belgelendirme: Mümkün olduğunca yorum satırlarına gerek duyulmayan, anlaşılır kod yazılmalıdır. Ancak çeşitli nedenlerle kolayca anlaşılmayan bir kod öbeği varsa, bunun nedeni ve nasıl çalıştığı belgelendirilmelidir.
Girdilere Karşı Savunma: Kullanıcıdan ya da üçüncü parti servis ve uygulamalardan gelen veriler, temizlenip biçimlendirilmeli, hata denetiminden geçirilmeli ve gerekiyorsa try/except blokları içerisinde işlenmelidir.
Test Edilebilirlik: Sınıf ve metodlar birim testlerinin kolayca yazılabilmesine olanak verecek şekilde tasarlanmalıdır. Arayüzler (interface) mümkün olduğunca test ortamında taklit edilebilir olmalıdır.
Testler ve Kapsam: Kodun tamamını kapsayan, doğru tasarlanmış yeterli sayıda birim testi yazılmış olmalıdır. Dış servislere bağımlı işlevlerin testi için gerekli mocking kütüphane ve sunucuları kullanılmalıdır.
Ayarlanabilirlik: Uygulamanın çalışmasını ve davranışını etkileyen, dosya dizin yolları, açılır menüde gösterilecek seçenek sayısı gibi değerler ya kullanıcı tarafından ya da uygulamanın konfigurasyon standardına uygun şekilde (çevre değişkenleri) ile ayarlanabilir olmalıdır.
Çöp Kod: Yorum satırı haline getirilmiş kod olmamalıdır. Silinen herşey sürüm kontrol sisteminden geri getirilebilir.
Yapılacaklar: Todo olarak bırakılmış eksiklerin, sorun çıkarmayacağından emin olunmalıdır.
Döngüler: Döngüler uzunluk ve döngüden çıkış kriterlerinin uygunluğuna karşı denetlenmelidir.
Mevcudiyet Denetimi: Nesneler, kullanılmadan önce, o kapsamda mevcut olup olmadıklarına karşı denetlenmelidir. Bu denetimler, birçok hatanın kaynağında yakalanmasını sağlar.
Kod Tekrarı: Aynı işi yapan kodların tekrar yazılmasından kaçınılmalıdır. Bu amaçla özellikle projeye sonradan katılan geliştiricilerin, mevcut utility metodlarından haberdar olmaları sağlanmalıdır.

Arkauç Testleri¶

Bileşen (Birim) Testleri:¶

Sistemin arkaucunu oluşturan bileşenlerin tümü py.test test frameworkü kullanılarak test edilecektir. Birim testleri, kodun en az %60’ını kapsayacaktır (code coverage). Uygulamayı oluşturan tüm bileşenlerin birim testleri, kendi ana dizinleri altında “tests” dizininde tutulur. “py.test” komutu, proje ana dizini altında çalıştırıldığında, ismi “test” ile başlayan tüm Python dosyalarını tek tek tarayıp, içlerinde yine ismi “test” ile başlayan metodları çalıştırır. Örnek bir birim test aşağıda görülebilir.

from tests.data.test_data import data

from tests.data.test_model import Student

def test_model_to_json_compact():

st = Student(**data)

st.join_date = data[‘join_date’]

st.AuthInfo(**data[‘AuthInfo’])

for lct_data in data[‘Lectures’]:

lecture = st.Lectures(**lct_data)

lecture.ModelInListModel(**lct_data[‘ModelInListModel’])

for atd in lct_data[‘Attendance’]:

lecture.Attendance(**atd)

for exam in lct_data[‘Exams’]:

lecture.Exams(**exam)

clean_value = st.clean_value()

assert data == clean_value

Örnek birim testi 1 Py.test, standard “assert” ifadesinin testin başarılı olup olmadığının kontrolü için kullanır. Bu sayede testlerin hazırlanması, yeni geliştiriciler için neredeyse hiçbir ek öğrenme süreci gerektirmez.

Yukarıdaki test, benchmark eklentisiyle birlikte aşağıdaki gibi bir çıktı verecektir.

================== test session starts ==================

rootdir: /home/whogirl/Works/pyoko, inifile:

plugins: benchmark

collected 4 items

tests/test_model_to_json.py

— benchmark: 1 tests, min 5 rounds (of min 25.00us), 1.00s max time,

Name (time in us) Min Max Mean StdDev Rounds Iterations

test_model_to_json 214.0999 41221.8571 319.0611 1019.8894 1629 1

================== 1 passed in 1 .37 seconds ==================

Test frameworkünün, kod kapsam analiziyle birlikte çalıştırılması sonucu aşağıdaki gibi bir çıktı elde edilecektir. Bu örnekte pyoko modülünün test kapsam oranı %58 olarak görünmektedir.

py.test –cov pyoko ================== test session starts ================== platform darwin – Python 2.7.6 – py-1.4.27 – pytest-2.7.0 rootdir: /home/whogirl/Works/pyoko/pyoko, inifile: plugins: cov collected 4 items pyoko .... coverage: platform darwin, python 2.7.6-final-0
Name	Stmts	Miss	Cover
pyoko/__init__	1	0	100%
pyoko/db/base	165	118	28%
pyoko/db/connection	5	0	100%
pyoko/db/schema_update	20	10	50%
pyoko/db/solr_schema_fields	1	1	0%
pyoko/exceptions	11	0	100%
pyoko/field	46	8	83%
pyoko/lib/__init__	1	0	100%
pyoko/lib/py2map	22	17	23%
pyoko/lib/utils	16	5	69%
pyoko/model	106	7	93%
pyoko/settings	2	0	100%
TOTAL	397	166	58%
================== 4 passed in 3.14 seconds ==================

HİTAP gibi test ortamı sunmayan üçüncü parti servislerle veri alışverişi yapan modüllerin testleri, harici servisin istek / yanıt setlerini mimik eden Wiremock gibi bir simulatöre karşı yapılacaktır. Bu amaçla üretim ortamında servise gönderilen ve alınan veri trafiği kaydedilecek ve simulatör bu verilerle “eğitilecektir”.

Pyoko

Veri erişim katmanı (DAL) olarak görev yapacak olan Pyoko kütüphanesi için yazılacak birim testleri, veri doğruluğu ve API işlevlerine ek olarak çalışma hızı ve bellek kullanımı gibi kriterleri de göz önünde bulunduracaktır.

SpiffWorkflow Engine

Üçüncü parti bir kütüphane olarak projeye eklenmiş olan SpiffWorkflow’un geliştirilmesi ve bakımı uygulamanın ihtiyaçları doğrultusunda sürdürülecektir. Buna ek olarak, BPMN iş akışlarının doğruluğunun devamlı olarak sınanabilmesi için entegre bir test kaydetme ve çalıştırma modülü geliştirilecektir.

İş Akışı (Workflow) Testleri:¶

Sistemin tüm işlevlerinin üzerine inşa edileceği BPMN iş akışları, verilen girdilerle beklenen davranışı gösterip göstermediğine karşı test edilecektirler. Böylece iş akışları üzerinde yapılacak güncellemelerin, amaçlanan dışında yan etkilere neden olmadığından emin olunması sağlanacaktır.

Ulakbus projesinin iş akışları sunucuya gönderilen istek(request), sunucudan dönen cevap(response) tabanlı test edilmektedir.

Test için gerekli veriyi toplamak için;

Ulakbus.net’e gidilir.
Ayarlar(Dev) tıklanır, Backend Url’ye http://127.0.0.1:9001/ yazılıp kaydedilir ya da adres satırına ulakbus.net?backendurl=http://127.0.0.1:9001/ yazılıp enter tuşuna basıldığında aynı ayarlar yapılır.
İlgili iş akışının çalışabilmesi için veritabanında verilerin gerekli verilerin yüklü olması gerekir.
Adres satırına 127.0.0.1:9001/reset_cache komutu yazılıp enter tuşuna basıldığında ile cache temizlenir.
Tekrardan Ulakbus.net’e gidilir ve giriş yapılır.
Test edilecek iş akışı başlatılır,yazılan teste uygun şekilde iş akışı adımlarına tıklanır.
Test edilecek iş adımları bittikten sonra adres çubuğuna 127.0.0.1:9001/session_fixture komutu yazılıp enter tuşuna basılır.
Toplanan veriler iş akışı testinin adının test_ sonraki adıyla aynı olacak şekilde tests/fixtures dizinine .csv uzanstısıyla kaydedilir.

İş akışına testi başlamadan önce veritabanı boşaltılır, iş akışı testi için oluşturulmuş veriler yüklenir.

İş akışına ait test şu şekilde işler:

Sunucuya istek yapılır, sunucudan dönen cevapta belli koşullar aranır ve aranan koşulların olmaması durumunda AssertionError verir.
Sunucudan dönen cevaptaki nesnelerin değerleri ve nesnelerin sayısı ile veritabanından çekilen nesnelerin değerileri ve nesnelerin sayıları karşılaştırılır.

İş Akışı Test Örneği

import time
from pyoko.manage import FlushDB, LoadData
from ulakbus.models import OgrenciDersi
from zengine.lib.test_utils import *


class TestCase(BaseTestCase):
  """
  Bu sınıf ``BaseTestCase`` extend edilerek hazırlanmıştır.

  """

  def test_setup(self):
      """
      Okutman not girişi iş akışı test edilmeden önce veritabanı boşaltılır,
      belirtilen dosyadaki veriler veritabanına yüklenir.

      """

      import sys
      if '-k-nosetup' in sys.argv:
          return

      # Bütün kayıtlar db'den silinir.
      FlushDB(model='all').run()
      # Belirtilen dosyadaki kayıtları ekler.
      LoadData(path=os.path.join(os.path.expanduser('~'),
                                 'ulakbus/tests/fixtures/okutman_not_girisi.csv')).run()

  def test_okutman_not_girisi(self):
      """
      Okutman not girişi iş akışının ilk iki adımında ders şubesi ve sınav seçilir.

      Seçilen ders ve seçilen sınav ait notlar okutman tarafından onaylanmışsa;

      Dönen cevapta ``Notlar Onaylandı`` başlığı olup olmadığını test eder.


      ``Notlar Onaylandı`` başlığı var ise;

      Seçilen ders şubesine ait derslere kayıtlı öğrencilerin ad, soyad bilgisi ile
      sunucudan dönen öğrenci kayıt listesinin ad, soyad bilgisinin eşitliği test edilir.

      Kullanıcı, ders seçim ya da sınav seçim ekranına dönerek sınav ve ders
      seçebilir.


      ``Önizleme`` başlığı var ise;

      Seçilen ders ve seçilen sınav ait notlar okutman tarafından onaylanmamıştır.

      Seçilen ders şubesine ait derslere kayıtlı öğrencilerin ad, soyad bilgisi ile
      sunucudan dönen öğrenci kayıt listesinin ad, soyad bilgisinin  eşitliği test edilir.

      Notlar düzenlenebilir, onaylanabilir, ders seçim ekranına ya da sınav seçim
      ekranına dönülebilir.

      Notlar onaylandıktan sonra dönen cevapta hocalara bilgilendirme mesajı içeren
      ``Notlar Kaydedildi`` olup olmadığını test eder.

      Ders onaylanmadan önceki öğrenci sayısı ile ders onaylandıktan sonraki
      öğrenci sayısının eşitliği test edilir.

      İş akışı tekrar başlatılıp onaylanan ders  ve onaylanan sınav tekrardan seçilir
      ve gelen mesaj başlığında `Notlar Kaydedildi`` olup olmadığını test eder.

      """

      # Okutman kullanıcısı seçilir.
      usr = User(super_context).objects.get('Bkhc7dupquiIFPmOSKuO0kXJC8q')
      time.sleep(1)

      # Kullanıcıya login yaptırılır.
      self.prepare_client('/okutman_not_girisi', user=usr)
      self.client.post()

      # Ders şubesi seçilir.
      self.client.post(cmd='Ders Şubesi Seçin',
                       form=dict(sube='S7z8bvdNCBFSd9iCvQrb7O1pQ75', sec=1))
      # Seçilen şubeye ait sınav seçilir.
      resp = self.client.post(cmd='Sınav Seçin',
                              form=dict(sinav='7isfBEsi96AVDZdp2o33mQoWemJ', sec=1))

      assert resp.json['msgbox']['title'] == 'Notlar Onaylandı'

      # Veritabanından çekilen öğrenci bilgisi ile sıunucudan gelen öğrenci bilgisi
      # karşılaştırılarak test edilir.
      for i in range(0, len(resp.json['object']['fields'])):
          ogrenci_ders = OgrenciDersi.objects.filter(ders_id='S7z8bvdNCBFSd9iCvQrb7O1pQ75')
          ogrenci_ad = ogrenci_ders[i].ogrenci_program.ogrenci.ad + ' ' + ogrenci_ders[
              i].ogrenci_program.ogrenci.soyad
          assert ogrenci_ad == resp.json['object']['fields'][i][u'Adı Soyadı']

      # Ders seçim ekranına geri döner
      self.client.post(cmd='ders_sec',
                       form=dict(sinav_secim='null', ders_secim=1),
                       flow='ders_secim_adimina_don')
      # Ders şubesi seçilir.
      self.client.post(cmd='Ders Şubesi Seçin',
                       form=dict(sube='PRGgozMfVXSrAqyO2aMnjS6aBQo', sec=1))
      # Sınav seçilir.
      resp = self.client.post(cmd='Sınav Seçin',
                              form=dict(sinav='IvXH1cqyYoHznv0iRV4FjLvXWwz', sec=1))

      # Dersler okutman tarafından onaylanmamışsa;
      assert resp.json['forms']['schema']['properties']['kaydet']['title'] == 'Önizleme'
      assert 'inline_edit' in resp.json['forms']

      # Veritabanından çekilen öğrenci bilgisi ile sıunucudan gelen öğrenci bilgisi
      # karşılaştırılarak test edilir.
      for i in range(0, len(resp.json['forms']['model']['Ogrenciler'])):
          ogrenci_ders = OgrenciDersi.objects.filter(ders_id='PRGgozMfVXSrAqyO2aMnjS6aBQo')
          ogrenci_ad = ogrenci_ders[i].ogrenci_program.ogrenci.ad + ' ' + ogrenci_ders[
              i].ogrenci_program.ogrenci.soyad
          assert ogrenci_ad == resp.json['forms']['model']['Ogrenciler'][i][u'ad_soyad']

      # Öğrencilerin sayısı.
      num_of_ogrenci = len(resp.json['forms']['model']['Ogrenciler'])

      # Kayıtlar önizlenir.
      self.client.post(cmd='not_kontrol',
                       form=dict(Ogrenciler=resp.json['forms']['model']['Ogrenciler'], kaydet=1))

      # Sınav notları onaylanıp kaydedilir.
      # İş akışı bu adımdan sonra sona erer.
      resp = self.client.post(cmd='not_kaydet',
                              flow='end',
                              form=dict(kaydet_ve_sinav_sec='null', kaydet=1,
                                        kaydet_ve_ders_sec='null',
                                        not_duzenle='null', not_onay='null'))

      assert resp.json['msgbox']['title'] == 'Notlar Kaydedildi'

      # İş akışı tekrardan başlatılır.
      resp = self.client.set_path('/okutman_not_girisi')
      self.client.post()

      # Ders şubesi seçilir.
      self.client.post(cmd='Ders Şubesi Seçin',
                       form=dict(sube='PRGgozMfVXSrAqyO2aMnjS6aBQo', sec=1))

      # Sınav seçilir.
      resp = self.client.post(cmd='Sınav Seçin',
                              form=dict(sinav='IvXH1cqyYoHznv0iRV4FjLvXWwz', sec=1))

      assert num_of_ogrenci == len(resp.json['object']['fields'])
      assert resp.json['msgbox']['title'] == 'Notlar Onaylandı'

Benchmark Testleri:¶

İş akışı motoru, Pyoko gibi görev kritik modüllerin performansı pytest-benchmark eklentisi kullanılarak devamlı olarak ölçülüp kaydedilerek bu modüllerin performanslarındaki zamana bağlı değişim takip edilecek ve olası gerilemeler önlenecektir.

Servis Testleri:¶

Uygulamanın birçok işlevi Zato ESB üzerinde çalıştırılacak mikro servisler üzerinden sunulacaktır. Bu servislerin işlevselliği ve API uyumluluğu zato-apitest frameworkü ile yazılacak testler ile sınanacaktır.

Kural Motoru (Rule Engine) Testleri:¶

Uygulamanın iş mantığının önemli bir kısmını oluşturan kural setleri, belirli girdilerle beklenen çıktıları verip vermediklerine karşı denetelenmelidir.. Bu amaçla kural setleri standart birim testleri içerisinde kural motoru ile işletilerek beklenen çıktıyla eşleştirilecektir.

Kurulum ve Yayınlama Aşaması Testleri¶

Kurulum ve Yayınlama (Build Release) aşamasında Buildbot aracılığı ile

kurulum ve kütüphane bağımlılık testleri
Uygulamanın tüm bileşenlerine ait birim testleri
Entegrasyon testleri uygulanacaktır.

Test Sunucuları ve Geliştirme Test Döngüsü:¶

Her iş (issue) kendi geliştirme branchinde geliştirilir ve yapılan değişiklikler küçük parçalar halinde commit edilir. Git flow esas alınarak yapılan git iş akışı sonunda develop branchiyle birleştirilir ve uzak repoya gönerilir. develop branch’ine yapılan pushlar buildbot’u tetikler ve test, kurulum ve yayınlama aşamasını başlatır. develop branch’indeki son değişiklikler sürekli olarak nightly kurulum adresinden erişilebilir.

Yayına Alma (Production):¶

Sürüm adayı haline gelen master branchte bulunan kaynak kod, aşağıda detaylı şekilde anlatılan sürüm öncesi kabul testlerinden geçer. Bu testlerin başarılı olması halinde, semantik sürümlendirme sistemine göre etiketlenir (tagging).

Semantik sürümlendirme sistemine göre kullanılacak desen MAJOR.MINOR.PATCH şeklindedir. Buna göre 3 haftalık küçük sürümler MINOR, gündelik çözülen işler PATCH, önceden belirlenmiş hedefleri kapsayan fazların sonunda ise MAJOR değerleri arttırılır.

MINOR sürümler çıktıkça, buildbot taglenmiş sürümdeki depoları production ortamında yayına alır. Gerekli dosyaları kopyalar ve veritabanı şemalarını yeni sürümlere göç ettirir.

Kullanıcı Arayüzü Testleri¶

Kullanıcı Arayüz Testlerı üç başlıkta yapılır: - Bileşen (Birim) Testleri - Kabul (E2E) Testleri - Manuel Testler

Kullanıcı Arayüzü AngularJS ile Model-View-Controller (MVC) yapısı ile programlanacaktır. Modül yapısı aşağıdaki örnekte olduğu gibidir:

app/

dashboard/

dashboard.html (template) dashboard.js (Controller ve Model tanımlarının olduğu dosya) dashboard.test.js (Testlerin yazıldığı dosya)

… (diğer modüller)

app.css (stil dosyası) app.js (Uygulamanın tanımlandığı yapılandırıldığı dosya)

karma.conf.js (testlerin çalışma zamanı yapılandırmalarını içeren dosya)

Bileşen (Birim) Testleri:¶

Uygulamada *.test.js dosyaları modüllerin Unit testlerinin barındığı dosyalardır. Unit testler Jasmine test uygulama çatısı kullanılarak yazılır. Uygulamanın Giriş (Login) modülü için yazılmış bir örnek aşağıdaki gibidir:

describe('zaerp.login module', function () {

   beforeEach(module('zaerp.login'));

   describe('login controller', function () {

         it('should have a login controller', inject(function (){

 expect('zaerp.login.LoginCtrl').toBeDefined();

     }));

   });

 });

Bu test örneğinde “login controller”ının tanımlanmış olması gerekliliği test edilmektedir. Kullanıcı arayüzü unit testleri karma test yürütücüsü (test runner) ile çalıştırılır. Bunun için yukarıda açıkladığımız yapıda da görüleceği gibi “karma.conf.js” ismiyle bir yapılandırma dosyası bulunmaktadır. Karma yapılandırma örneği aşağıdaki gibidir:

module.exports = function (config) {

    config.set({

        basePath: './',

         files: [

            'app/bower_components/angular/angular.js',

            'app/bower_components/angular-route/angular-route.js',

            'app/bower_components/angular-mocks/angular-mocks.js',

            'app/app.js',

            'app/components/\*\*/\*.js',

            'app/login/\*.js',

        ],

        autoWatch: true,

        frameworks: ['jasmine'],

        browsers: ['ChromeCanary'],

        plugins: [

            'karma-chrome-launcher',

            'karma-firefox-launcher',

            'karma-jasmine',

            'karma-junit-reporter'

        ],

        junitReporter: {

            outputFile: 'test_out/unit.xml',

            suite: 'unit'

        }

    });

};

Bu yapılandırmada test dosyalarının hangileri olduğu ve testlerin çalışması için uygulama bağımlılıkları (dependencies) “files” anahtarında, hangi test uygulama çatısı kullanılacağı “frameworks” anahtarında, hangi tarayıcının kullanılacağı “browsers” anahtarında ve eklentiler “plugins” anahtarında belirtilmektedir.

Unit testler nodejs kullanılarak uygulama kök dizininde “npm test” komutuyla çalıştırılır. Örnek bir test çıktısı aşağıdaki gibidir:

INFO [watcher]: Changed file “zetaops/ng-zaerp/app/login/login_test.js”. Chrome 45.0.2412 (Mac OS X 10.10.3): Executed 8 of 8 SUCCESS (0.409 secs / 0.063 secs)

Bu çıktıdan 8 test senaryosunun başarıyla geçtiği görülmektedir (Executed 8 of 8 SUCCESS (0.409 secs / 0.063 secs)).

Birim testlerinin kodun ne kadarını kapsadığı yine karma ile incelenecektir. Karma testler çalıştıktan sonra coverage/ dizini altında bir html dosyası oluşturarak kod kapsama oranını yayınlar. Örnek html çıktı sayfası şu şekildedir:

Kabul Testleri:¶

Ulakbus projesinin kabul testleri Selenium kullanılarak test edilir. Selenium, tarayıcı tabanlı uygulamaları otomatikleşirmek için kullanan açık kaynak kodlu bir test framework’tür.

Neden Selenium?¶

Açık kaynak.
Birçok programalama dilini destekler.
Birden fazla tarayıcı ve platform ile uyumludur.
Testlerin paralel çalışmasına imkan verir.
İnsan kaynaklı hataları azaltarak testin doğruluğunu artırır.
Geniş bir kullanıcı tabanına ve yardım topluluklarına sahiptir.

http://cdn2.softwaretestinghelp.com/wp-content/qa/uploads/2014/10/Selenium-intro-1-new.jpg

Selenium Test Örnekleri¶

Document Object Model içinde username ve password tanımlı id alanlarına kullanıcı adı ve kullanıcı şifresi değerleri gönderilerek kullanıcı giriş yapar.

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

class Logging(object):
    # Yeni bir Firefox penceresi açar.
    driver = webdriver.Firefox()
    # Belirtilen adresindeki sayfayı yükler.
    driver.get('http://nightly.ulakbus.net/#/dashboard')
    # Document Object Model'in yüklenmesi bekler.
    driver.implicitly_wait(10)

    def do_login(self):
        email_field = self.driver.find_element_by_id("username")
        # Kullanıcı adı alanına 'test_user' yollar.
        email_field.send_keys("test_user")
        password_field = self.driver.find_element_by_id("password")
        # Sifre alanına '123' yolluyor.
        password_field.send_keys("123")
        # Giriş tuşuna tıklar.
        self.driver.find_element_by_css_selector('.btn').click()
        # Panel tusunu gorene kadar kullanıcının login olmasını 25 saniye bekler.
        WebDriverWait(self.driver, 25).until(
        EC.element_to_be_clickable((By.CSS_SELECTOR, '#side-menu > li:nth-child(1) > a:nth-child(1)')))

Kullanıcı giriş yaptıktan sonra gerekli ayarlar yapılır.

from test_login import Logging

class Settings(Logging):
    def do_settings(self):
        # Kullanıcıya giriş yapar.
        self.do_login()
        self.driver.find_element_by_css_selector('li.dropdown:nth-child(4) > a:nth-child(1)').click()
        # Ayarlar(dev)'e tıklar.
        self.driver.find_element_by_css_selector('.dropdown-menu > li:nth-child(4) > a:nth-child(1)').click()
        # Backend Url'ye değer gönderir.
        self.driver.find_element_by_css_selector('.form-control').send_keys('https://test.ulakbus.net/')
        # Kaydet'e tıklar.
        self.driver.find_element_by_css_selector('button.btn:nth-child(2)').click()

Gerekli ayarlar yapıldıktan sonra Önceki Eğitim Bilgilerine tıklar ve tanımlı alanlara değerler yollayarak yeni bir önceki eğitim kaydı oluşturarak kaydeder.

from test_settings import Settings

class TestCase(Settings):
    def test_sidebar(self):
      # Ayarları yapar.
      self.do_settings()
      # Genel'e tıklar.
      self.driver.find_element_by_css_selector(
          'li.ng-binding:nth-child(3) > a:nth-child(1) > span:nth-child(2)').click()
      # Önceki Eğitim Bilgilerine tıklar.
      self.driver.find_element_by_css_selector('ul.in:nth-child(2) > li:nth-child(6) > a:nth-child(1)').click()
      # Backend ayarları değiştirildiği için kullanıcının tekrar giriş yapması gerekir.
      self.do_login()
      # Genel'e tıklar.
      self.driver.find_element_by_css_selector(
          'li.ng-binding:nth-child(3) > a:nth-child(1) > span:nth-child(2)').click()
      # Önceki Eğitim Bilgilerine tıklar.
      self.driver.find_element_by_css_selector('ul.in:nth-child(2) > li:nth-child(6) > a:nth-child(1)').click()
      # Mezun Oldugu Okul'a değer yollar.
      self.driver.find_element_by_css_selector('#okul_adi').send_keys('Anadolu Lisesi')
      # Diploma Notu'na değer yollar.
      self.driver.find_element_by_css_selector('#diploma_notu').send_keys('76')
      # Mezuniyet Yılı'na değer yollar.
      self.driver.find_element_by_css_selector('#mezuniyet_yili').send_keys('2008')
      # Kaydet'e tıklar.
      self.driver.find_element_by_css_selector('.btn-danger').click()

Selenium hakkında daha fazla bilgi almak için http://www.seleniumhq.org/docs/

Manuel Testler:¶

Tarayıcılara has hatalar, görsel düzenlemeler ve diğer otomatik olarak test edilemeyen arayüz özellikleri ve fonksiyonları manuel olarak test edilecektir.

Sürüm Öncesi Kabul Testleri¶

Test Senaryoları¶

Ihtiyaç analiz belgelerinde belirtilen kullanıcı senaryolarına uygun şekilde test senaryoları yazılacaktır. Test senaryolarının amacı, ihtiyaç analizinde ortaya çıkan gereksinimlerin, geliştirme faaliyeti sonucu ortaya çıkan ürün ile karşılanıp karşılanmadığıdır.

Sürüm aşamasında önceden yazılmış test senaryoları, kullanıcılar tarafından manuel şekilde uygulanır ve sonuçlar raporlanır. Bazı test senaryoları otomatik olarak da gerçeklenebilirler.

Bizim uygulamamızda test senaryoları bir veya birden çok iş akışından (workflow) oluşan eylemler dizisi şeklinde olacaktır. Birden çok aktör ve ön koşulu içinde barındıran, problemi yeterli karmaşıklık düzeyine getirecek belirli sayıdaki öğrencinin ders seçimi ve sonuçlarının web sitelerinde yayınlanması veya öğrenciler için ders programının hazırlanması gibi..

Kullanılabilirlik Testi¶

Uygulama ekranları, uluslararası kabul görmüş kullanılabilirlik ilkeleri (w3c) ve KAMİS (Kamu Internet Siteleri Rehberi)’nin temel aldığı TS EN ISO 9241-151 (İnsan-Sistem Etkileşiminin Ergonomisi Standartları), WCAG ve ISO/IEC 40500:2012 (Web İçeriği Kullanılabilirlik Standartları ve Kriteri) standartlarında uygunluğu test edilecektir.

Bu amaçla genel bir kontrol listesi (checklist) hazırlanmıştır:

Genel Görünüm

Klavye kısayollarıyla gezinmek mümkün mü?
Klavye kısayollarıyla gezinmek kolay mı?
Sayfalar otomatik olarak yenilenmemeli
Website iletişim bilgileri, referansları uygun bir alanda mı?
Servis/hizmet/uygulama bilgilerine kolayca erişiliyor mu?
Görme engelliler için erişilebilirlik düzenlenmiş mi?
Grid sistem kullanılmış mı?
Klavye kullanımı sitedeki tüm işlemleri kapsıyor mu?
Kullanıcılara içerikleri okuyabilmeleri için yeterli zaman verililyor mu?
Hukuki ya da mali sonuçları olan işlemlerde kullanıcının hata yapma olasılığı azaltılmalıdır.

Anasayfa

Amacı kolay anlatıyor mu?
Yapmak istediği işleme kolay ulaşılıyor mu?
Sayfa görünümü pozitif bir intiba bırakıyor mu?
Giriş yapan kullanıcı ismi yer alıyor mu?
Büyük değişiklikler ana sayfadan duyuruluyor mu?
Konum ve iletişim bilgileri yer alıyor mu?
Lisans, sözleşme gibi statik sayfalara linkler var mı?
Sayfadaki imajlar ve/veya videolar amaçla alakalı mı?
Site hem www alt alanadıyla hem alt alanadı olmadan erişilebilir mi?
Sitede yapılacak temel işlemler ana sayfada yer alıyor mu?

Yönetim Paneli

İçerikler kullanıcı rolüyle ilgili mi?
Uyarılar zamanında ve etkili şekilde gösteriliyor mu?
Uyarılar öncelik ve önem derecelerine göre renklendirilmiş mi?
Birden fazla role sahip kullanıcılar için roller arası geçişi sağlayan bir buton var mı?

Erişilebilirlik

İmajların “alt” özellikleri kullanılmış mı?
İçerik stil dosyası (css) olmadan da okunabilir mi?
Bağlantılar, butonlar ve seçim kutuları kolayca tıklanabilir mi?

Örnek erişilebilirlik testi: http://achecker.ca/checker/index.php

Site İçi Yönlendirme

Önemli bağlantılar sayfanın hareketli öğelerinde olmamalı
Linkler alfabetik olarak sıralanmamalı, gruplanmalı
Kullanıcı sitede hangi sayfada olduğunu kolayca farkedebilmeli
Yönlendirme bağlantıları her sayfada görünür mü?
Bağlantılar açıklayıcı mı?
Title’da site ve o sayfanın kısa bir açıklaması var mı?
Site url’si akılda kalıcı mı?

Arama

Bir arama kutusu var mı?
Arama kutusu her sayfada görünür mü?
Arama kutusu yeterince geniş mi?
Arama sonuçları kategorilendiriliyor mu?

Bağlantılar

Önemli komutlar bağlantı yerine buton olarak gösterilmeli, örn: kaydet gibi
Linkler kolayca farkedilir mi?
Kırık (erişilemeyen) link olmamalı

Şablon

Önemli içerikler öncelikli olarak gösteriliyor mu?
Site şablonu farklı ekran boyutlarında ölçekleniyor mu?
Birbiriyle alakalı bilgiler gruplandırılmış mı?
Tüm sayfalarda tutarlı mı?
Sayfalar çok sıkışık olmamalı

Formlar

Formlar kolay doldurulabilir mi?
Form alanlarının açıklamaları var mı?
Alanların alması gereken değerler kullanıcıya gösteriliyor mu?
Çok uzun açılır menüden kaçınılmış mı?
Form alanlarının isimleri açık ve anlaşılır mı?
Form onay butonu var mı?
Hata mesajları ilgili form alanının yanında yer alıyor mu?
Birden fazla adımdan oluşan formlar için hangi adımda olduğu anlaşılıyor mu?

İçerik

Metin ve arkaplan rengi arasında yeterli derecede kontrast var mı?
İçerik gözle taranabiliyor mu?
İçerik temiz bir dille yazılmış mı?
İletişim bilgileri açık şekilde yazılmış mı?
İçerik kullanışlı ve güncel mi?
Dil kurallarına uyuyor mu?
İçerik sıralaması anlamlı mı?
İçeriklerin ayırt edilebilmesi ya da doğru anlaşılabilmesi için renk kullanımına dikkat edilmiş mi?
Hareketli içerikler kullanıcılar tarafından kontrol edilebiliyor mu?
Tekrarlı içerikler pas geçilebiliyor mu?
Metin öğeleri yeniden boyutlandırılabilir mi?

Her ekran kontrol listesi formu ile birlikte açılır. Test kullanıcıları bu formu doldurup kaydederler. Sonuçlar ilgili servise raporlanır.

Performans Testleri¶

Load Tests:¶

Yük testleri, uygulamanın belirli parçalarının yoğun trafik altındaki davranışlarını ölçmek amacıyla yapılır. Yayınlama aşamasında önceden belirlenen yük değerleri ile otomatik şekilde gerçekleştirilecektir. Bu amaçla geçici sanal makineler oluşturulacak, testler bu makineler üzerinde gerçekleştirilecektir. Temel test aracımız Tsung olarak seçilmiştir. Tsung birçok farklı protokolde detaylı şekilde özelleştirilebilen requestler hazırlamaya olanak vermektedir.

Ağ Kullanımı ve Web Sayfa Başarımı:¶

Ağ Kullanımı uygulama modüllerinin gerektiğinde çağırılacak şekilde düzenlenmesi (lazy load), statik dosyaların (javascript, css, imaj ve diğer dosyalar) optimize ve minimize edilmesi gibi konuları içerir. Bu süre çevrimiçi araçlar ve tarayıcılar kullanılarak test edilir.

Render Performansı:¶

Sayfa render süresi kod tekrarı, optimizasyonu, DOM kullanımı gibi bilinen gerekliliklere göre kısalmaktadır. Sayfa bileşenlerinin yüklenme süresinden sonra gereken tüm fonksiyonların çalıştırılması ve stillerin uygulanması süresi render performansıdır. Tarayıcının yeteneklerine bağımlı olsa da belirlenecek minimum değerin altında olmamalıdır. Selenium ile test edilecektir.

Güvenlik Testleri¶

Uygulamanın güvenlik test ve kontrolleri için Open Web Application Security Project (OWASP) topluluğunun yayınladığı test rehberinde yer alan testlerin bazıları kullanılacaktır. 11 konu başlığı altında toplanan testlerin uygulamamız için uygun olanları seçilerek her sürüm öncesi kabul testleri aşamasında uygulanacaktır.

Kontroller Sistem Hakkında Bilgi Toplama, Yapılandırma ve Yayınlama, Kimlik Yönetimi, Kimlik Doğrulama ve Yetkilendirme, Oturum Yönetimi, Girdi Geçerliliği, Hata Ayıklama, Şifreleme, İş Mantığı, İstemci Tarafı Testleri başlıkları altında yapılacaktır.

Yapılacak testler ayrıca ISO 27002 bilgi güvenliği standartlarında belirlenen kriterlerin tamamlanması için kuruma destek olacaktır.

Temel Yönetim Komutları¶

Komut satırı yönetim aracı manage.py ile kullanıcı ekleme, veritabanı yedekleme, geliştirme sunucusu çalıştırma gibi birçok operasyon kolaylıkla yapılabilir.

-h or –help¶

Yardım mesajını gösteririr ve çıkış yapar.

usage¶

$ ./manage.py -h or $ ./manage.py -help

dump_data¶

Bütün modellere ait verileri standart çıktıya ya da belirtilen dosyaya yazar.

usage¶

$ ./manage.py dump_data [-h] [--timeit] --model [MODEL] [--path [PATH]]
                        [--type [{csv,json,json_tree,pretty}]]
                        [--batch_size [BATCH_SIZE]]

Zorunlu olan argüman:¶

model [MODEL] Dökümü alınacak modellerin isimleri yazılır. Bütün modellerin dökümü alınacaksa ‘all’ yazılır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösteririr ve çıkış yapar.
–timeit İşlemin süresini ölçer.
–path [PATH] Standart çıktı yerine, belirtilen dosyaya yazar.
–type [{csv,json,json_tree,pretty}]
1. csv: csv varsayılan formattır. Her satıra bir tane kayıt yazar. csv, diğerlerinden daha hızlıdır ve belleği daha verimli kullanır çünkü JSON encoding/decoding işlemlerini yapmaz.
2. json: Her bir kayıt için, ayrı bir json string içeren bir döküman yazar. Dökümandaki her satır bir kayda ait json stringidir. json-tree’nin aksine, bellek kullanımı kayıt başına artmaz.
3. json_tree: Büyük veritabanlarında kullanmayın. Bütün dökümü tek bir JSON nesnesi olarak yazar.
4. pretty: Büyük veritabanlarında kullanmayın. json_tree’nin formatlanmış versiyonu.

load_data¶

Belirtilen dosyadan verileri okur ve modelleri doldurur.

usage¶

$ ./manage.py load_data [-h] [--timeit] --path [PATH] [--update]
                        [--type [{csv,json,json_tree,pretty}]]
                        [--batch_size [BATCH_SIZE]]

Zorunlu olan argüman:¶

–path [PATH] Veri dosyası ya da fixture dizininin yoludur. Bir dizinden veri yükleyeceği zaman, .js ve .csv uzantılı dosyaları kullanır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösteririr ve çıkış yapar.
–timeit İşlemin süresini ölçer.
–update Varolan kayıtların üzerine yazar.Objenin varlığını kontrol etmeyecek bu yüzden daha hızlı çalışacak.
-batch_size [BATCH_SIZE] Solr’dan varsayılan miktardaki(1000) nesneleri tek seferde bulup getirir.
–type [{csv,json,json_tree,pretty}]
1. csv: csv varsayılan formattır. dump_data ile elde edilmiş veya geçerli bir csv dosyası olabilir.
2. json: dump_data ile elde edilmiş veya geçerli bir json dosyası olabilir.
3. json_tree: dump_data ile elde edilmiş veya geçerli bir json_tree dosyası olabilir.
4. pretty: dump_data ile elde edilmiş veya geçerli bir pretty json_tree dosyası olabilir.

load_fixture¶

Fixture’ları verilen json dosyasından ya da verilen dizindeki json dosyalarından yükler. Verileri, ulakbus_settings_fixtures isimli bucket içine, mevcut keylerin üzerine yazarak doldurur.

usage¶

$ ./manage.py load_fixture [-h] [--timeit] --path [PATH]

Zorunlu olan argüman:¶

–path [PATH] Fixture dosyasını ya da dizinini yükler.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

migrate¶

Verilen model ya da modeller için yeni SOLR şemaları üretir veya mevcutları günceller.

usage¶

$ ./manage.py migrate [-h] [--timeit] --model [MODEL] [--threads [THREADS]]
                      [--force]

Zorunlu olan argüman:¶

model [MODEL] Dökümü alınacak model isimleridir. Bütün modellerin dökümü alınacaksa ‘all’ yazılır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.
–threads [THREADS] Threadler’in maksimum sayısıdır.Varsayılan deger 1’dir.
–force Şema yaratımını zorunlu kılar.

flush_model¶

Modellere ait bucket’ların içeriğini siler.

usage¶

$ ./manage.py flush_model [-h] [--timeit] --model [MODEL]

Zorunlu olan argüman:¶

–model [MODEL] Silinecek olan model isimleridir. Bütün modelleri silmek için ‘all’ yazılmalıdır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

update_permissions¶

İzinleri veritabanı ile senkronize eder.

usage¶

$ ./manage.py update_permissions [-h] [--timeit] [--dry]

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.
–dry Degişiklik yapmaz sadece listeler.

shell¶

IPython shell’ini çalıştırır. Bu shell projeye ait tüm modelleri yükler ve kullanıma hazır hale getirir. Çalışma kolaylığı sağlar.

usage¶

$ ./manage.py shell [-h] [--timeit] [--no_model]

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.
–no_model Modelleri içe taşımaz(import).

runsever¶

Geliştirme sunucusunu çalıştırır.

usage¶

$ ./manage.py runserver [-h] [--timeit] [--addr [ADDR]] [--port [PORT]]

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.
–addr [ADDR] Sunucunun dinleyeceği adres. Varsayılan 127.0.0.1’dir.
–port [PORT] Sunucunun dinleyeceği port. Varsayılan 9001’dir.

create_user¶

Yeni kullanıcı yaratır.

usage¶

$ ./manage.py create_user [-h] [--timeit] --username [USERNAME] --password
                          [PASSWORD] [--abstract_role [ABSTRACT_ROLE]]
                          [--super] [--permission_query [PERMISSION_QUERY]]

Zorunlu olan argümanlar:¶

–username [USERNAME] Kullanıcı adı
–password [PASSWORD] Şifre

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.
[–abstract_role [ABSTRACT_ROLE]] AbstractRole
–super Süper kullanıcı
–permission_query [PERMISSION_QUERY] Bu sorgudan dönen izinler yenı eklenen kullanıcıya tanımlanır. Varsayılan: “code:crud* OR code:login* OR code:logout*”

generate_diagrams¶

Modellerden PlantUML diyagramları oluşturur.

usage¶

$ ./ manage.py generate_diagrams [-h] [--timeit] [--daemonize]
                                 [--model [MODEL]] [--path [PATH]]
                                 [--split [{no,app,model}]]

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösteririr ve çıkış yapar.
–timeit İşlemin süresini ölçer.
model [MODEL] Diyagramı çizilecek modellerin adı buraya yazılarak seçilir. Tüm diyagramları seçmek için ‘all’ girilebilir. Eğer bu seçenek verilmediyse tüm modeller için diyagram oluşturulur.
–path [PATH] Standart çıktı yerine, belirtilen dosyaya yazar. Eğer ‘split’ seçeneği ‘app’ veya ‘model’ seçilirse ‘path’ verilmesi zorunludur.
–split [{no,app,model}]
1. no: Tüm modelleri tek bir diyagrama yerleştirir ve standart çıktıya ya da tek bir dosyaya yazar.
2. app: Modelleri, Metaclasslarındaki ‘app’ alanına göre gruplayarak ayrı dosyalara yazar. Bu seçenek seçilirse ‘path’ seçeneğiyle bir dosya adı verilmelidir. Dosyaları ‘path’ seçeneğindeki isim ve ‘app’ isimleri ile kaydeder, örneğin ‘–path diagrams.puml’ seçildiyse dosyaları ‘diagrams.app.puml’ şeklinde kaydeder.
3. model: Modellerin her birini ayrı dosyalara yazar. Bu seçenek seçilirse ‘path’ seçeneğiyle bir dosya adı verilmelidir. Dosyaları ‘path’ seçeneğindeki isim, ‘app’ isimleri ve model ismi ile kaydeder. Örneğin ‘–path diagrams.puml’ seçildiyse dosyaları ‘diagrams.app.model.puml’ şeklinde kaydeder.

Bu komut ile oluşturulan diyagramlar PlantUML’in çizim sınırlarını aşabilir. Oluşan diyagramların çizilirken yarım kalması durumunda PlantUML’e bir çevre değişkeni verilerek diyagramları çizmesi sağlanabilir:

$ env PLANTUML_LIMIT_SIZE=8192 plantuml my-diagram.puml

Veri Üreteçleri¶

Aşağıda sıralanan komutlar geliştirme esnasında fake(uydurma) veriler üretmek amacıyla eklenmiştir.

random_personel¶

Rastgele Personel üretir.

usage¶

$ ./manage.py random_personel [-h] [--timeit] --length [LENGTH]

Zorunlu olan argümanlar:¶

–length [LENGTH] Rastgele üretilecek personel sayısıdır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

random_harici_okutman¶

Rastgele Harici Okutman üretir.

usage¶

$ ./manage.py random_harici_okutman [-h] [--timeit] --length [LENGTH]

Zorunlu olan argüman:¶

–length [LENGTH] Rastgele üretilecek okutmanın sayısıdır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

random_ogrenci¶

Rastgele Ögrenci üretir.

usage¶

$ ./manage.py random_ogrenci [-h] [--timeit] --length [LENGTH]

Zorunlu olan argüman:¶

–length [LENGTH] Rastgele üretilecek öğrenci sayısıdır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

random_okutman¶

Personel veya HariciOkutman modellerinden rastgele Okutman üretir.

usage¶

$ ./manage.py random_okutman [-h] [--timeit] --length [LENGTH]

Zorunlu olan argüman:¶

–length [LENGTH] Rastgele üretilecek okutmanın sayıdır.

Zorunlu olmayan argümanlar:¶

-h,–help Yardım mesajını gösterir.
–timeit İşlemin süresini ölçer.

ESB ve SOA ne anlama geliyor yani?¶

Sistemlerin sistemini düşünmek hakkında harika bir özet olmuş.

Nick Coghlan, Core Python Geliştiricisi

Aşağıdaki dillerde okuyabilirsiniz. Català, Deutsch, Français, Português, ру́сский İngilizce ve 中文.

ESB tanımının SOA ile bağlantılı oluşu kafa karışıklığına neden oluyor. ESB Kurumsal Veri Yolu (KVY) şeklinde ifade edilebilir. SOA kavramı ise Servis Odaklı Mimari şeklinde kullanılabilir.

Ama bu kavramlar da, sürü sepet kurumsal gevezelik olmadan, sade bir Türkçe ile bile yeterince açık olmuyor maalesef.

Tüm gerçek¶

Bankanızın uygulamasına girdiğinizde neler olduğunu bir düşünün:

Adınız görüntülenir
Hesabınızdaki para oradadır
Kredi kartlarınız ve kart borcu görüntülenir
Varsa aldığınız krediler görüntülenir
İlgilenebileceğiniz kredilerin bir listesi de oradadır

Tüm bu bilgi, birbirinden farklı sistemler ve uygulamalardan gelmektedir ve her biri veriyi (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV, ve aslında çok da önemli olmayan): değişik bağlantı şekillerinden görünür hale getirmektedir.

CRM uygulaması Linux ve Oracle ile çalışıyor
z/OS mainframe sistem üzerinde COBOL ile yazılmış
Mainframe dedik ama size herşeyi söylemek için pek ağzı sıkı olan bu sistemler size sadece CSV verisi gönderirler
Windows üznerinde PHP ve Ruby çalışmaktadır.
PostgreSQL, Python ve Java Linux ve Solaris üzerinde çalışmaktadır

Şimdi sorumuz arayüz uygulamasını 1-5 arası çalışan tüm bu uygulamalarla nasıl konuşur hale getireceksiniz? Bittabiki bunu yapmayacaksınız

Bu ayrı mimarilerin birbiriyle doğrudan konuşmasına izin vermeyeceksiniz. Bu, zaten başa çıkılması zor olan mimarilerin her birinin, kendi içinde ölçekli çalışabilmesini sağlayabilmek için temel bir ilkedir.

Aşağıdaki çizimde, sistemin yaptığı her bir servis çağrısı değişik boyut ve stilde belirtilmiştir.

Resimler şu adresten alınmıştır. https://zato.io/docs/intro/esb-soa-tr.html

Lütfen dikkat ediniz, daha üst seviye süreçleri bu çizimde göstermedik bile. Mesela App1, App6’nın daha önce verdiği cevaba göre App2 veya App3 ya da App5’i çağırır ve böylece App4 daha sonra App2 tarafından üretilen veriyi alır ve fakat sadece App1 veri çekmeye izin veriyorsa ;_;

Ayrıca not ediniz, daha sunucuların birbirleriyle olan iletişiminden hiç bahsetmedik misal her bir sistem 10 adet fiziki sunucuda çalışıyor olabilir ve bu durumda 60 adet fiziki sunucu birbiriyle konuşuyor olabilir.

Ve fakat, hala bazı sorularımız kalıyor geriye.

Bu arayüzleri nasıl birbirinden ayıracağız? Yeni sürümü nasıl planlayabilirsiniz? Her biri değişik ekipler, satıcılar veya bölümler tarafından yönetilen uygulamaların güncellemelerini ya da sürüm indirimlerini nasıl koordine edeceksiniz? Üstelik işin başındaki ekibin yarısı çoktan işten ayrılmışken?

Eğer 6 değişik uygulamayla başa çıkabileceğinizi düşünüyorsanız, 30 taneye ne dersiniz?

Resimler şu adresten alınmıştır. https://zato.io/docs/intro/esb-soa-tr.html

Peki 400 ayrı uygulama ile başa çıkabilir misiniz? Ya 2000? Her bir uygulamanın 10 sunucu gerektiren tekil bir ortamda koştuğunu ve bu 20K’lık sistemin parçalarının kıtalara dağıtık olduğunu ve arada her türlü teknik ve kültürel sınırlar olduğunu, üstelik sistemin her bir parçasının hiç bir kesinti olmadan son derece geveze bir şekilde, diğer parçalarla sürekli olarak durmadan mesaj alıp verdiğini? (Bu durumun çizimini paylaşmayacağız korkmayın)

Bu duruma gayet uyan bir tanımımız var. Buna karmaşa diyoruz.

Bu karmaşayı nasıl düzelteceksiniz?¶

Yapılacak ilk şey, durumun kontrolden çıktığını kabul etmektir. Bu da size çok fazla suçluluk hissetmeden vaziyeti kurtarma şansı verir. Tamam, oldu bir kere, daha iyisini bilmiyordunuz, ama şimdi düzeltmek için bir çare var.

Bu, belki de kurumun IT yaklaşımında yapısal bir değişiklik anlamına gelebilir fakat başka bir adım da, sadece etrafa veri basmak için yaratılmamış sistem ve uygulamaları feshetmek olabilir. Bunların hepsinin amacı, bulunduğunuz sektörün ne olduğuna bakılmaksızın iş süreçleriniz olmalıdır. Bankacılık, ses kaydı tutma, muhasebe, telsizle yer bulma cihazları, web uygulamaları vb. her tür iş.

Bu ikisini açıklıkla belirlediğiniz zaman sisteminizi servisler etrafında kurmak üzere düşünmeye başlayabilirsiniz.

Servis, diğer uygulamaların kullandıklarında mutlu olacakları, “ilginç olan”, “tekrar kullanılabilir (reusable)” ve “atomik” bir şeydir ve asla iki endpoint arasında noktadan noktaya erişime açılmaz. Bu, servis hakkında olası en kısa anlamlı açıklamadır.

Eğer bir sistemdeki işlevsellik şu 3 ihtiyacı karşılıyorsa;

İ lginç
T ekrar kullanılabilir
A tomik

bu sistem, diğer sistemlere asla doğrudan olmamak üzere açılabilir. (expose edilebilir)

Buyrun bu İTA yaklaşımını bir kaç örnek üzerinden tartışalım.

Değişken	Notlar
Ortam	Elektrik şirketi CRM uygulaması
İşlev	2012 3. çeyreğinden beri self servis portalinde aktif olan müşterilerin listesini döndür.
İlginç mi?	Evet gayet ilginç. Bu pek çok değişik rapor ve istatistikte kullanılabilir.
Tekrar kullanılabilir mi?	Hayır, pek sayılmaz. Ancak tüm yılın istatistikleri gibi daha üst seviye kurgular yapmaya izin verir, ancak açıktır ki 2018 yılı için kullanmaya pek de olanak yok.
Atomik mi?	Büyük bir olasılıkla evet. Eğer yılın diğer çeyrekleriyle ilgili bilgi veren başka servisler de varsa, tüm yıl için bir fikre varılabilir.
Nasıl İTA olacak?	Sadece bir çeyrek zaman aralığı yerine, rastgele başlama ve bitiş tarihlerini kabul edecek hale getirmek. Sadece portal değil, başka herhangi bir sebeple sisteme bağlanacak olan uygulamaların da kullanımını sağlamak. Uygulamanın input param gibi girilmesini ve sadece portal şeklinde sabit olarak kodlanmış (hard coded) olmasını sağlamak.

Değişken	Notlar
Ortam	E-ticaret sitesi
İşlev	Verilen müşteriye ait toplanmış her tür bilgiyi döndürmek.
İlginç mi?	Evet kesinlikle. Eğer tüm veriyi okuyabiliyorsanız, sadece lazım olan kısmını alabilirsiniz.
Tekrar kullanılabilir mi?	Komik ama tam olarak değil. Çok az sayıda, tüm bu veriyle ilgilenen uygulama olacaktır.
Atomik mi?	Kesinlikle değil. Bu canavar işlevsellik, mantık olarak birbirine eklemlenmiş düzinelerce küçük parçadan oluşmaktadır.
Nasıl İTA olacak?	Küçük parçalara bölerek. Müşteriyi neyin özetlediğini düşünün (adres bilgisi, telefonlar, favori ürünleri, seçtiği iletişim yöntemleri vb. bilgiler) bunların her biri bağımsız birer servise dönüştürülmelidir. Atomik olanlar dışında ESB (Kurumsal Servis Veriyolu) kullanarak bileşik servisler yaratmak

Değişken	Notlar
Ortam	Herhangi bir yerdeki CRM uygulaması
İşlev	Birisi bir hesap yarattıktan sonra C_NAZ_AJ tablosundaki CUST_AR_ZN kolonunu güncellemek.
İlginç mi?	Kesinlikle hayır. Bu CRM uygulamasının iç bir fonksiyonu. Şu mantıklı dünyada hiç kimse böyle alt kademe bir fonksiyonla uğraşmak istemez.
Tekrar kullanılabilir mi?	Muhtemelen evet. Hesap değişik kanallardan yaratılabiliyorsa tekrar kullanılabilir.
Atomik mi?	Evet öyle görünüyor. Bu sadece bir tablodaki bir kolonun güncellenmesi işi.
Nasıl İTA olacak?	Bunu sakın servise çevirmeye çalışmayın. İlginç değil bir kere. Hiç kimse bir sistemde yer alan belirli bir tablolar ve kolonların güncellenmesiyle uğraşmaz. Bu CRM uygulamasının karmaşık bir detayıdır ve zaten kendi kendine hem tekrar kullanılabilir ve hem de atomik durumdadır. İş bu sebeple servis yapmaya çalışmamak lazımdır. Bunu CRM uygulamasını yazan düşünsün siz değil.

Değişken	Notlar
Ortam	Mobil telekomünikasyon şirketi
İşlev	Ödeme sistemine bağlı bir ön ödemeli kartı yeniden doldurmak.
İlginç mi?	Had safhada evet. Herkes SMS, sesli yanıt sistemi, portal, hediye kartı gibi değişik yollardan bunu kullanmak ister.
Tekrar kullanılabilir mi?	Hayli tekrar kullanılabilir. Daha üst seviye pek çok sürecin parçası olabilir.
Atomik mi?	Evet, kendisini çağıran uygulamalar açısından bakarsak kartı tekrar ya da dolduramaz. Bir dizi adımla bu işlevselleği uyarlayacak ödeme sistemi burada konu dışıdır. İş açısından bakarsanız, bu ödeme sistemi tarafından sunulan atomik ve bölünemez bir servistir.
Nasıl İTA olacak?	Bunu sakın servise çevirmeye çalışmayın. İlginç değil bir kere. Hiç kimse bir sistemde yer alan belirli bir tablolar ve kolonların güncellenmesiyle uğraşmaz. Bu CRM uygulamasının karmaşık bir detayıdır ve zaten kendi kendine hem tekrar kullanılabilir ve hem de atomik durumdadır. İş bu sebeple servis yapmaya çalışmamak lazımdır. Bunu CRM uygulamasını yazan düşünsün siz değil.

Değişken Notlar Ortam Mobil telekomünikasyon şirketi İşlev Ödeme sistemine bağlı bir ön ödemeli kartı yeniden doldurmak. İlginç mi? Had safhada evet. Herkes SMS, sesli yanıt sistemi, portal, hediye kartı gibi değişik yollardan bunu kullanmak ister. Reusable? Hayli tekrar kullanılabilir. Daha üst seviye pek çok sürecin parçası olabilir. Atomik mi? Evet, kendisini çağıran uygulamalar açısından bakarsak kartı tekrar doldurabilir ya da dolduramaz. Bir dizi adımla bu işlevselleği uyarlayacak ödeme sistemi burada konu dışıdır. İş açısından bakarsanız, bu ödeme sistemi tarafından sunulan atomik ve bölünemez bir servistir. Nasıl İTA olacak? E zaten öyle şu an. Eğer son 50 yıl civarında programlama ile uğraştıysanız, kendi uygulamanızı servis olarak bir dış uygulamaya açmanın, başka biri tarafından yazılmış koda kendi kodunuzu API olarak açmakla kesinlikle benzediğini görebilirsiniz. Aradaki tek fark, tekil bir sistemdeki alt sistemlerle uğraşmak yerine, birbirinden tamamen ayrılmış sistemlerde çalışıyor oluşunuz.

ESB üzerinde SOA ile servis yaratmak¶

Şimdi sistemlerin asla doğrudan bilgi alışverişi yapmadığını ve bir servisin ne olduğunu anladığınıza göre ESB’den faydalanmaya başlayabilirsiniz.

Resimler şu adresten alınmıştır. https://zato.io/docs/intro/esb-soa-tr.html

Tümleşik sistemlerde servisleri çağırmak ve kullanmak, artık Kurumsal Veri Yolu’nun (ESB) işine dönüşüyor. Bu şekilde, genellikle KVY kullanarak sadece bir arayüz ve bir erişim metodu yazmak yeterli oluyor.

Eğer yukarıdaki diyagramdaki gibi 8 sisteminiz varsa, yaratılacak, bakımı yapılacak ve idare edilecek, 16 adet ara birim oluşacaktır.

Eğer KVY olmasaydı, her sistemin birbiriyle konuştuğunu varsayacak olsak 56 adet ara biriminiz olması gerekirdi.

40 adet daha az ara birim demek daha az para ve zaman harcamak demek. Cuma günlerinizin neden daha kasıntılı geçtiğinin de bir sebebi aynı zamanda.

Sadece bu durum bile sizi KVY kullanmaya başlama konusunda özendirmeli.

Eğer bir gün sistem yeniden yazılsa, şirket el değiştirse, hatta kurum içi bölümler tekrardan bölünse bile değişime ayak uydurmak KVY ekibinin görevidir. Kurumdaki başka hiç bir sistemin bu değşikliklerden haberi bile olmaz çünkü KVY ile kullandıkları arabirim aynı kalacaktır.

Yukarıda anlattığımız İTA servislerini günlük olarak deneyimlediğinizde, artık bileşik servisleri de düşünmeye başlayabilirsiniz.

Az evvel yukarıdaki bahsettiğimiz ‘bana-müşteriyle-ilgili-her-şeyi-ver’ servisini hatırladınız mı?

Böyle bir servis yazmak iyi bir fikir değil ama zaman zaman istemci (client) uygulamaların bu türden toplanmış ve özetlenmiş bilgiye ihtiyacı oluyor. İşte bu belirli istemci için en iyi bileşik veriyi getirecek en kral atomik servisi seçecek olan da gene KVY ekibidir.

Bir zaman sonra tüm organizasyonun kafasına dank edecek gerçeklik şudur; Bu işin tablolar, dosyalar, fonksiyonlar, rutinler, kayıtlarla falan bir ilgisi kalmamıştır. Bu artık ilginç, tekrar kullanılabilir ve atomik servisleri merkeze alan bir mimari meselesidir.

İnsanlar artık uygulamaların ve sistemlerin birbirine nasıl bir şeyler göndereceği konusunda düşünmeyecekler. KVY sistemini, kendi sistemlerinde kullanabilecekleri ilginç servisler olarak görecekler. Ve bundan sonra hangi servisi kimin sunduğuyla ilgilenmeyecekler, kendi sistemleri sadece KVY ile ilgilenecek.

Bu, sabır, koordine bir çaba ve zaman alacak bir süreç ancak yapılabilir bir şey.

Aman dikkat edin...¶

Servis odaklı uygulama (SOA) konseptini mahvetmenin en kolay yolu KVY hizmetini açıp ondan sonra olayların kendiliğinden düzelmesini beklemek olabilir. Hala harika bir fikir olmasına rağmen, sadece KVY sistemini kurmakla çok büyük bir kazanım sahibi olamazsınız maalesef.

En iyi halde, aşağıdaki diyagramdaki gibi bazı şeyleri halı altına süpürmek, size hiç bir şey kazandırmayacaktır.

Resimler şu adresten alınmıştır. https://zato.io/docs/intro/esb-soa-tr.html

IT ekibiniz ondan tiksinecek, yönetim ise önce bu yeni gelen çocuğa tolerans gösterecek ancak daha sonra KVY iyice alay konusu olacak. “Ney ney, sihirli değnek değil mi, Hahahaha”.

Eğer KVY işleri iyi hale getirmek üzere yapılan daha büyük bir planın parçası olamazsa, bu türden sonuçlar kaçınılmaz hale gelecektir.

KVY bankalar vb. kocaman kurumlar için uygun görünüyor, öyle mi?¶

Kesinlikle yanlış, öyle değildir. İlginç bir sonuç almak için her koşulda birden fazla erişim yöntemiyle birden fazla veri kaynağını işbirliği içinde kullanabilmek son derece iyi bir tercih.

Mesela, termal sensörlerden alınan en son okuma değerlerini, bir entegrasyon platformu içinde yer alan eposta alarmı ya da Iphone uygulaması gibi birbirinden farklı kanallara yayınlamak için son derece uygun bir yol KVY.

Kritik bir uygulamanın tüm bileşenlerinin ayakta olup olmadığını düzenli olarak denetleyen ve sorun varsa hemen sms gönderen bir betiği koşturmak ta çok iyi fikir.

Temiz ve iyi tanımlanmış bir ortamda bulunan ve entegrasyon ihtiyacı bulunan her şey KVY servisi için idealdir, ancak gene de en iyi adapte olan servisleri oluşturmak ta tecrübe işidir. Bu konuda Zato ekibinden yardım alabilirsiniz.

Fakat duydum ki SOA sadece XML, SOAP ve web servisleri hakkındaymış¶

Evet, bu belirli bir kısım insanın inanmak istediği şey.

Eğer çalıştığınız kişiler veya kurumlar BASE64-kodlanmış bir CSV dosyası yaratıp, bunu bir de SAML-secured SOAP mesajı halinde size gönderiyorlarsa nasıl bir izlenim bıraktığınız anlaşılabilir bir şey.

XML, SOAP ve web servislerinin kullanım alanları var ama her şey gibi onlar da yanlış şekilde kullanılabilirler.

SOA temiz ve yönetilebilir bir mimari içindir. Bir servisin SOA kullanıp kullanmadığı konu dışı. Bir tane bile SOAP servisi kullanılmasa bile, SOA hala geçerli bir mimari yaklaşım olarak geçerli olacaktır.

Bir mimar harika bir bina tasarlasa bile, binayı kullanacak kişilerin iç mekanlarda hangi rengi seçeceği hakkında yapabileceği çok da bir şey yok.

Kısaca hayır, SOA sadece XML, SOAP ve web servisleri hakkında değildir. Bu da kullanılabilir elbette ama tüm mesele bundan ibaret değil.

SOA hakkında gerçekleri öğrenmek isteyen ve yolunu kaybetmiş meslektaşlarınız varsa onları da bu makaleye yönlendirmenizi, SOA hakkındaki gerçekleri anlamaya davet ediyoruz.

Ve fazlası da var¶

Bu bölüm sadece temelleri kapsıyor ancak size KVY ve SOA’nın neye benzediği ve nasıl başarıyla uygulayabileceğiniz hakkında sağlam bir anlayış verdiğini umuyoruz.

Burada ele almadığımız ve bununla sınırlı olmayan diğer konular;

KVY geçişi için yönetimden nasıl destek istersiniz
SOA mimarlarını ve analiz ekibini nasıl işe alırsınız (Varsa tabii)
Kurumunuza Canonical Veri Modeli (CDM) nin tanıtılması
Anahtar Performans Göstergesi (KPI) - artık sistemler arası kullanılacak servisler için ortak ve birleştirilmiş bir yönteme sahipsiniz. Şimdi bu sistemi gözlemleyerek ne elde ettiğinizi ölçümlemeniz gerekiyor.
İş Süreci Yönetimi (BPM) - servisleri planlamak için ne zaman ve nasıl bir BPM platformu seçmelisiniz (cevap - düzgün çalışan ve tapılası servisleri nasıl yaratacağınızı anlamadan ve iyice yakınlaşmadan aman geçmeyiniz)
Herhangi bir API’si olmayan sistemlerle ne yapacaksınız. Mesela KVY bunların veritabanına doğrudan erişmeli mi? (cevap - bu konuda belirlenmiş net bir kural yok)

Zato tam olarak nedir?¶

Zato middleware ve backend sistemler inşa etmek için Python dili ile yazışmış bir KVY ve uygulama sunucusudur. Hem ticari hem de topluluk desteği bulunan açık kaynak kodlu bir yazılımdır. Ve Python da kullanım kolaylığı ve üretkenliği ile meşhur bir dil. Python ve Zato’yu birlikte kullanıyor olmanız demek, baş belası olan pek çok konuya daha az zaman harcamak ve daha verimli olmak anlamına gelir.

Zato pragmatistler tarafından pragmatistler için yazılmıştır. Herhangi bir tedarikçinin SOA/KVY pazarından pay kapmak amacıyla alelacele bitiştiriverdiği dingabak bir sistem değildir.

Aslında, tam olarak bu tür sistemlerde ortaya çıkan yangını söndürmek üzere pratik olarak yapılan çalışmaların bir sonucudur.

Zato bu tür sistemler üzerinde çok uzun süre çalışma sonucu ortaya çıktığından görünürde benzer olan sistemlere göre çok daha fazla verimlilik ve kullanım kolaylığı sunar.

Daha fazla bilgi için!

See you there!

Zato İpuçları¶

Zato Bileşenlerini Yeniden Başlatma¶

Zato ile ilgili bileşenler /etc/zato/components-enabled/ dizini altında bulunmaktadır. Zato yeniden başlatıldığında, bu bileşenler yeniden başlatılmış olurlar. Her bir bileşen istenirse diğerlerinden ayrı olarak da yeniden başlatılabilir.

örnek kullanım¶

$ sudo service zato stop
$ sudo service zato start
veya
$ sudo service zato restart

os_environ¶

Servislerin kullandığı çevre değişkenleri (environment variable) Zato tarafından erişilebilir olmalıdır. Bunun için sunucu yapılandırma dosyasında (/opt/zato/ulakbus/server1/config/repo/server.conf) os_environ bölümüne çevre değişkenleri eklenmelidir.

örnek kullanım¶

[os_environ]
HITAP_USER='hitap_user_name'
HITAP_PASS='hitap_password'

zato_extra_paths¶

Zato servisleri tarafından kullanılan modül ve kütüphaneler, Zato tarafından erişilebilir olmaları için ~/zato_version/zato_extra_paths/ dizini altında bulunmalıdır. İlgili modül ve kütüphaneler için bu dizin altında sembolik link verilebilir.

örnek¶

Geliştirilen servisleri Zato aracılığıyla kullanmak için, servis modüllerini /opt/zato/ulakbus/server1/pickup-dir/ dizini altına kopyalamak gerekmektedir. Bu işlemi yapmadan önce çevre değişkenlerini (HITAP_USER, HITAP_PASS vb.) tanımladığınızdan emin olunuz.

örnek kullanım¶

$ sudo cp /app/ulakbus/ulakbus/services/personel/hitap/*.py /opt/zato/ulakbus/server1/pickup-dir/

Bu işlemden sonra servisler için tanımlanmış kanalları (channels) ve giden bağlantıları (outgoing) içeren bir yapılandırma dosyası varsa bu dosya içeriye aktarılmalıdır.

enmasse¶

Zato servisleri için tanımlanmış kanalların (channels) ve giden bağlantıların (outgoing) bir yapılandırma dosyasına çıkartılarak saklanmasını veya içeriye aktarılmasını sağlar.

export¶

$ zato enmasse ../server1/ --input input1.json --export-local --export-odb

Argümanlar:¶

path Zato server dizinini belirtir.
–input Dışarıya aktarılacak dosya, bu JSON girdi dosyası kullanılarak oluşturulur. Bu yüzden dosya mevcut değilse, içerisine boş bir sözlük {} konularak oluşturulabilir.
–export-local –export-db JSON ve ODB nesnelerini birleştirerek tek bir dosya halinde dışarıya aktarır.

import¶

$ zato enmasse ../server1/ --input zato-export-2015-06-30T08_56_22_628706.json --import --replace-odb-objects

Argümanlar:¶

path Zato server dizinini belirtir.
–input İçeriye aktarılacak JSON dosyası. Bu dosya yukarıdaki örnekte olduğu gibi Zato komut arayüzü üzerinden dışarıya aktarılmış olmalıdır.
–import –replace-odb-objects Nesneleri, dışarıya aktarılmış JSON dosyasından mevcut olanların üzerine yazılacak şekilde içeri aktarır.

Yazılım Tasarım Analizi Belgesi¶

Sistem Mimarisi¶

Sistem Mimarisi Genel Görünüm¶

ULAKBÜS Katmanları Genel Görünüm¶

İş Akışı (Workflow) Tabanlı Uygulama¶

İş Akışı (Workflow) Tabanlı Uygulamalar, iş süreçlerini yeterince küçük adımlara bölerek, iş akışlarının aktörlerini ve her bir adımda işlenecek veriyi net bir şekilde tanımlayarak kolay yönetilebilirlik ve esneklik sağlarlar. İş süreçlerinin tamamıyla olmasa bile belli oranda otomatikleştirilmesi ve yazılım tarafından işlenebilir olması değişen ihtiyaçları karşılamak için kolaylık sağlamaktadır. Sadece iş akışı şemalarında yapılacak değişikliklerle uygulamaya yön vermek mümkündür.

Örnek İş Akış Şeması

İş süreçleri yönetimi için, BPMN2 kural setine uyan Workflow Management yapısı seçilmiştir. Python dünyasında WorkFlow Management ve BPMN desteği bulunan SpiffWorkFlow kütüphanesi geliştirilmeye açık en uygun aday olduğu için seçilmiştir.

İş süreçlerinin görsel olarak oluşturulması için de Camunda Modeler seçilmiştir.

Kurumsal Veri Yolu Kullanımı¶

Kurumsal Veri Yolu (ESB) uygulamanın parçaları ve dış servisler arası iletişimi düzenler. Veri kaynaklarını mikro ölçekte, yeniden kullanılabilir servisler haline getirerek bir iletişim düzeni kurar. Özellikle dış servislerle veri alışverişini kendi üzerine alarak uygulama içerisinde daha sade ve yönetilebilir kod yazmaya olanak verir.

Neden KVY gerektiği ile ilgili, tarafımızdan çevrilmiş bulunan, açıklayıcı ve detaylı yazıyı buradan. okuyabilirsiniz.

Sunucu ve Servis Yerleşimi¶

VM Konfigürasyonları:¶

Small:

Standart:

Large:

2 GB RAM,

4 GB RAM,

8 GB RAM,

2 VCPU

4 VCPU

6 VCPU

2 GB Ephemeral SSD

10 GB SSD

ve

Açıklama	VM Türü	Adet	DİSK	OS
Riak Nodes	Large	5	400 GB SSD	Coreos
RiakCS	Standart	3	400 GB SSD	Coreos
Redis	Large	3	20 GB SSD	Coreos
Zato	Standart	3		Coreos
HaProxy	Standart	2	1 GB NonSSD	Coreos
HaProxy	Large	2	10 GB SSD	Coreos
Logging	Standart	2	400 GB NonSSD	Coreos
Apps	Small	3		Coreos
Buildbot	Small	4	10 GB SSD	Coreos
Fab	Standart	1	40 GB SSD	Ubuntu
Sandbox	Standart	1	80 GB NonSSD	Ubuntu

Image özellikleri:¶

Coreos.

Ubuntu.

Tercih Edilen Yazılımlar¶

Riak:¶

Riak, dağıtık bir veritabanı sistemidir. Verileri sunucular arasında dağıtarak yüksek erişilebilirliği sağlar. Riak’ın tercih edilmesindeki sebepler aşağıda sıralanmıştır:

Çok kullanıcılı / çok rollü sistemde verilerin sürekli erişilebilir olması,
Aynı veriye eş zamanlı erişerek okuma / yazma işlemlerinin, veriye erişimi bloke etmeyerek gerçekleştirilmesi,
İş modeline uygun senaryolara göre ortaya çıkacak uyuşmazlıkların çözümlenebilmesine olanak vermesi,
Zamanla büyüyen verinin sürekli yedekli olarak yönetilmesi,
Veri tasarım şeklinin, RDBMS kalıpları dışında yapılabilmesi,
Verinin “strong consistent” olarak tutulabilmesi sayesinde “ACID” benzeri bir tutarlılığa sahip olmak,
Sistem tüm Türkiye çapında kullanılsa bile, değişik veri merkezlerinde “multi homed” olarak çalışabilir olması.

RiakCS:¶

RiakCS, Riak veritabanı sisteminin üzerine kurulu nesne depolama (object storage) sistemidir. Sistemde kullanıcı tarafından üretilecek dokumanlar (resimler, doc, pdf vb) RiakCS ile saklanacaktır. RiakCS de dağıtık bir sistemdir. RiakCS ile yüksek erişilebilir, ölçeklenebilirlik dağıtık bir bulut depolama sistemi elde edilmiş olacaktır. RiakCS API (Uygulama Programlama Arayüzü) yaygın kullanılan Amazon S3 ile uyumludur.

Postgresql:¶

Postgresql, Zato Clusterı tarafından kullanılmaktadır. Cluster bilgileri gibi Zato’nun iç operasyonlarını ilgilendiren veriler saklanacaktır.

Redis:¶

Redis, bellekiçi key/value veritabanı sistemidir. Uygulama ile Riak arasında geçici depolama ve hızlı okuma işlemleri için kullanılacaktır. Bu sayede veritabanı üzerindeki yük hafifleyecek, veriye erişim çok yüksek hızlara çıkıp uygulama performası artacaktır.

Redis, ayrıca Zato tarafından benzer amaçlar için de kullanılacaktır.

Zato:¶

Zato, Python ile geliştirilmiş Kurumsal Hizmet Veriyolu (Enterprise Service Bus) yazılımıdır. Zato ile iş akışlarına uygun olarak, uygulamalar arası veri trafiği, mikro servisler haline getirilerek düzenlenecektir. Zato sadece sistem içi operasyonlar için değil aynı zamanda dış kaynaklarla olan iletişimi de üzerine alıp onları sistemin içerden erişebileceği mikro servislere dönüştürecektir. Bu da dış dünya ile uygulamanın tıpkı içerdeki gibi benzer desenler ile konuşabilmesini sağlayarak tutarlılık sağlayacaktır.

HaProxy:¶

High Available (Yüksek Erişilebilirlik) Proxy, hem kullanıcı arayüzeyleri aracılığı ile gelecek istekler (requests), hem dışarıya açılan servislere yapılacak çağrılar, hem de sistem içi bileşenlerin birbirleri ile olan iletişimleri sonucu doğacak trafiği dengelemek ve yüksek erişilebilirliği sağlamak için kullanılacaktır.

Bulut araçları¶

Docker:¶

Docker, uygulama ve servislerin konteynerlar şeklinde sanallaştırılarak Linux sistemleri üzerinde çalıştırılmasını sağlar. Docker uygulama ve servislerin yönetimini ve ölçeklenmesini kolaylaştrır. Bütün bileşenler kontenyerlar içinde servisler şeklinde çalışacaktır. Uygulama ve diğer tüm bileşenler bu sayede ihtiyaçlar ölçüsünde kolayca ölçeklenebilecektir.

Consul:¶

Consul,, Servislerin ve üzerlerinde çalıştıkları sistemlerin erişilebilirliği, yeni açılan veya herhangi bir sebeple çalışması kesintiye uğrayan, kapanan servislerden haberdar olmak için bütün host sistemlerde çalışacak servistir.

Systemd:¶

Systemd linux sistemler için neredeyse standart hale gelmiş modern servis yonetim aracıdır. Konteynerlar haline gelen uygulama parçacıkları systemd servisleri şeklinde yönetilecektir.

Etcd:¶

Etcd bir sytemd servisi olarak çalışacak ve cluster çapında data alışverişi yapmak için kullanılacaktır. Ortam değişlenleri, değişen ayarlar, Consul ve benzeri servislerin haberleşmesi için kullanılacaktır.

Confd:¶

Confd başta haproxy gelmek üzere sistem servislerinin yeni durumlarına göre yeni ayar dosyaları üretme ve ilgili servisleri yeniden başlatma işini üstlenmektedir.

Flannel:¶

Flannel cluster içinde çalışan servisler (docker konteynerları) için özel bir ağ katmanı oluşturur. Bu sayede servisler bu özel ağ üzerinden birbirleri ile konuşabilirler.

Fleet:¶

Fleet, konteyner haline getirilen servislerin cluster çapında systemd ye bildirilmesi ve yönetilmesinden sorumludur. Fleet yazılan bir servis için hazırlanan tanımlama dosyası (unit files) gereklerine uygun olarak, uygun gördüğü makinelerde çalıştırmaktan, bir başka makineye taşımaktan veya durdurmaktan sorumludur.

Github:¶

Github, temel proje yönetim ve geliştirme alanımızdır. Birçok geliştiricinin alışık olduğu bu ortam, katkıcıların kolayca dahil olmalarına olanak vermektedir. Açık kaynaklı yazılım projeleri geliştirme teamüllerine uygun bir ortamdır. Git sürüm yönetim sistemini kullanmaktadır. Geliştirici ve kullanıcı topluluğun teknik tartışmaları, geri bildirimleri Github’ın sağladığı ilgii araçlarla yapılacaktır.

Continuous Integration & Continuous Delivery:¶

Uygulama kaynak kodu ve/veya sistem/ortam ayarları değişiklikleri üzerine, uygulamanın test edilmesi, belirlenen ortamlarda kurulum ve yayınlanma işlerinin otomatik şekilde yapılması, elde edilen sonuçların geliştiricilerle paylaşılması ve raporlanması, geliştirme süreçlerini kolaylaştırmakta, hızlandırmakta, problemlerin kaynaklarını tespit etmeye yardımcı olmaktadır.

Projede, bu amaçla Buildbot kullanılacaktır. Buildbot ile üretilen her türlü sonuç, log, rapor projede ilgili taraflara çeşitli kanallardan iletilecektir.

Logging¶

Kayıt Türleri¶

DEBUG: Geliştici ve sistem yöneticileri için, servis veya uygulamaların çalışmaları hakkında açıklayıcı bilgiler sunar. Bu bilgiler geliştirme evresinde ve sorun çözme aşamalarında kullanılır.

INFO: Servis veya uygulamaların önemli adımlarının sonuçlarına, durum değişikliklerine ilişkin detaylı bilgiler içerir. Kullanıcı giriş yaptı, yeni ders eklendi, servis yeniden başladı vb..

WARN: Servis veya uygulamaların beklenen dışında davranışlar göstermesi hakkında bilgiler içeren kayıtlardır. Hata olmamakla birlikte bir servise erişememek, diske yazamamak gibi geçici problemlerin sebep olduğu aksaklıkların bildirilmesini kapsar. Uygulama veya servis kesintiye uğramaz fakat nasıl yönlendirildiğine bağlı olarak bir süre sonra yeniden deneyebilir, raporlayabilir, başka bir yöne doğru ilerleyebilir.

ERROR: Uygulamanın bir adımında beklenen işlevi yerine getirememesi sonucu ortaya çıkan kayıtlardır. Servis veya uygulama kesintiye uğramaz fakat ilgili adım muhtemelen elle müdahale gerektirecek bir problemle karşı karşıyadır.

FATAL: Uygulama yada servisin, veri kaybına da neden olabilecek bir hizmet kesintisine uğraması durumunda tutulan kayıtlardır.

Log Yönetimi¶

Hem uygulama hem de uygulamanın çalışacağı ortam bileşenlerinin her birinden toplanacak loglar, merkezi bir loglama sisteminde toplanacaktır. Sistemin anlık olarak izlenmesi, olağandışı gelişmelere uygun aksiyonlar alınması, uzun vadede geliştirme süreçlerine geribildirim olarak dönmesi amacıyla toplanan kayıtlar analiz edilecektir.

Bu amaçla Logstash, Kibana, Elasticsearch üçlüsü kullanılacaktır. Logstash ve Elasticsearch logların toplanması, filtrelenmesi, analiz edilmesi, Kibana ise görselleştirilmesi için kullanılacaktır.

Sistem ve Servis Logları¶

Uygulamanın üzerinde çalışacağı donanım, işletim sistemi, cluster ve bunlar üzerinde çalışacak servisler hakkında şu loglar tutulacaktır:

Coreos ve sanallaştırma araçlarından elde edilen loglar,
Sisteme yapılan girişler,
Açılan kapanan konteynerların durumları hakkındaki loglar,
Konteyner haline gelmiş servislerden
- Load Balancer erişim, hata, health check logları
- Riak ve RiakCS cluster yönetimi, riak admin logları
- Riak ve RiakCS kimlik dogrulama ve yetkilendirme logları
- Zato servis hata logları
- Zato iç ve dış servisler için doğrulama ve yetkilendirme logları

Sistem ve Servis Log Analizi¶

Çalışması duran servislerin tespit edilmesi ve aksiyon alınması,
Servislerden gelen hata loglarının, bellek durumu, cpu yükleri, disk doluluğu, network problemleri gibi donanım ve ağ logları ile birleştirilerek, aralarında bir kolerasyon olup olmadığının anlaşılması,
Servislerin durmasından hemen önceki işlemlerin tür ve yoğunluğunun önceki servis durmaları ile ortaklık gösterip göstermediğine bakılarak, örneğin disk i/o, vtye belirli sayıların üzerinde yazma vb gibi işlemlerin servislere olan olumsuz etkilerin ve buna yol açan sebeplerin anlaşılması,
Clustered servislerden gelen loglara bakarak yük dağıtımının dengeli bir şekilde yapılıp yapılmadığının anlaşılması,
Consul ile birlikte monitoringe yardımcı olması

Kullanıcı Arayüzü Logları¶

Kullanıcı arayüzünde oluşacak çalışma zamanı hataları tarayıcı konsoluna düşmektedir. Bu loglar yakalanarak sunucu tarafındaki log tutucuya gönderilerek kaydedilecektir.

Arayüz fonksiyonları logları belirtilen log seviyelerinde tutulacaktır.. Prod başlığında belirtilen maddeler ışığında arayüz logları için stacktrace.js kullanılacaktır.

incele: http://logstash.net/docs/1.1.1/outputs/riak#setting_bucket http://underthehood.meltwater.com/blog/2015/04/14/riak-elasticsearch-and-numad-walk-into-a-red-hat/

Notlar: CEP için loglarla nasıl bir relation kuracağız? Loglardan event trigger etmek nasıl?

Refleksler:¶

Duran servisleri yeniden başlatmak
Ölenlerin yerine yenisini başlatmak
Ağır yük altında olan servisleri genişletmek
Hafif yük altında olan servisleri daraltmak
Ölçeklenecek serviler için sistem kaynaklarının yetersizliğini tespit edip yeni kaynaklar eklemek veya kaynak ihtiyacını bildirmek. Mümkünse clustera yeni nodelar otomatik eklemek.
Kronik hale gelen problemlerin tespiti ve bilgilendirilmesi. Muhtemel konfigurasyon problemleri demek.
Application loglarindan gelen uyarilar

Fleet API kullanarak clusterda tanımlı servisleri başlatmak / durdurmak mümkün. Node ekleyip çıkarmak için Openstack / GCE API ile konuşmamız gerekir. Notification eposta veya sms ile mümkün. Yukarıdakilere ek başka ne gibi aksiyonlar olabilir?

Tercih Edilen Yazılım Bileşenleri¶

Arka Uçta Kullanılan Bileşenler¶

Genel Sistem Akış Şeması:¶

Modül / Bileşenlerin Genel Görünümü:¶

zaerp
- zdispatch
  
  requestleri karsilayip ilgili is akislarina yonlendiren tornado web çatısı dosyalari yer alacaktir.
- bin
  
  çalıştırılabilir uygulamalar. örn: bpmn packager.
- lib
  
  yardımcı kütüphane ve fonksiyon setleri.
- modules
  
  bazıları kendi alt dizinlerine sahip olan uygulama modulleri.
  
  auth
  
  örnek authentication modülü
- models
  user.py
  
  auth.py
  
  employee.py
  
  unit.py
- services
  
  bu dizinde Zato mikro servis dosyaları yer alacaktır.
- workflows
  
  bu dizinde iş akışı paketleri bpmn dosyaları yer alacaktır
tests

methodlar, uygulama birimleri ve uygulama geneli icin yazilan unit testleri yer alacaktır
docs
- geliştiriciler
  diagrams
  
  api
- son kullanıcılar
- sistem yöneticileri

kod, api, kullanici, gelistirici, sistem yoneticisi dokumanlari yer alacaktir.

Uygulamanın veri ve iş mantığının şu ana kadar planlanan yapısını gösteren class diagramlar aşağıda görülebilir.

_images/genericrequesttoresponseseqdiagram.png

SpiffWorkflow Engine¶

BPMN 2.0 notasyonunun önemli bir kısmını destekleyen, Python ile yazılmış bir iş akış motoru (workflow engine) uygulaması olan SpiffWorkflow incelenmiştir. Mevcut haliyle, tüm ihtiyaçlara cevap veremeyeceği tespit edildiğinden, ZetaOps tarafından genişletilerek yazılmaya devam edilmektedir. Genişletilmiş hali ile bu kütüphane tüm uygulamanın hareket zeminini oluşturmaktadır. Zetaops sürümü olan kütüphane ile, uygulama iş mantığının anahatları BPMN 2.0 notasyonuna uyumlu XML diagramlarından okunarak işletilecektir. Öğrencilerin sisteme giriş yapmasından arka planda çalışacak zamanlanmış görevlerin işletilmesine kadar tüm iş akışları, bu iş akış motoru tarafından yönetilecektir.

Pyoko¶

Riak veri şemalarının Python nesneleri olarak modellenmesi, bu modeller arasında bağlantılar tanımlanabilmesi, verilerin kayıt sırasında şema tanımlarına göre doğrulanması, kayıtlı verilerin pratik bir API ile sorgulanabilmesi ve geliştirme süresince bu şemalarda yapılacak değişikliklerin sürümlendirilerek saklanabilmesi amacıyla arka uçta Riak ve Redis’i kullanan Pyoko kütüphanesi ZetaOps tarafından geliştirilmektedir.

ZEngine¶

ZetaOps tarafından geliştirilmekte olan ZEngine, SpiffWorkflow’u taban alan basit bir web çatısıdır. Bu yapıda önyüze yönelik her iş akışının bir URLsi olmakta ve o anda işletilmekte olan iş akışı adımında referans verilen uygulama nesnesi (view class) request ve response nesneleri ile çağırılmaktadır.

Kural Motoru (Rule Engine)¶

Uygulamanın, kanun ve yönetmelik değişikliklerine bağlı olarak zamanla değişebilecek tanım ve kurallara dayalı iş mantığı, merkezi bir depodan kolayca güncellenebilecek ve sistem yöneticileri tarafından düzenlenebilecek kural setleri ile tanımlanacaktır.

Zato Servisleri¶

SOAP, REST, JSON, XML, CSV, PB gibi farklı protokol ve veri tipleriyle konuşan servislerin dönüşümü Zato ESB üzerinde yapılacaktır. Harici istemciler ve farklı modüller tarafından ihtiyaç duyulan işlevsellikler Zato ESB üzerinde çalışan mikro servisler olarak sunulacaktır. Uygulamanın hizmet sağlayıcı olduğu her durumda REST stili kullanılacaktır.

Tornado Web Sunucusu¶

Tornado, non-blocking network I/O, long polling, WebSockets yeteneklerini içeren bir web sunucusudur. Bu sayede sunucudan kullanıcıya tek yönlü veri iletimi yapan http protokolü yerine, kullanıcı ile sunucu arasında iki yönlü veri iletimi (Push, Pull) mümkün olmaktadır.

RabbitMQ¶

RabbitMQ AMQP (Advanced Message Queue Protocol) protokolünü destekleyen bir mesaj yönetimi uygulamasıdır.

Raporlama ve Analiz¶

Önceden oluşturulan standart raporlara ek olarak, indekslenmiş veri üzerinde gelişmiş sorgulamalar yaparak her türlü günlük ihtiyaca yanıt verebilecek esnek bir raporlama altyapısı geliştirilecektir. Verilerin çok çeşitli şekillerde incelenmesine ve derlenmesine olanak veren Python tabanlı analiz betiklerine ek olarak, indekslenmemiş büyük miktarda veri üzerinde MapReduce işlemleri yapabilmek için Erlang betikleri de kullanılabilecektir.

Kullanıcı Arayüz Bileşenleri¶

Angular.js

AngularJS, MVC (Model View Controller) deseni sağlayan bir javascript uygulama çatısıdır. Kullanıcı arayüzü işlemlerini gerçekleştirecek tüm fonksiyonlar için kullanılır. AngularJS standart sunucu taraflı yazılım geliştirme tekniklerini önyüze uygulayan ve önyüz geliştirmeyi hızlandıran bir uygulama çatısıdır. Karmaşık uygulamalarda DOM yönetimini başarıyla gerçekleştirir ve bu sayede uygulamanın kesintisiz ve sorunsuz çalışmasını sağlar.
Karma

Karma, Uygulama fonksiyonları için yazılmış testleri uygulayan test sürücüsüdür. Uygulamamızda Jasmine test çatısı testlerinin çalıştırılmasında kullanılır. Geliştiricinin her bir test ortamı için ayrı ayrı yapılandırma dosyası oluşturmadan tek bir yapılandırma ile testleri çalıştırabilmesini sağlar.
Selenium

Selenium, E2E testlerin çalıştırıldığı test platformudur. Kullanıcının tarayıcıda gerçekleştireceği işlemlerin sunucudan dönecek sonuca kadar test edilmesini sağlar.
Protractor

Protractor Selenium E2E testleri için bir çözüm enteratörü uygulama çatısıdır. Angularjs için Selenium özelleştirmeleriyle daha etkin ve bekleme sürelerini optimize ederek daha kısa sürede test edilmesini sağlar.
Jasmine

Jasmine, javascript testleri için kullanılan bir uygulama çatısıdır. Uygulama fonksiyonlarının testlerinde başarılı sentaksı ile geliştirme sürecini hızlandırır.
Bower

Bower, uygulamada kullanılacak paketlerin yönetimi için kullandığımız paket yönetim aracıdır. Uygulamanın gerektirdiği paketlerin kurulum esnasında eksiksiz şekilde ve sürüm uyumlu olarak kurulumunu sağlar.
Grunt

Grunt javascript uygulamaları için bir görev yürütücüsüdür. Küçültme, derleme, paketleme, testler gibi tekrarlanan görevleri otomasyon ile yürütmek için kullanılır.
Nodejs

Nodejs javascript uygulamaları için sunucu taraflı çalışma zamanı ortamıdır (runtime environment). Uygulama geliştirilirken bower, jasmine, karma gibi araçların kullanılması için gereklidir.
StackTrace.js
npm

npm nodejs için paket yönetim aracıdır. Uygulamanın geliştirme ortamı için gerekliliklerinin yönetilmesini sağlar.
Bootstrap3

Bootstrap3 grid sistem standardına uygun uyumlu (responsive) arayüz geliştirmek için kullanılan html, css vs javascript uygulama çatısıdır. Uygulamanın değişik ekran boyutlarında ve farklı cihazlarda sorunsuz çalışması için kullanılır.

Kullanıcı arayüz tasarımında uyulacak kurallar ve ilkeler:¶

Tüm tasarım bileşenleri html5 standardına uyacaktır.
Tasarım, kullanıcı arayüzü temiz ve tutarlı modeller temel alınarak anlamlı, kullanışlı ve amaca hizmet edecek şekilde organize etmelidir.
Basit ve sık yapılan işlemleri kolayca gerçekleştirebilmeli, kullanıcıyla açık ve kolay iletişim kurabilmeli, uzun işlemler için kullanışlı kısayollar sağlamalıdır.
Kullanıcı arayüzü tasarımı, yapılacak işlemler için tüm ihtiyaç duyulan opsiyonları ve materyalleri kullanıcının dikkatini dağıtmadan ve tam şekilde verebilmelidir.
Tasarım kullanıcıyı değişiklikler halinde bilgilendirmeli, kullanım esnasında oluşacak hataları kullanıcının anlayacağı şekilde sunabilmelidir.
Tasarım bileşenleri tekrar kullanılabilir olmalıdır.
Tasarım tüm ekran çözünürlüklerinde düzgün çalışabilmelidir.
Tasarım, engelli kullanıcılar için “mümkün” olduğu kadar kolay bir kullanım sunabilmelidir. 1 2 3 4

Kullanıcı veri girişi ilkeleri:¶

Kullanıcı verileri güvenli şekilde ve amaca yönelik geçerlilik kuralları çerçevesinde girilebilmelidir.
Kullanıcı daha az vuruş kullanarak kısa sürede veri girebilmelidir. Bunun için otomatik tamamlayıcılar, açılır menüler gibi kolaylaştırıcı bileşenler kullanılmalıdır.

Arayüz tasarımı ilkeleri:¶

Arayüz farklı amaçlar için kullanılacak farklı bölümlerden oluşmalıdır.
Kullanıcı her zaman sistemde nerede olduğunu ve hangi bilgilerin ona gösterildiğini bilmelidir.
Arayüz kolay kullanımlı ve estetik olmalıdır.

Arayüzün kullanımı kolay öğrenilebilmelidir.
Arayüz kullanıcının minimum eforuyla çalışabilmelidir.

Hata mesajları, uyarılar ve gösterilecek diğer bilgi ilkeleri:¶

Kullanıcı hatalar hakkında anlaşılır şekilde bilgilendirilmelidir.
Uyarılar kullanıcının etkileşimini kesintiye uğratmayacak şekilde gösterilmelidir.
Tekrar eden durumlarda kullanıcı deneyimini kesintiye uğratmamalı ve tekrarlı hatalar farkedilerek ona göre gösterilmelidir.
Kullanıcının yapacağı işlemle alakasız bilgiler arayüzde yer almamalıdır.

Modül Yapısı ve Klasör Hiyerarşisi:¶

app/

Uygulamanın yer aldığı dizindir.
bower_components/

Bower paket yönetimi ile uygulama kullanılan harici paketlerin tutulduğu dizindir.
components/

Uygulama ortak bileşenlerinin bulunduğu dizindir.
dashboard/
Yönetim paneli teması, controller, view ve testlerinin bulunduğu dizindir. her bir modül için benzer bir dizin buunacaktır.
- dashboard.html
- dashboard.js
- dashboard_test.js
app.css

Uygulama genel css dosyası
app.js

Uygulama ana javascript dosyası
index.html
e2e-tests/
- protractor.conf.js
  
  E2E testlerinin yapılandırıldığı dosyadır. E2E testleri için protractor kullanılmaktadır.
- scenarios.js
  
  E2E test senaryolarının yazılı olduğu dosyadır.
node_modules/

Uygulamada kullanılan nodejs modüllerinin yer aldığı dizindir.
bower.json

Uygulama bağımlılıklarının yapılandırıldığı dosyadır.
karma.conf.js

Karma testleri için yapılandırma dosyasıdır.
package.json

Uygulama nodejs bağımlılıklarının yapılandırıldığı dosyadır.

Ekran Listesi:¶

Uygulamada belirlenen yetkilendirme şemasına göre, yetkili olan kişinin bir ya da daha çok kontrol paneli (dashboard) olabilir. Her bir ekran görünümü belirli parçalardan oluşacaktır. Giriş talebi yapıldığında yetki türüne göre kullanıcının ekranı bileşenleri bir araya getirilerek uygun hale getirilir (render) ve gösterilir. Sistemin kullanacağı ortak bileşenler birer Angular modülü olacaktır.

Navigasyon Diagramı:¶

Üniversite web uygulaması ve katmanlarını içerir.

Çevrimiçi Yardım ve Rehberler:¶

Kullanıcıların arayüzü kolayca öğrenebilmelerini sağlamak ve kullanım esnasında karşılaşacakları sorunlar sırasında yardım etmek amacıyla çevrimiçi yardım ve rehber araçları kullanılır.

Sisteme ilk kez giriş yapan kullanıcıyı yönlendirmek ve arayüzün işlevleri hakkında bilgilendirmek amacıyla rehber araçları kullanılır.

Kullanıcı sistemin bir noktasında sorunla karşılaştığında bağlamsal olarak derhal konuyla ilgili yardıma erişmesi için çevrimiçi yardım araçları kullanılır.

http://usablica.github.io/intro.js/

Şekil: Kullanıcı Formları Request/Response Cycle Talep/Cevap Yaşam Döngüsü

Şekil: Kullanıcı Arayüz Bileşenleri Request/Response Cycle Talep/Cevap Yaşam Döngüsü

Veri Tasarımı¶

Geçici Veri¶

Uygulamanın sık kullandığı veriler Redis üzerinde önbelleklenecektir. Bu önbellek verileri işlemci ve veritabanı yükü açısından pahalı işlemlerle hesaplanmış değerleri ve veritabanından sık sık okunan verileri içerir. Pyoko kütüphanesi üzerinden yapılan doğrudan veri çağrıları (get request) otomatik olarak önbellekleneren veri tabanı üzerindeki sorgu yükü hafifletilecektir.

Önbellekleme haricinde, kullanıcı oturumları da Redis üzerinde tutulacaktır. Kullanıcının o an geçerli yetkileri, oturum boyunca yaptığı işlemlerle ilgili durum bilgileri de yine kullanıcı oturumu içerisinde tutulacaktır.

Kalıcı Veri¶

Verilerin kalıcı olarak saklanacağı Riak, basit anahtar-değer çiftlerinden map, set, counter gibi gelişmiş veri tiplerine, nihayetinde tutarlılıktan (eventually consistent) kesin tutarlılığa (strong consistency) kadar çeşitli veri saklama kiplerini destekleyen gelişmiş bir NoSQL veri tabanıdır. JSON biçiminde saklanacak olan veriler, Riak’ın dahili Apache Solr entegrasyonunu sayesinde istenilen incelikte indekslenmekte ver sorgulanabilmektedir.

Kalıcı olarak depolanacak tüm veri sürümlendirilerek saklanacaktır. Bu sayede her hangi bir kaydın son 100 sürümü ya da son 10 yıl içindeki tüm sürümlerine istenildiği an ulaşılabilecektir. Sürüm sayısına ya da süreye göre ne kadar geriye dönük saklama yapılacağı her bucket için kendi model tanımı altında yapılacaktır.

Veritabanı seviyesinde herhangi bir şablon kısıtı olmamasına rağmen, veriyi tutarlı biçimde saklayabilmek ve hızlı bir şekilde sorgulayarak erişebilmek için tüm veriler iç içe Python sınıfları şeklinde modellenecek, bu modeller kayıt esnasında JSON şeklinde biçimlendirilerek saklanacak ve yine modelde tanımlandığı şekilde indekslenecektir.

Test ve Prod ortamları için farklı bucketlar kullanılacak, değişen konfigurasyon ve yük testleri için geçici Riak clusterları açılacaktır.

Veri ve Veri Şablonu Göçü:¶

Uygulamanın yaşamı boyunca veri şablonlarında yapılacak güncellemeler ve bu güncellemeler nedeniyle verinin kendisinde yapılması gerekecek veri göçleri Pyoko kütüphanesi ile sürümlendirilecek ve yönetilecektir. Uygulamayı bir üst sürüme güncellemek ya da önceki sürüme dönmek için gerekli veri tabanı işlemlerini içeren göç betikleri geliştirme aşamasında Pyoko yardımıyla türetilecek ve kod deposuna eklenecektir. Gerektiğinde, elle özel göç betikleride yazılacaktır.

Varlıklar (Entities)¶

Uygulama içinden çağrılan tüm veri adları İngilizce olacaktır. Her bir entity için ayrıca bu belgeye ek belgeler oluşturulacaktır.

Personel
Student
Program
Lecture
Unit

Dış Veri Kaynakları¶

Sistem birçok veri kaynağı ile konuşabilecek, ihtiyaç duyulan veri alışverişini sağlayacaktır. Bu dış kaynakların biçemleri XML, JSON şeklinde değişik olabilir. Konuşulacak servislerin detayları aşağıdaki gibidir.

LDAP:¶

Birçok üniversitede doğrulama ve yetkilendirme gibi amaçlar için aktif şekilde kullanılan LDAP sistem tarafından desteklenecektir. LDAP’ta yapılan değişiklikler sisteme düzenli şekilde yansıtılacak, sistem gerektiğinde LDAP şemalarında değişiklik yapabilecektir. Özellikle göç aşamaları gibi LDAP kullanımının kaçınılmaz olduğu zaman ve şartlar için öngörüşmüştür.

KBS:¶

Kamu Harcama ve Muhasebe Bilişim Sistemi (KBS) Maliye Bakanlığı tarafından sağlanan, kamu kurumlarında tahakkuk ve ödeme işlemlerinin otomasyonunu sağlayan bir edevlet uygulamasıdır. Üniversitelerde de birçok mali işlem KBS aracılığıyla gerçekleştirilmektedir. KBS sisteminin el verdiği ölçüde entegrasyon sağlanacaktır.

HİTAP:¶

HİTAP(Hizmet Takip Projesi), devlet memurlarının hizmetlerinin takibi amacıyla Sosyal Güvenlik Kurumu tarafından geliştirilmiş edevlet uygulamasıdır. Personel bilgilerinin iki yönlü güncellenmesi için HİTAP servisi ile düzenli şekilde veri alışverişi yapılacaktır. HİTAP bir SOAP servisidir.

ASAL:¶

ASAL Servisi, Milli Savunma Bakanlığı tarafından sağlanan yurttaşların askerlik durumlarını sorgulayabildikleri bir edevlet uygulamasıdır. Bu uygulama ile web servisi şeklinde konuşup, erkek öğrenci ve personin askerlik durumları karşılıklı olarak takip edilecektir.

ÖSYM:¶

Öğrenci kayıtlarının otomatizasyonuna yardımcı olmak için, yerleştirme bilgileri ÖSYM’nin sunduğu

YÖKSİS:¶

YÖKSİS (Yükseköğretim Bilgi Sistemi) YÖK tarafından kurulan yükseköğretim kurumlarının çeşitli bilgilerinin merkezi şekilde saklandığı sistemdir. YÖK üniversitelerden YÖKSİS’e düzenli veri girişi beklemektedir. Ayrıca YÖK üniversitelerde açılan bölüm ve programların bilgilerinde çeşitli güncellemeler yapmakta, bu güncellemelerin verinin bütünlüğü ve tutarlılığı için en kısa sürede üniversitelerin sistemlerine aktarılması gerekmektedir. YÖKSİS entegrasyonu bu ihtiyaç ve sorunlara çözüm olacaktır. YÖKSİS bir SOAP servisidir.

AKS:¶

Adres Kayıt Sistemi, Nüfus ve Vatandaşlık İşleri tarafından sağlanan bir edevlet hizmetidir. Sistemimiz bu hizmet ile tam entegrasyon halinde olacak ve sisteme kayıtlı kişilerin adres bilgilerini bu sistemdeki kayıtlar ile güncelleyecektir.

MERNİS:¶

AKS gibi merkezi kimlik hizmetidir. Sistemde kayıtlı kişilerin kimlik bilgileri MERNİS ile uyumlu şekilde saklanacaktır.

BANKALAR:¶

Öğrenci Harç ve ödeme işlemlerinin takip edilmesi için bankaya açılacak olan servistir. Banka öğrencilerin ödemeleri gereken miktarları bu servis aracılığı ile öğrenir ve ödeme bilgilerini sisteme geri bildirir. Bizim tarafımızda açılacak servis REST türünde olacaktır.

SMS:¶

Öğrenci ve personele SMS bildirimleri yapmak isteyecek öğrenciler üniversiteler kendi servislerini Zato ESB ile kolayca yazabileceklerdir.

Rol ve Yetki Kontrolü (ACL - Access Control List)¶

Rol ve Öznitelik tabanlı hibrid bir yetkilendirme ve veri erişim kontrol modeli kullanılacaktır. Kurgulanacak sistem, Midpoint IDM gibi kimlik yönetimi sistemleri ile dış kimlik kaynaklarıyla (LDAP, veritabanları) REST metoduyla veri alışverişi yapabilecektir.

Rol Tabanlı Yetkilendirme (Rol Based Authorization Control)¶

Rol ve yetkiler, Akademik ve İdari Birimler (Units), Soyut Roller(Abstract Roles), İş Akışı(WorkFlows), İş Akışı Adımları(WorkFlow Tasks) ve Kullanıcı (User) kavramlarının kesişimleri sonucu ortaya çıkarlar.

Kullanıcıların bir birimde, tanımlanmış herhangi bir role (bölüm sekreteri, öğretim elemanı, öğrenci vb.) dahil olmaları onları belirli workflowların belirli adımları için yetkili olmalarını sağlayacaktır. Örnek verecek olursak:

Birim: Mühendislik Fakültesi Bilgisayar Mühendisliği Bölümü Soyut Rol: Bölüm Başkanlığı Kullanıcı: Ayşe Bilgin, Öğretim Üyesi, Prof. İş Akışı: Ders, Öğretim Elemanı Paylaşımı. Bu iş akışının 2 aktörü vardır. Paylaşımı yapan bölüm sekreteri, bu paylaşıma onay veren bölüm başkanı. İş Akışı Adımları: İş akışı, yineleyen düzeltme - gözden geçirme ve nihayetinde onay ve ilgililere bildirim adımlarından oluşmaktadır.

Ayşe Bilgin, bölüm başkanı olarak, sadece kendi bölümü ile ilgili olarak bu iş akışının ilgili adımları için otomatik olarak yetkilendirilmiş olacaktır.

Öte yandan Ayşe Bilgin bir başka birimde, geçici olarak, bir rol ile sadece belli görevleri yapmak üzere görevlendirilmiş olsun. Bu durumda Ayşe Bilgin’in yetkileri, ilgili rolün sahip olduğu yetkilerin (iş akışı adımları yetkileri) bir kısmı ile genişletilebilecektir. Bu da ancak ilgili iş akışı adımlarının ilgili birim ve rol ile somutlanmasının yetki olarak tarif edilmesiyle mümkün olabilmektedir.

Öznitelik Tabanlı Yetkilendirme (Attribute Based Authorization Control)¶

Bu modelde ise yukarıda tarif edilmiş yetkilerin, mekan, zaman, geçici sınırlamalar gibi özelliklere göre daraltılması veya genişletilmesidir. Belirli yetkilerin ancak belirli zaman aralıklarında, belirli mekanlarda ve kullanıcının sahip olduğu özniteliklerin belirli eşleşmeleri sağladığı durumlarda gerçekleşmesi durumudur.

İzindeki veya dışarıda görevlendirilmiş bir personelin belirli iş akışlarını yürütememesi, kritik iş akışlarının mesai saatleri içinde veya okul içinden yapılması vb.

Satır ve Hücre Seviyesinde Erişim Kontrolü¶

Yukarıdaki modellere göre yetkilendirilen kullanıcılar, belirli bir buckettaki kayıtların hangilerine erişebilecekleri ve erişebildikleri bu kayıtların hangi alanlarını görebilecekleri konusunda sınırlandırılacaklardır. Bu sınırlamaların hemen hepsi veri erişim katmanı (pyoko) seviyesinde işletilecektir.

# Veri modeli tanımlaması

class Student(Model):

sno = field.String(index=True) name = field.String(index_as=’text_tr’) phone = field.String(index=True)

class Meta(object):

cell_filters = {: ‘can_view_student_phone’: [‘phone’] }

def row_level_access(self):

self.objects = self.objects.filter(unit_in=self._context.user[‘unit’][‘id’])

# Workflow adımında çağırılan view metodunda veritabanı sorgulaması

def show_student_list(context):

# context ‘session’, ‘request’, ‘response’, ‘permissions’, ‘user’ nesnelerini içerir. Student(context).all()

Yukarıda öğrenci listesini gösteren örnek view metodunda Student modelindeki tüm kayıtlar istenmesine karşın, erişim katmanı model içerisine tanımlanmış olan satır tabanlı kısıtları işleterek o an giriş yapmış olan personelin, sadece kendi bölümündeki öğrencileri görmesine müsade etmektedir. Benzer şekilde eğer cell_filters süzgeci tanımlandıysa, veri tabanından dönen veriler, kullanıcının görmeye yetkili olmadığı hücreler filtrelendikten sonra view metoduna döndürülür. Veri erişim kontrolü mümkün olduğunca model seviyesinde yapılarak, olası hata ve güvenlik açıklarının en aza indirgenmesi hedeflenmektedir.

İki Seviye Yetkilendirme¶

Kullanıcılar bazı kritik işlemler için ikinci bir parola ile yetkilendirilirler. Kullanıcılara ait bazı kayıtları silme, nihayi onayları verme, toplu kayıt işlemleri gerçekleştirme gibi durumlarda ikinci bir adımda bu işlemlerin kritik oldukları anımsatılır ve kendilerine ait başka bir parola ile devam etmeleri sağlanır.

Yetki Devri¶

Rol veya role ait bazı yetkiler farklı kullanıcılara devredilebilirler. Devredilen yetkiler tek tek iş akışı adımları veya bir rolün sahip olduğu tüm yetkiler şeklinde belirlenebilir. Yetki devri belirli sürelidir. Yetki devredilen kullanıcı için geçici bir rol tanımlanır. Kullanıcı bu geçici rol ile kendi rolü arasında geçiş yaparak ilgili görevleri yerine getirebilir.

Test Döngüsü¶

Yazılım geliştirme ve buna bağlı test döngüsü “Yazılım Geliştirme ve Test Döngüsü” belgesinde detaylı olarak verilmiştir.

Yerelleştirme¶

Yazılımın temel dili Türkçedir. Çoklu dil desteği sistemin doğal özelliklerinden birisidir. Gettext kullanılacaktır.

Güvenlik Ölçümleri¶

Güvenlik test ve kontrolleri “Yazılım Geliştirme ve Test Döngüsü” belgesinde detaylı olarak verilmiştir.

Data Erişim Seçimleri¶

Neden RDBMS Kullanmıyoruz?¶

Bu uygulamada ortaya çıkan entity yapıları, geleneksel rdbms çözümlemeleri ile ele alınamayacak kadar karmaşık yapılardır. Bu artan verinin RDBMS ile dağıtık olarak yönetilebilmesi çok fazla problemle uğraşmak anlamına gelmektedir. Uygulama içinde kullanılacak Object Relational Mapping (ORM) [1] işlemleri için Pyoko adında bir kütüphane geliştirilmiştir. Bu sebeple:

Neden Eventually Consistent Kullanmıyoruz?¶

Riak’ı Eventually Consistent modunda kullandığımızda, concurrent yazma işlemleri sonucu verinin birden fazla değişik versiyonu oluşabiliyor. (Sibling) Çünkü veri, farklı nodelardaki kopyalarının durumu gözetilmeksizin yazılıyor. Oluşan conflictler ise daha sonra çözüme kavuşturuluyor. * [1] Bu da ayrıca yönetilmesi gereken oldukça karmaşık bir problemi beraberinde getiriyor.

Oluşan conflictler birkaç yolla çözüme bağlanabiliyor.[2] Bu çözümlerin bir kısmı Riak tarafından otomatik olarak yapılabiliyor. Riak’ın sağladığı iki temel çözüm time-based ve last-write-wins şeklinde. Riak’ın internal çözümleri dışında uygulama katmanından bu çözümleri uygulamak da mümkün. Fakat aynı bucket üzerinde hem Riak internal hem de application taraflı çözümleri kullanamıyoruz. Bir bucketdaki conflictlerin nasıl çözüleceği bucket metadataları ile kontrol ediliyor. Riak internallar için allow_mult parametresi false olması gerekirken, uygulama taraflı çözümler için true olması gerekiyor.

Yani hem Riak internal çözümlerini hem de uygulama çözümlerini tek bir bucket üzerinde birlikte kullanmak mümkün değil. Bizim durumumuzda bu tür conflictlerin uygulama katmanında

çözüme bağlanması kaçınılmaz. Bu da birçok bucketta Riak’ın last-write-wins veya timestamp gibi çözümlerini kullanamayacağımız anlamına geliyor. Çünkü aynı verinin farklı kesitlerine farklı kullanıcılar erişiyor. Uygulama katmanında conflict resolution ise data layerında daha fazla complexity demek.

*http://docs.basho.com/riak/latest/dev/using/conflict-resolution/

Neden Data Type Kullanmıyoruz?¶

Veri tipleri sadece eventually consistent sistemlerde kullanılabiliyor.[3] Veri tipleri, yukarıdaki problemi her bir data type için Riak tarafından farklı tanımlanmış kurallar dahilinde çözüyorlar[4] ve buna uygulama katmanında müdahale etmek mümkün değil. Kararı Riak veriyor. Eventually consistent ortamda, uygulama katmanında conflict resolution mümkün olmadığı için veri tipleri kullanamıyoruz.

Riak veri tipleri sayesinde sınırlı da olsa search (arama) imkanı sağlıyor. Bunu da register, flag gibi belirli tipleri solr şemasında dynamic field olarak tanımlayarak yapıyor.[4] Bizim register, flag şeklinde işaretlediğimiz her veri, dynamic field tanımlaması sayesinde solr da indexleniyor. Riak’ın bu veri tipleri sayesinde search için eklediği ekstra bir özelliğe dair dökümanlarda altı çizilen bilgi yok. Bizim verimize uyacak nested biçimde register, counter ve setler içeren maplere bağlı olarak dynamic field ı bu şekilde kullanmak, sayısız ve kontrolsüz biçimde artan index ve inverted indexlere[5] yol açacaktır.

Neden Write Once Kullanmıyoruz?¶

Write Once kullandığımızda sistem sürekli farklı keylere yazacağı için conflict oluşmaz. Fakat uygulama katmanında verinin bütünlüğü için alacağımız önlem, yani verinin yazılmadan önce okunması, farklı nodelardan okuma ve sistemde oluşabilecek gecikmelerden dolayı yüzde yüz garanti sağlamaz. Yazma isteğinin doğrulanması için yapılacak okuma ve yazma farklı nodelardan yapılacağı için burada da verinin bir öncekini baz alan iki farklı kopyası oluşacaktır.

Bunun yanı sıra arama işini daha karmaşık hale getirmekte, çok kopyalı sonuçlar arasında en son kopyaya ulaşma gibi ekstra bir zorluk eklemektedir.

Neden Strong Consistency?¶

Riak Strong Consistency modunda conflictlere izin vermez. Veri tüm nodelarda eşlenene kadar yazıldı olarak kabul edilmez. Concurrent işlemlerde tıpkı RDBMS’lerdeki locklarda olduğu gibi yazma hataları döndürür. Bu da uygulama katmanında çok daha kolay yönetilebilir ve basit bir conflict resolution policy anlamına gelir.

Neyi Nasıl Kullanacağız?¶

Log, temporary datalar hariç Strong Consistent bucketlar kullanacağız. Tek kopya üzerinde çalışacağız. Datayı yapabildiğimiz kadar flat hale getirip, solr indexleri için mümkün olduğunca az dynamic field içeren şemalar kullanacağız. Flat haline getirilmiş bucket arasında linkler ile relationlar kuracağız. Versiyonları ayrı bir Write Once Bucket’ta tutacağız. Bunlara bir pk ve date fieldları ekleyip bu iki field ı solr da indexleyeceğiz.

Notlar¶

1: If you are using Riak in an eventually consistent way, conflicts between object values on different nodes is unavoidable. Often, Riak can resolve these conflicts on its own internally if you use causal context, i.e. vector clocks or dotted version vectors, when updating objects. Instructions on this can be found in the section.

http://docs.basho.com/riak/latest/dev/using/conflict-resolution/ 2.paragraf

2:http://docs.basho.com/riak/latest/dev/using/conflict-resolution/#Client-and-Server-side-Conflict-Resolution

3: http://docs.basho.com/riak/latest/ops/advanced/strong-consistency/#Important-Caveats

4: https://github.com/basho/yokozuna/blob/develop/priv/default_schema.xml#L100

5: https://en.wikipedia.org/wiki/Inverted_index

[1]	https://en.wikipedia.org/wiki/Object-relational_mapping

Standart Fakülteler için Yazılım İhtiyaç Analizi Belgesi¶

Tanımlar¶

Fakülte¶

Kendisine bölümler bağlanabilen akademik birimdir.

Dekan¶

Rektör önerir, YÖK 3 yıllığına atar. Fakültenin ve birimlerinin temsilcisidir. Başka bir üniversiteden atanabilir. Süresi biten dekan yeniden atanabilir. Fakülte kurullarına başkanlık eder. İstenilen raporları hazırlar.

Dekan Yardımcısı¶

Dekan kendisine çalışmalarında yardımcı olmak üzere fakültenin aylıklı öğretim üyeleri arasından en çok iki kişiyi dekan yardımcısı olarak seçer. En çok 3 yıl.

Dekana, görevi başında olmadığı zaman yardımcılarından biri vekalet eder. Göreve vekalet altı aydan fazla sürerse yeni bir dekan atanır.

Fakülte Kurulu¶

Dekan başkanlık eder. Bağlı bölümlerin başkanları ile varsa fakülteye bağlı enstitü ve yüksekokul müdürlerinden ve üç yıl için fakültedeki profesörlerin kendi aralarından seçecekleri üç, doçentlerin kendi aralarından seçecekleri iki, yardımcı doçentlerin kendi aralarından seçecekleri bir öğretim üyesinden oluşur.

Fakülte Yönetim Kurulu¶

Fakülteyle ilgili kararların aldındığı birimdir. Dekan başkanlık eder. Üyeler, Fakülte Kurulu’nun seçtiği 3 profesör, 2 doçent ve 1 yardımcı doçentten oluşur.Dekan çağrısı üzerine toplanır.

Öğrencilerin verdiği dilekçeler, hocaların verdiği dilekçeler ve senatoya gidecek tüm evraklar buradan geçer.

Öğrencilerin kabulü, ders intibakları ve çıkarılmaları ile eğitim öğretim ve sınavlara ait işlemleri hakkında burada karar verilir.

Fakülte Sekreteri¶

Fakültenin idari amiridir.

Fakülte Öğrenci İşleri¶

Öğrencilerin kayıt işlemleri: İlk ve sonraki kayıtlar
Askerlik işlemleri: Yeni kayıtları, kaydı silinenleri, mezun olanları, aktif öğrencileri askerlik şubesine bildiriyorsunuz. Askerlik durum belgesi çıktısı alınıp postayla gönderiliyor.
Ders işlemleri: Ders kaydı: Birinci sınıfa gelenler
Ders ekleme çıkarma: Öğrenci durumunu güncelleme (pasif, disiplin cezası, kayıt dondurma)
Harç işlemleri: Öğrencinin harç bilgisi sistemde duracak. Banka web servisi ile bilgiyi alacak. Ödendiyse geri bildirecek.

Mezuniyet İşlemleri

Bölüm¶

Bir fakülte ya da yüksekokulda, aynı veya benzer nitelikte eğitim-öğretim yapan birden fazla bölüm bulunamaz.

Her bölümün YÖKSİS Birim ID’si bulunur.

TUIK Kodu

Hazırlık durumu olur. Yok - Secmeli - Zorunlu

Eğitimi Tipi - Dönemlik / Yıllık

Bölüm sistemde pasif hale getirilebilir. Pasif hale gelirse alt birimler de pasif hale gelir.

Bölüm Başkanı¶

Bölümü yönetir.

Bölüm başkanı; bölümün aylıklı profesörleri, bulunmadığı takdirde doçentleri, doçent de bulunmadığı takdirde yardımcı doçentler arasından dekanca üç yıl için atanır.

Bölüm başkanı, görevi başında bulunamayacağı süreler için öğretim üyelerinden birini vekil olarak bırakır.

Herhangi bir nedenle altı aydan fazla ayrılmalarda, kalan süreyi tamamlamak üzere aynı yöntemle yeni bir bölüm başkanı atanır.

Çeşitli raporlar alabilmelidir.

Bölüm Kurulu¶

Anabilim dalı başkanlarından oluşur.

Anabilim Dalı¶

Bölümlerin altında açılmış branşlardır. Öğretim üyelerinden oluşur.

Anabilim Dalı Başkanı¶

Anabilim dalına bağlı öğretim üyeleri arasından seçilir.

Danışman¶

Bölüm Başkanı’nın önerisi ile dekan tarafından görevlendirilen akademik personeldir. Öğrencilerin ders seçme gibi eğitim-öğretim faaliyetlerine danışmanlık eder.

Ders onayı yapar. Ders ekleme çıkarma yapabilir. Transkript görüp mezuniyet onayı verir. Öğrencinin kişisel bilgilerini, notlarını, devamsızlık durumunu görebilir. Sistemden uyarılar alır. Farabiyle giden, erasmus ile giden, kayıt donduran, yatay geçişle giden ve kendisi ders kaydı yapmamış öğrenci yerine ders kaydı yapamaz.

Program¶

Bir bölümün tüm öğrenim programıdır. Ders ve uygulamalardan oluşur. Her ders ve uygulamanın ilgili programda bir kredisi mevcuttur.

Bölüm Kurulu’nun önerisi üzerine Yönetim Kurulu tarafından karara bağlanarak en geç Mayıs ayı içinde REKTÖRLÜĞE sunulur. SENATO onayı ile kesinleşir.

Lisans Programları 128 - 160 kredi, Lisans ve Yüksek Lisans birlikte veren 5 yıllık programlar için 162 - 194 kredidir.

Lisans Programları 240 AKTS, Lisans ve Yüksek Lisans birlikte veren 5 yıllık programlar için 300 AKTS, 6 yıllık programlar için 360 AKTS’dir.

Program Mezuniyet Ortalaması, programdan mezun olmak için gereken not ortalamasıdır. Öğrenci tüm derslerden geçse bile bu ortalamayı tutturamıyorsa mezun olamaz.

Ders¶

Dersler, program dahilinde açılırlar. Bölüm Kurulu tarafından yapılan müfredat oluşturma toplantısı ile belirlenir. Açılacak, kapatılacak ya da değiştirilecek dersler Bölüm Kurulu kararı ile tanımlanır. Ders içeriği ve derse ait sınavlar dersin hocası tarafından belirlenir. Dersler dönemliktir. KURUL veya SENATO kararıyla dersler yıllık olabilir.

Dersin dönemlik veya yıllık olup olmadığı kayıt altına alınmalıdır.

Aynı ders başka bir programda farklı bir derstir. Aynı ders başka bir programda aynı ders ise aynı krediye sahiptir.

Bir programda aynı ders birden fazla dönemde yer alabiir. Örneğin MAT01, birinci yılın hem birinci döneminde hem de ikinci döneminde yer alabilir. İlgili programdaki öğrenci için aynı krediye sahip, aynı derstir. Hocası, şube sayısı farklı olablir.

Ders Şubesi¶

Bölüm Kurulu kararıyla dersler şubelere bölünebilir. Öğrenciler ders seçimi sırasında bu şubelerden sadece birini seçerler. Ders şubelerinde sınavlar aynıdır, harflendirme aralıkları (başarı kriteri) uygulaması farklıdır. Bu kriterler derslerin sisteme girişi yapılırken tanımlanır. Öğrencilerin şubeleri daha sonra elle değiştirilebilir.

Öğrenci Şubesi¶

İlk kayıt sırasında, öğrencileri gruplandırmak için şubelere bölünür. Öğrenciler ilk kayıt yaptırdığında şube açma işlemi;

çeşitli şablonlara göre yapılabilir:
- tek numara / çift numara
- ilk n sayıda öğrenci, sonraki n sayıda öğrenci vb.
elle seçilebilir.

Eğer şubelendirme yapılmamışsa, öğrenciler ŞUBE 1’dir.

Şubelerin bölüm ve bölüm dışı kontenjanları olabilir. Dersler, belli bölümlere, belli fakültelere veya tüm üniversiteye ait olabilir.

Ders kayıtlarından sonra eğer öğrenci fazlalaşırsa MEB uygulama okullarını bildirir. Dekanlığa bağlı Uygulama Koordinatörlüğü bölümlere okulları dağıtır. Öğrenciler 10’ar kişilik gruplar halinde okullara dağıtılır.

Her anabilim dalında uygulama koordinatörü vardır. Öğrenciler şubelendirilip, okullara uygulama koordinatörleri tarafından dağıtılır. Bölüm sekreteri de şubelere bir hoca ataması yapar.

Ders Kredisi¶

Bir dersin başarıyla tamamlanabilmesi için öğrencinin yapması gereken çalışmaların tümünü ifade eder. (teorik dersler, uygulama, seminer, bireysel çalışma, sınavlar, ödevler, kütüphane çalışmaları, proje, stajlar, mezuniyet tezi vb.)

Krediler anabilim dalı kurulu tarafından belirlenir. Mayıs ayında senatoya gider. Senatodan onay çıktığı takdirde yöke gönderilir. Ancak AKTS sisteminde (Bologna süreci) iş yükü hesabı ile kredi belirlenir (25 saat = 1 Kredi şeklinde [Bu eşitlik bazı üniversitelerde farklı olabiliyor]).

Bir dersin

Teorik = Teorik Kredisi

Pratik = Pratik Kredisi

Klasik Ders Kredisi = Teorik + Pratik / 2

ECTS = Sabit (Bologna hesabı)

Zorunlu Ortak Ders¶

YÖK Kanunu ve YÖK Yürütme Kurulu’nca belirlenen şu dersleri ifade eder:

Atatürk İlkeleri İnkılap Tarihi
Türk Dili
Yabancı Dil Dersleri
Bilgisayar Dersleri

Ön Şartlı Ders¶

Alınabilmesi için önceki yarıyıl veya yıllardaki bir veya birden çok dersin başarılması şartı bulunan derslerdir.

Şart, ilgili dersin başarılı olma kriterini yerine getirmek olabileceği gibi, belirli bir notun alınmış olmasını da içerebilir. Örnek: Bilgisayar Mühendisliği Veri Yapıları dersi, Algoritmalar ve Programlama 2 dersinden en az DD almak.

Ön şartlar ders programında önceden ilan edilir.

Seçtirmeli Ders¶

Gruplar halinde tanımlanırlar. Öğrenci bu gruptaki derslerden herhangi birini veya birden çoğunu alabilir. Seçmeli derslerden kalanlar aynı gruptaki başka bir dersi alabileceği gibi, kaldıkları dersi almaya, öğrenci işleri veya danışman tarafından zorlanabilir. Bu zorlama ders grubu tanımında belirlenir.

Grup tanımı yapacağız. Grup başarısı için alınması gereken ders sayısı belirlenir. Öğrenci bu kriteri sağladığında, grup dersinden geçmiş olur.

Öğretim Yılı¶

14 haftadan az olmayan iki yarıyıldan oluşur.

Normal Öğretim Süresi¶

Bir yıl süreli yabancı dil hazırlık sınıfı opsiyonel,lisans eğitimi 4 yıldır. Kayıt dondurma normal öğretim süresine dahil değildir.

Azami (En fazla) Öğretim Süresi¶

Yeni yönetmelikler incelenecek. 6 yıllık ve hazırlıkla ilgili bilgi alınacak. Hazırlık sınıfları azami 2 yıldır. 2 yıllık ön lisansta 4 yıl, 4 yıllık lisansta 7 yıldır. 5 yıllık okullarda 8 yıldır. 6 yıllık okullarda 9 yıldır.

Ücretler¶

Öğrenim ücretleri, normal öğretimlerde normal öğrenim süresinin aşmasını takiben, 2. öğretimlerde ise birinci dönemden itibaren alınan harç ve uzatılan ders kredisi oranında alınan dönemlik ücretlerdir.

Çift ana dal programında kayıtlı olan öğrencilerden ise normal öğrenim süresine ilave bir yılın ardından ücret alınır.

Harç ücretleri Bakanlar Kurulu tarafından Ağustos sonu itibarıyla belirlenir.

Sınavlar¶

Ara Sınav

Her yarıyılda en az bir adet yapılır.

Sonuçları en geç genel sınavdan 15 gün önce öğretim görevlileri tarafından sisteme girilmelidir.

Genel Sınav

Dersin tamamlandığı yarıyıl veya yıl sonunda yapılır.(Devam zorunluluğu sağlanmalı)

Sonuçları sınavların ardından en geç 5 gün içinde açıklanmalıdır.(Uygulamalı bir ders ise uygulamalarda başarılı olunmalıdır.)

Bütünleme

Genel sınava girme hakkı olup giremeyen veya ara sınav ve genel sınav sonucu başarısız olanlar.

Tek ders

Mezuniyetleri için tek dersi kalan öğrenciler.(Devam zorunluluğu sağlanmalı)

Ara sınav şartı aranmadan CC ile öğrenci başarılı sayılır.(Ders önceki yıllarda alınmış olmalı)

Muafiyet

Yabancı dil hazırlık sınıfında okumak zorunda olanlar için ilgili dil dersinden yarıyıl başında açılır. 70 ile geçer. Ortalamaya dahil edilmez.

Hazırlık sınıfı olmayan, zorunlu İngilizce dersi için öğretim yılı başında yapılır. CC ile geçer. Ortalamaya dahil edilir.

Mazeret

Geçerli mazeretleri olan öğrencilere ara sınavlar için tanınan haktır. Başka hiçbir sınav için mazeret sınavı uygulanmaz.(Ara sınav dönemi için geçerli mazeret bildirilmelidir.)

Ek Sınav

Uygulamalı derslerin ek sınavları olabilir. Ara sınav şartı aranmaksızın ek sınavlarda alınan en az CC ise öğrenci başarılı sayılır.

Kural Setleri¶

Süreler¶

Normal Öğretim Süresi:¶

Üniversiteden süreli uzaklaştırma cezası alan öğrencilerin ceza süreleri ve mesleki hazırlık sınıfı için verilen ek süreler eğitim-öğretim süresinden sayılır. Ancak yabancı dil hazırlık sınıfı için verilen ek süreler eğitim-öğretim süresinden sayılmaz. Kayıt dondurma sayılmaz.

Azami Öğretim Süresi:¶

Öğrencinin kayıt dondurduğu yıllar dahil edilmez. Afla veya intibakla gelen öğrenciler için başlangıç dönemi girilecek ve bu dönemden itibaren kaç tane aktif dönemi varsa sayılarak maksimum süreyi geçip geçmediği tespit edilecek.

Af ve intibak: Öğrenci gelir. Önceki durumu (en son transkript) bölüme gönderiyoruz. Bölüm kararı ile öğrencinin hangi derslerden muaf olduğu ve hangi dersleri alacağı bildirilir. Ayrıca hangi dönemden başlayacağı bildirilir. Öğrencinin önceki dönemleri kaç yılda tamamladığı hesaba katılmaz. Başladığı dönem hesaba katılarak azami ve normal öğretim süresi işletilir.

Azami süreler içinde katkı payı veya öğrenim ücretinin ödenmemesi ile kayıt yenilenmemesi nedeniyle öğrencilerin ilişikleri kesilmez.

Ancak üniversite yetkili kurullarının kararı ve Yükseköğretim Kurulu’nun onayı ile dört yıl üst üste katkı payı veya öğrenim ücretinin ödenmemesi ile kayıt yenilenmemesi nedeniyle öğrencilerin ilişikleri kesilebilir. - İlişik kesme nedeni.

Azami süre içerisinde başarılı olmadıysa kayıt ücretlerini ödemek koşulu ile ders ve sınavlara katılma hariç, öğrencilere tanınan diğer haklardan yararlandırılmaksızın öğrencilik statüleri devam eder.

Azami öğretim süresi sonunda öğrencinin 5 adet dersi ancak nottan kaldıysa 3 yarıyıl daha ek süre verilir. Öğrenci bu dersleri 3 derse indirebilirse, zaman sınırı olmadan sınav hakkı verilir.

Devamlılık Kuralları¶

Öğrenciler, teorik derslerin % 30’undan ve / veya uygulamaların % 20’sinden fazlasına devam etmezlerse başarısız sayılırlar.
Tekrarlanan derslerde önceki dönemde devam şartı yerine getirilmiş ise, ara sınavlara girmek kaydıyla bu derslerde devam şartı aranmaz.
- Tekrarlanan derslerde, uygulama sınavı yapılan veya sınıf geçme sistemi uygulanan fakülte ve yüksekokullar için devam şartı aranır.

Sınava Katılma Şartları¶

İlgili dersten muaf öğrenciler sınava giremezler.
Kayıtları dondurulmuş öğrenciler sınavlara giremezler.
Mazeretli öğrenciler sınava girmezler. Sınava girerlerse, sınavları geçersiz sayılır.
- Mazeret işlenirken saat dikkate alınmalı. Ögrenci saat konusunda bilgilendirilmeli.
Devamlılık kurallarına uymayan öğrenciler o dersin genel sınavına giremezler.
Uygulamalarda başarılı olamayan öğrenciler o dersin genel sınavına giremezler.
Tek ders sınavına girmek için, ilgili dersin devam şartları sağlanmış olmalıdır.
Disiplin cezası almış öğrenciler, ceza süresi içerisinde hiçbir sınava giremezler.

Puan Sistemi¶

Hocalar değiştirmediği sürece, sınav sonuçları şu şekillerde ifade edilir:

100’lük Sistem	Harf	4’lük Sistem
90-100	AA	4.00
85-89	BA	3.50
75-84	BB	3.00
70-74	CB	2.50
60-69	CC	2.00
55-59	DC	1.50
50-54	DD	1.00
40-49	FD	0.50
0-39	FF	0.00
–	F	0.00

Harf Sistemi¶

AA,BA,BB,CB,CC	Başarılı
DC	Şartlı Başarılı
DD,FD,FF	Başarısız
F	Devamsızlık veya uygulamadan başarısız, genel sınava girme hakkı bulunmayan öğrenci
G	Geçer notu, kredisiz derslerde başarılı olan öğrenci
K	Geçmez not, kredisiz derslerde başarısız öğrenci
M	Dikey/yatay geçişle kabul olunan başarılı sayıldıkları dersler

Ders Başarı Hesaplama¶

Öğrenci bir dersten AA, BA, BB, CB, CC almışsa o dersten başarılı sayılır.

Ayrıca dönem / yıl ağırlıklı not ortalaması 2.50 olan öğrenci şartlı başarılı, DC olan derslerden de başarılı sayılır. Şartlı geçiş işlemi tüm not girişlerinin tamamlanmasının ardından otomatik yapılır.

Başarı Hesaplama¶

Ağırlıklı Not = AKTS * Not Katsayısı (4’lük not)

Dönem Ağırlıklı Not Ortalaması = O dönem alınan tüm derslerin ağırlıklı not toplamı / tüm derslerin kredi toplamı

Genel Ağırlıklı Not Ortalaması = Kayıt olunan zamandan hesaplama zamanına kadar alınan ve harflenmiş tüm derslerin ağırlıklı not toplamı / aynı derslerin kredi toplamı

Mezuniyet Ağırlıklı Not ortalaması:

Mezun olmaya hak kazanılan tarih itibariyle genel ağırlıklı not ortalaması

Ortalama hesaplarında ondalık kısmı iki hane olur. 3. hane 5’ten küçükse 0’a indirgenir, 5’ten büyükse ikinci hane bir arttırılarak hesaplanır.

3,144 -> 3,140 -> 3,14

3,145 -> 3,150 -> 3,15

Yerine alınan ders dahil edilir. Bırakılan ders dahil edilmez. Tekrar edilen derslerden son harf notu dikkate alınır. Muaf dersler ortalama hesaplamaya dahil edilmez.

Dönem hesabı yapılırken o dönem alınanlar -bırakılanlar dahil- hesaplamaya dahil edilir.

Ücret Hesaplama¶

Ücretler Harç Tipine göre hesaplanır. 100’lük hesaplancak.

Normal Harç
Formasyon Harcı
Yabancı Uyruklu
Ücretsizler (Şehit ve Gazi Çocukları)
Ücretsizler (Mavi kart)
Ücretsizler (Suriyeli)
Ücretsizler (YD Öğrenimini Tamamlayanlar)
Ücretsizler (YD Türk Okulunda Tamamlayanlar)
MEB Burslusu
Özel Üniversiteden Yatay Geçişle Gelen
Diyanet Burslusu
Türk Asıllı Yabancı Uyruklular
Türkiye Burslular
Hükümet Burslular

İki farklı ücret hesaplanmaktadır.

Harç: Bakanlar Kurulu tarafından belirlenen miktar (HARÇ)

Kalan Derslerin Kredi Toplamları: Normal Öğretim Süresi ardından kalan dersler arasından ilgili dönemde alınacak derslerin kredi toplamı (KDKT)

Dönem Kredi Toplamı: O dönemde alınması gereken toplam kredi (DKT)

Normal Öğrenim¶

Normal Öğretim Süresi	0
Normal Öğretim Süresini Aşanlar	HARÇ + (((HARÇ / DKT) * KDKT) * 3/2)
Örnek Hesaplama Harç 300 TL Kalan Ders Kredisi 6 Dönem Toplam Ders Kredisi 30	300 + ((300 / 30) * 6 * 3/2) 300 + 90 390 TL

İkinci Öğretim¶

Normal Öğretim Süresi	0
Normal Öğretim Süresini Aşanlar	HARÇ + (((HARÇ / DKT) * KDKT) * 3/2)
Örnek Hesaplama Harç 300 TL Kalan Ders Kredisi 6 Dönem Toplam Ders Kredisi 30	300 + ((300 / 30) * 6 * 3/2) 300 + 90 390 TL

Mezuniyetleri müteakip akademik yıla taşan öğrenciler, o yarıyılın da katkı payını veya ikinci öğretim ücretini öderler. Ancak tek ders sınavında başarılı olan öğrenciden o dönemin harcı alınmaz.

İş Akışları¶

Kayıt İşlemleri¶

İlk Kayıt:¶

Öğrencilerin bilgileri ÖSYM sistemine bağlanılarak çekilir ve öğrenciler sisteme “geçiçi kayıt” olarak kaydedilir. Bilgileri Mernis ve AKS’den güncellenir.
Öğrenci için öğrenci numarası ve geçici bir parola verilir.
Askerlik durumları ASAL’dan web servisi ile öğrenilir. Askerlik engeli olanlar kayıt yaptıramazlar.
1. öğretim öğrencilerinin harç ödeme bilgilerini banka bizim sistemden öğrenip, ödeme bilgilerini web serivisi aracılığıyla yine bizim sisteme yazacak.
- harcını ödememiş olanların kayıt işlemleri yapılamaz.
- askerlik sıkıntısı olanların durumu bankaya uygun şekilde bildirilir.
Öğrenciler, öğrenci numarası ve geçici parola ile giriş yapıp, ön kayıt formu internetten doldurup çıktısını alır. Öğrenci durumu ön kayıt olarak işaretlenmeli, ön kayıt formu askerlik engeli olanara gösterilmez. Askerlik engeli bu öğrencilere uygun şekilde gösterilir.
Ön kayıt yapmamış öğrenciler kesin kayıta geldiklerine ön kayıtları yapılır.
Öğrenci kayıt şartlarında belirlenen belgeleri teslim ettiğinde kayıt tamamlanmış olur. Öğrenci kayıtlı hale gelir.

Kayıt dönemi kapandığında kesin kayıt haline gelmemiş geçici kayıtlar ve ön kayıtlar silinir. Kesin kayıt dönemi bittiğinde boş kontenjanlar için rapor haline getirilir. Ek kontenjan ile gelenler de ilk kayıt sürecine tabidir.

Eğer öğrenci ÖSYM aracılığıyla gelmiyorsa, ön kayıt işlemi yapılmaz, birinci adım elle işlenir ve öğrenciye kesin kayıt yapılır. Geliş tipine göre gerekli alanlar doldurulur. Geldiği kurum, geldiği bölüm, geldiği ülke vb..

Kesin Kayıt Sonrası:¶

Sistem öğrencilere programın gerektirdiği ilk ders atamalarını otomatik yapar.
Öğrencilere bir danışman hoca ataması, bölüm sekreterliği tarafından yapılır.
Askerlik durumları bildiriliyor. Belge üretip postaya verilecek.
Şubelendirme yapılır.

Kayıt Yenileme:¶

Kayıt yenileme için 2. öğretimler veya normal öğretim süresini aşanlar için ders seçimi yaptırılır.
Ders seçimlerinin sonucu ortaya çıkan harçlar öğrenci tarafından bankaya yatırılır.
Normal Öğretim Süresi içinde olan öğrenciler harç ödemeden, ders seçimi yaparak kayıt yenilerler.
Bu aşamaların ardından dersler danışman onayına açık hale getirilir.
Danışman onayıyla kayıt yenileme işlemi tamamlanır.

Kayıt Dondurma:¶

Haklı ve geçerli mazereti olan öğrencilerin öğrenim süreleri, yönetim kurulu kararıyla dondurulur. Sağlık ile ilgili mazeretlerde sağlık kurulu raporu zorunludur. Kayıt dondurma süresi öğretim sürelerinden sayılmaz. Min 1 dönem,, max 2 dönem kayıt dondurabilir. 2. dönem sonunda kayıt aktif edilir.

Hiç bir öğrencilik haklarından faydalanamaz. Belgeleri (askerlik, öğrenci, transkript) alamaz, epostasina giremez, ders kaydı yapamaz, sınavlara giremez vb..

Kayıt Silme:¶

Aşağıdaki hallerde kayıt silme işlemi yapılır:

İlgili mevzuat hükümlerine göre üniversiteden çıkarma cezası almış olması.
Öğrenci tarafından yazılı olarak kayıtlı olduğu birim ile ilişiğinin kesilmesi talebinde bulunulması.
Kayıt esnasında istenen belgelerden herhangi birinin daha sonradan gerçeğe aykırı olduğunun tespit edilmesi.
Vefat
Dikey Geçiş, Nakil vb.

Kayıt silme aslında silindi olarak işaretlenir. Hiçbir öğrencilik haklarından faydalanamaz. Sistemde görünmez hale gelir.

Kayıt silme işlemi fakülte kurulu kararı ile fakülte öğrenci işleri tarafından uygulanır. Kayıt silme sebebi seçilir ve açıklama not halinde yazılır.

Ders Açma¶

Program yıllara göre versiyonlanır. Her öğrenim yılı başında program yeni versiyona geçer. Değişiklikler işlenir. Ders ile ilgili kurallar ve şubeler tanımlanır.

Seçmeli Derslerin Açılması¶

Seçmeli Derslerin açılabilemesi için en az 10 öğrencinin ilgili dersi seçmiş olması gerekmektedir. Ders seçimi sırasında dersi seçen öğrenci sayısının öğrenciye gösterilmesi süreci kolaylaştırabilir.

Sınıf Açma¶

Öğrenci azlığı nedeniyle sınıf teşkil edilemediği için normal ve ikinci öğretim birleştirilerek ders yapılabilir.

Ders Alma Biçimleri¶

İlk

Üstten

Devamsız Tekrar

Devamlı Tekrar

Yükseltme İçin

Ders Seçme¶

Öğrenciler sisteme giriş yapıp ders seçimlerini yapabilmeliler.

Dersler nottan kaldıysa devamsız tekrar, devamsızlıktan kaldıysa devamlı tekrar şeklinde alınır.

Yeni kayıtlar ders seçme ekranını pasif görürler.

Sistem, öğrencilerin ders seçimlerine yardımcı olmak için şu özelliklere sahip olmalıdır:

Öncelik, alt yarıyıllarda hiç alınmayan, devamsız veya başarısız olunan derslere verilmelidir.
Öğrenciler bölündükleri şubelere göre dersin şubelerini almaya zorlanabilir veya öğrenciler istedikleri şubeyi seçebilirler.
Alınabilecek toplam kredi minimum 30, maksimum 45 kredi olmalıdır.
Bu değerlere alt yıl dersleri dahildir.
Yan dal-çift dal dersleri hariçtir.
Ön şartlı dersler, şartları sağlanmıyorsa seçilememelidir.
Üst yarıyıl derslerinin seçilebilmesi için;
- Öğrencinin kayıt dondurma, uzaklaştırma cezası veya kayıt yenilemeyip dönem kaybetmemiş olmaması gerekir.
- Tüm alt yarıyıl derslerinden başarılı olmak zorunludur.
- Üst yarıyıl dersleri ile birlikte toplam 45 kredi aşılamaz.
- Üst yarıyıl dersleri 45 kredinin % 20’sini aşamaz.
Genel not ortalaması >= 3.00 olmalıdır.
- Danışmanın olumlu görüşü şarttır.
Daha önce başarılı olunan dersler not yükseltme amacıyla seçilebilir. Devam zorunluluğu olmadan alınan en son not geçerli olur. Ortalama hesaplarına ne olursa olsun en son alınan not dahil edilir.
Muaf olunan dersler seçilemezler.

Danışman onay sürecine kadar, öğrenci tarafından yukarıdaki kurallara göre seçilen dersler, danışman onay süreci içinde danışman tarafından kontrol edilir ve onaylanır. Bu onayın ardından ders seçme işlemi ilgili öğrenci için tamamlanmış olur.

Ders onayı yapıldığında öğrenciye her türlü ders o döneme ait şekilde yeni ders olarak tanımlanır. Dersler tekrar veya yerine bile olsa yeni bir ders kartı açılır. Öğrencinin geçmiş dönemdeki aynı ders durumu saklanır. Tekrar derslerin kredileri farklı olabilir. Bu değişiklik programda Bölüm Kurulu tarafından yapılmış olmalıdır.

Ders Ekleme-Çıkarma ve Mazeretli Ders Kaydı¶

Normal ders kaydı sürecinde ders kaydı yapmayan öğrencilerden mazereti olanlar bu süre içerisinde, yönetim kurulu onayıyla ders seçimini yapabilirler. Seçilen dersler dilekçe ile belirtilir. Fakülte öğrenci işleri gerekli dersleri ekler ve çıkarır. Bu işlem danışman onaylı gerçekleşir.

Danışman veya öğrenci ders seçimlerini değiştirmek için dilekçe verir. Bu değişiklikler önceki paragraftaki süreçle aynı şekilde yapılır.

Başka Bölümlerden Ders Alma¶

İlgili Bölüm veya Anabilim Dalı Kurulu uygun gördüğü hallerde başka fakülte ve bölümlerden dersler alınabilir. Ilgili dersler, ilgili programdaki kredi ve başarı şartları ile değerlendirilirler.

Program Değişikliği¶

Program değişiklikleri, Bölüm Kurulu’nun önerisi üzerine Yönetim Kurulu tarafından karara bağlanarak en geç Mayıs ayı içinde REKTÖRLÜĞE sunulur. SENATO onayı ile kesinleşir.

Program değişiklikleri gelecek yıllar için geçerli olur ve mevcut öğrencilerin derslerini ve ders bağımlılıklarını etkileyebilir. Kaldırılan veya yeni eklenen dersler sebebiyle mevcut öğrenciler için belirli dersler korunabilir. Bu sebeple program değişiklikleri versiyonlanmalı ve ilgili versiyona kayıt yaptıran öğrenciler için ders zorunlulukları ve bağımlılıklılar saklanmalıdır.

Ders Muafiyeti¶

Bir dersten muafiyet şartları şu şekildedir:

Programdan kaldırılan ve yerine herhangi bir ders konulmayan, herhangi bir dersten başarısız olan öğrenci, o dersten muaf sayılır.
İlgili dersin muafiyet sınavını başarmış olmak.

Not Girişi¶

Hoca notları kendi ekranından girer. Yayınla diyene kadar her türlü değişikliği yapabilir. Yayınla dedikten sonra, öğreciler notları görebilir, hoca artık hiçbir değişiklik yapamaz. Hoca tarafından yapılacak yanlışlık düzeltmeleri hocanın dilekçesi üzerine öğrenci işleri tarafından yapılır.

Öğrenci itirazları yine dilekçe üzerinden takip edilip, öğrenci işleri tarafından yapılır.

Sınav ve sonuçların yayınlanma tarihleri akabindeki süreçler için önemlidir.

Hoca dilekçesi üzerine tüm notlar yayından kaldırılıp, hocanın değerlendirilmesine açılabilir.

Büt ve final sonuçlarının girilmesi, öğrencinin harf notunun hesaplanmasına neden olur. Eğer büt ve final sonuçlarının değiştirilmesi sonucu harf değişikliklerinden kaynaklanan sonuçlar olursa bunlar elle düzeltilir. Geçme-kalma veya şartlı geçme vb..

% 10 İşlemleri

Değişim programları dışındaki
Disiplin cezası almamış
İkinci öğretimde okuyan öğrencilerden
Genel ortalaması 3’ten büyük
Başarısız dersi olmayan
Bulunduğu dönemde, sınıf ortalamasının en yüksek % 10’udur.

Bunların sadece sonraki dönem harçları birinci dönem gibi hesaplanır.

Onur Belgeleri¶

Bulunduğu dönemde ve sınıfta;
Başarısız dersi olmayan,
Genel ortalaması >= 3,5 ise yüksek onur,
Genel ortalaması >= 3 olan onur belgesi alır.

Harf Yeniden Hesaplama¶

Harf değişimlerini etkileyen her operasyonun ardından -sınav notlarının değişmesi- ona bağlı işlemler yeniden hesaplanır.

Şartlı geçiş
Geçme kalma
Onur belgesi
% 10 işlemleri

Mazeret Yönetimi¶

Mazeret bitiş tarihinden itibaren en geç bir hafta içinde bildirimde bulunulmalıdır. Bu süre içinde bildirilmeyen mazeret kabul edilmez. Ara sınav dışında başka sınavlar için mazeret kabul edilmez.

Mazeret öngörülen devam süresine dahil edilmez. Kaybedilen süre eğitim öğretim süresine eklenir.

Devamlılık Takibi¶

Devamın denetimi, dekanlıkça uygun görülen bir yöntemle yapılır. Devamsız öğrencilerin durumu genel sınavlardan önce ilgili öğretim elemanı tarafından ilân edi Hoca sisteme devamsızlıktan kaldı şekinde giriş yapar. Not F olur. Bir daha not girişi yapamaz. Bu işlem geriye de alınamaz. Sisteme bir bilgi girmez öğrenci dersin devam şartını yerine getirmiş sayılır. Bu işlemin geriye alınması dilekçe ile yönetim kuruluna gider. Fakülte Öğrenci işleri düzeltir.

Devamlılık ders için takip edilir. Hoca tarafından takip yapılır. Hoca sisteme devamsızlıktan kaldı şeklinde giriş yapar. Not F olur. Bir daha not girişi yapamaz. Bu işlem geriye de alınamaz. Sisteme bir bilgi girilmezse öğrenci dersin devam şartını yerine getirmiş sayılır. Bu işlemin geriye alınması dilekçe ile yönetim kuruluna gider. Fakülte öğrenci işleri düzeltir.

Mezuniyet¶

Bir öğrencinin kayıtlı olduğu programdan mezun olabilmesi için o programdaki bütün dersleri almış ve başarmış olması ve mezuniyet ağırlıklı not ortalamasının en az 2.00 olması gerekir. Mezuniyet tarihi, o sınav dönemindeki sınavın son günüdü̈r. Tarih elle girilebilir.

Ancak, bu tarihe kadar tek ders, staj, endüstriye dayalı öğretim, bitirme ödevi/tezi, arazi çalışması ve benzeri sebeplerle mezun olamayan öğrenciler; tek ders sınavında başarılı olduğu veya bu çalışmaların tamamlanarak kabul edildiği tarihte mezun olurlar.

Roller¶

Öğrenci
Danışman
Dekan
Fakülte Sekreteri
Fakülte Öğrenci İşleri Personeli
Fakülte Yönetim Kurulu Üyesi
Fakülte Yönetim Kurulu Başkanı
Anabilim Dalı Kurulu Üyesi
Anabilim Dalı Kurulu Başkanı
Fakülte Kurulu Üyesi
Fakülte Kurulu Başkanı
Bölüm Başkanı
Danışman

Yetkiler¶

Yetki Devri¶

Personeller kendine ait bazı yetkilerini başka bir personele geçici süreli olarak devredebilmelidir. Örneğin; dekanlar ve tıptaki hocalar not girişi yapmak istemiyorlar. Bu yüzden şifrelerini asistanlarıyla veya öğrenci işleriyle paylaşıyorlar. Bunu engellemek için akademisyen A dersi için not girme yetkisini X-Y tarihleri arasında asistanına devredebilmelidir.

Ekranlar¶

Not ve devamsızlık giriş ekranları
Toplu askerlik belgesi bastır
Toplu danışman atama
Toplu sınıf şubelendirme
Toplu sınav tarih girişi
Toplu not durum belgesi
Mezuniyet ekranı
Toplu Mernis ve AKS güncelleme.

Sistemden Beklenecek Raporlar¶

Genel durum ve işleyiş raporu (Fakülte faaliyet raporu)
Öğrenci sınıf listeleri
Dersi alan öğrenciler listesi.
Bölüm ders müfredatı

Sistem Tarafından Üretilecek Belgeler¶

Öğrenci belgesi
Askerlik durum belgesi (Sadece erkek öğrencilere verilebilir.)
Transkript (Dönemlik bölümler için dönemlik, yıllık bölümler için yıllık verilir.)
Not durum belgesi (Yıllık, dönemlik)
Geçici mezuniyet belgesi (Sadece mezun durumundaki öğrencilere verilebilir.)
Tömer belgesi (Sadece tömer kursunda kayıtlı öğrencilere verilebilir.)
Yabancı uyruklu öğrenci bilgi formu (Sadece yabancı uyruklu öğrencilere verilebilir.)
Diploma (Sadece mezun durumundaki öğrencilere verilebilir.)
- Diploma metni her bölüme göre değişebilir. Diploma metnin içine parametre geçirilmelidir.
Diploma Eki (Sadece mezun durumundaki öğrencilere verilebilir)

EBYS Entegrasyonu¶

YÖKSİS Kurum Ağacı¶

YÖKSİS tarafından sağlanan web servislerinden kurum ağacı çekilir. Sistemdeki bilgiler, bu servisten sağlananlarla güncellenir. Bu kurum ağacında okulun tüm akademik birimleri kendilerine verilen bir kod ile yer alır.

Ders Kopyalama¶

Önceki yıldan bölüm dersleri aktarılıp, değişiklikler işlenir.

Ders Tipleri¶

Hazırlık
Normal
Seçmeli
Staj
Tıp Staj
Entegre

Ders Durumları¶

Alıyor
Geçti
Kaldı
Devamsızlıktan Kaldı
Danışman Onayı Bekliyor
Muaf
Notsuz Muaf

Ders Alış Tipi¶

İlk
Üstten
Devamlı Tekrar
Yükseltme İçin
Devamsız Tekrar

Ders Dili¶

Türkçe

İngilizce...

Derslerin Dili Kuralları¶

Hazırlık sınıfından kalanlar, bölümdeki o dildeki dersleri alamazlar. Onun yerine ilgili dersin Türkçesini alırlar.

Personel ana bilim dalında yer alır, öğrenciler programda yer alırlar.
Bölümlerden öğrenci işlerine giden tum evraklardan örnek isteyelim.
- Diploma eki nasıl verilir?
Dış servislere erişim sorunu varsa uygulama uyarı yapsın.

Program örneği

http://konya.edu.tr/dosyalar/fakulte/ahmetkelesogluegitimfakultesi/derskodlari/ALMANCA.pdf

Bologna Ders Kartı

http://konya.edu.tr/bologna/goster/12198

İsteğe bağlı hazırlık sınıfı açılabilir. - Hazırlık sınıfının isteğe bağlı olup olmamasını saklamalıyız. Bu hazırlık sınıfında başarılı olamayan öğrencilerin ilişikleri kesilmez ve eğitimlerine devam ederler.

Öğretim dili tamamen veya kısmen yabancı dil olan programların hazırlık sınıfını iki yıl içinde başarı ile tamamlayamayan öğrencilerin programdan ilişiği kesilir. - İlişki kesme nedeni.

Öğretim dili tamamen veya kısmen yabancı dil olan programların hazırlık sınıfından ilişiği kesilen öğrenciler kendi yükseköğretim kurumlarında öğretim dili Türkçe olan eşdeğer bir programa kayıt yaptırabilirler. - Öğrenci geliş nedeni.

Ayrıca bu öğrenciler, kayıtlı olduğu yükseköğretim kurumunda eşdeğer program bulunmaması hâlinde talep etmeleri durumunda Ölçme, Seçme ve Yerleştirme Merkezi Başkanlığı tarafından bir defaya mahsus olmak üzere kayıt yaptırdığı yıl itibarıyla, öğrencinin üniversiteye giriş puanının, yerleştirileceği programa kayıt yaptırmak için aranan taban puanından düşük olmaması şartıyla öğretim dili Türkçe olan programlardan birine merkezî olarak yerleştirilebilirler. - Öğrenci geliş nedeni.

Sınav Hakkı¶

Azami sürelerini tamamlamış son sınıf öğrencilerine,

Başarısız oldukları bütün dersler için iki ek sınav hakkı verilir.
Bu sınavlar sonunda başarısız ders sayısını beş derse indirenlere bu beş ders için üç yarıyıl,
ek sınavları almadan beş derse kadar başarısız olan öğrencilere ise dört yarıyıl (sınıf geçme esasına göre öğretim yapılan kurumlarda iki öğretim yılı),
ek dersi almadan bir dersten başarısız olanlara ise öğrencilik hakkından yararlanmaksızın sınırsız,

başarısız oldukları dersin sınavlarına girme hakkı tanınır.

İzledikleri programdan mezun olmak için gerekli bütün derslerden geçer not aldıkları hâlde yönetmeliklerinde başarılı sayılabilmeleri için öngörülen not ortalamalarını sağlayamamaları sebebiyle ilişikleri kesilme durumuna gelen son dönem (sınıf geçme esasına göre öğretim yapılan kurumlarda son sınıf) öğrencilerine not ortalamalarını yükseltmek üzere diledikleri derslerden sınırsız sınav hakkı tanınır. Bunlardan uygulamalı, uygulaması olan ve daha önce alınmamış dersler dışındaki derslere devam şartı aranmaz. Açılacak sınavlara, üst üste veya aralıklı olarak toplam üç eğitim-öğretim yılı hiç girmeyen öğrenci, sınırsız sınav hakkından vazgeçmiş sayılır ve bu haktan yararlanamaz. Sınırsız hak kullanma durumunda olan öğrenciler sınava girdiği ders başına öğrenci katkı payını/öğrenim ücretini ödemeye devam ederler. Ancak bu öğrenciler, sınav hakkı dışındaki diğer öğrencilik haklarından yararlanamazlar. Açık öğretim öğrencileri, öğrencilik haklarından yararlanmak kaydı ile bu sürelerle kısıtlı değildir.

Derslere devam yükümlülüklerini yerine getirdikleri hâlde, yıl içi ve yıl sonu sınav yükümlülüklerini bu maddede belirtilen hükümlere uygun olarak yerine getiremedikleri için öğretim kurumları ile ilişiği kesilen hazırlık sınıfı ve birinci sınıfta en fazla bir dersten, ara sınıflarda ise en fazla üç dersten başarısız olan öğrencilere üç yıl içinde kullanacakları üç sınav hakkı, not ortalamasını tutturamadıkları için hazırlık sınıfı dâhil ara sınıflarda da sene kaybeden öğrencilere diledikleri üç dersten bir sınav hakkı verilir. Sınav hakkı verilenler, yıl içi veya yıl sonu sınavı olduğuna bakılmaksızın başvurmaları hâlinde üniversite veya yüksek teknoloji enstitülerinin her eğitim-öğretim yılı başında açacakları sınavlara alınırlar. Sınavların sonunda sorumlu oldukları tüm dersleri başaranların kayıtları yeniden yapılır ve öğrenimlerine kaldıkları yerden devam ederler. Bu durumda olan öğrencilerin sınavlara girdikleri süre, öğrenim süresinden sayılmaz. Bu sınavlara katılan öğrenciler öğrencilik haklarından hiçbir şekilde yararlanamazlar.

WorkFlow List¶

Derslerin Subelendirilmesi ve Öğretim Elemanlarının Atanması

Bu işlemlerin son tarihi ders kaydının başlamasından önceki cumadır. Eğer tamamlanmamışsa n zamanı öncesinden üst birime bilgi verilir.

Bölüm başkanı veya delege ettiği birisi kendi ekranındaki ilgili bağlantıya tıklayarak workflow başlatır.

Bölüm başkanı Programların ders listelerini indirir.

Her bir ders için ders koordinatörlerini belirler. Her bir ders için şube sayısını belirler Her bir şube için hoca atamasını yapar Her bir ders için öğrencilerin seçim biçimini belirler auto/manual Her bir şube için kontenjan belirler.

Tüm derslerin tamamlanmasının ardından öğrencilerin seçebilecekleri dersler öğrencilerin kayıtları altına gönderilir.

Eğer ders seçme biçimi otomatik ise;

Öğrenciler kontenjana göre şubelere dağıtılır.

Manuel ise;

Öğrenciler kendi seçimlerini kendileri yaparlar.

Öğrencilerin seçebilecekleri şubelerin listesi öğrencinin kaydına işlenir.

Öğretim Elamanı, Öğrenci İşleri ve diğer ilgililer bilgilendiririlir.

Work Flow tamamlanır.

UniTime Entegrasyonları¶

UniTime Nedir?¶

UniTime, bir araştırma sahası olan “akademik takvimleme problemleri”ni çözmek üzere geliştirilen, açık kaynaklı bir yazılım projesidir. Ulakbüs projesi kapsamında, bu alanda geliştirilmiş diğer projeler incelendiğinde, UniTime’ın daha kararlı bir proje olduğu ortaya çıkmıştır.

Aşağıdaki listede, incelenen diğer projeler ve algoritmalar listelenmektedir:

FET (Free Timetabling Software)

OptaPlanner

Making a Class Schedule Using a Genetic Algorithm

Greedy Algorithms

UniTime hakkında daha detaylı bilgiye aşağıdaki link üzerinden erişebilirsiniz:

http://www.unitime.org

Kavram Şeması¶

UniTime ve Ulakbüs yazılımı arasında veri akışını sağlayacak olan entegrasyonları yaparken, iki ayrı projenin farklı terminolojilerinden kaynaklanan bir harita dosyası ihtiyacı duyulmuştur.

Aşağıdaki tabloda Ulakbus modellerinin UniTime projesindeki kavramlara karşılıkları listelenmiştir:

Ulakbüs	UniTime
Building	Building
Campus	Campus
Ders	Course
Cogunlukla bir Ders nesnesine denk gelir	Instructional Offering
Egitimin organizasyonu (sadece teori, teori ve uygulama, vb)	Configuration
Donem	Academic Session
Okutman	Instructors
Ogrenci	Student
Personel	Staff
Program	Subject Area
Room	Room
RoomType	Room Type
Sinav	Exam
Unit (unit_type=”Bölüm”)	Department
Sube Ders icin biraraya gelmis ogrenci toplulugu Ders programinda zamanlanacak nesneler Subelerdir	Classes
?	Academic Classifications
?	Academic Areas
?	Majors
?	Minors
?	Student Accommodations
?	Curriculum Projection Rules
?	Last-like Enrollments

Entegrasyon Yöntemi¶

UniTime ve Ulakbüs yazılımı arasında veri akışını sağlayacak olan entegrasyonları yaparken, UniTime projesinin veri giriş/çıkış (data export import) imkan sağlayan XML arabirimi (Data Exchanger) kullanılmıştır. UniTime projesi ile birlikte sunulan örnek Data Exchanger XML dosyalarına aşağıdaki adresten ulaşmanız mümkündür:

https://github.com/UniTime/unitime/tree/master/Documentation/Interfaces/Examples

Entegrasyon kapsamında,

Akademik Dönem, Kampüs, Bina, Oda

Okutman, Öğrenci, Personel

Bölüm, Program, Ders, Öğrenci

Modellerine ait verilerin Ulakbüs üzerinden UniTime’a aktarılması hedeflenmektedir.

Verilerin aktarılmasının ardından hedeflenen işlevsellikler aşağıdaki kapsamdadır:

Güncel akademik dönem boyunca verilecek olan ders programlarının takvimlendirilmesi (ders programlarının varolan dersliklere ve tarih - saatlere dağılımının hesaplanması).
Güncel akademik dönem boyunca yapılacak olan sınavların takvimlendirilmesi (sınavların varolan dersliklere ve tarih - saatlere dağılımının hesaplanması).
Unitime üzerinde hesaplaması biten akademik ders takviminin Ulakbüs üzerinde bulunan DersProgrami modeline kayıt edilmesi.
Unitime üzerinde hesaplaması biten sınav takvimlerinin Ulakbüs üzerinde bulunan Sınav modeline kayıt edilmesi.

Önemli Not: Entegrasyon sırasında dışarıya aktarılan verinin, Ulakbüs üzerinde güncel olarak görünen akademik döneme ait olması hedeflenmiştir. Geçmiş dönemlere ait veriler dışarıya aktarılamaz.

Geçmiş dönemlere ait verilerin dışarıya aktarıma kısıtlanmasının nedeni; bu dönemlere ait işlemlerin Ulakbüs tarafında yeni döneme (güncel akademik döneme) aktarılarak işlenmesidir.

Örnek Entegrasyon¶

Bu örnekte UniTime üzerinde Department olarak adlandırılan ve Ulakbüs üzerinde Bölüm‘e denk düşen kayıtların aktarılması için gerekli XML dosyasının yaratılacağı bir fonksiyon örneklendirilmiştir. Örnek XML şemasına aşağıdaki adreten ulaşılabilir:

https://github.com/UniTime/unitime/blob/master/Documentation%2FInterfaces%2FExamples%2FdepartmentImport.xml

   class DepartmanAktar(Command):
       CMD_NAME = 'departman_aktar'
       HELP = 'Akademik bölüm listesi için UniTime XML import dosyası oluşturur.'
       PARAMS = []

       def run(self):
           import os
           import datetime
           from lxml import etree
           from ulakbus.models import Donem, Unit, Campus
           root_directory = os.path.dirname(os.path.abspath(__file__))

           # Güncel akademik dönemi seç
           term = Donem.objects.filter(guncel=True)[0]

           # Unit modeli üzerinden üniversite seç
           uni = Unit.objects.filter(parent_unit_no=0)[0].yoksis_no

           # Unit modeli üzerinden bölümleri seç
           units = Unit.objects.filter(unit_type='Bölüm')

           # Campus modeli üzerinden kampüs listesini al
           campuses = Campus.objects.filter()

           doc_type = '<!DOCTYPE departments PUBLIC "-//UniTime//DTD University Course Timetabling/EN" "http://www.unitime.org/interface/Department.dtd">'

           # XML ağacını oluştur (create XML tree)
           for campus in campuses:
               if campus:
                   root = etree.Element('departments', campus="%s" % uni, term="%s" % term.ad,
                                        year="%s" % term.baslangic_tarihi.year)
               for unit in units:
                   etree.SubElement(root, 'department', externalId="%s" % unit.key,
                                    abbreviation="%s" % unit.yoksis_no, name="%s" % unit.name,
                                    deptCode="%s" % unit.yoksis_no, allowEvents="true")

           # Stringi düzgünleştir (string prettify)
           s = etree.tostring(root, pretty_print=True, xml_declaration=True, encoding='UTF-8',
                              doctype="%s" % doc_type)

           # Güncel tarih-saat tabanlı export klasörü yarat
           current_date = datetime.datetime.now()
           directory_name = current_date.strftime('%d_%m_%Y_%H_%M_%S')
           export_directory = root_directory + '/bin/dphs/data_exchange/' + directory_name
           if not os.path.exists(export_directory):
               os.makedirs(export_directory)

           # Stringi dosyaya yazdır
           out_file = open(export_directory + '/departmentImport.xml', 'w+')
           out_file.write("%s" % s)
           print("Dosya %s dizini altina kayit edilmistir" % export_directory)


Oluşturulan XML dosyası, UniTime üzerinde **Administration** -> **Academic Sessions** -> **Data Exchange** menüsü ile ulaşabileceğiniz form aracığılığı ile sisteme import edilir.

Sistem Operatörleri¶

RIAK KV Kurulumu¶

Riak production ortamında en az 3 node, mümkünse 5 node çalışması önerilen dağıtık bir veritabanı sistemidir. Belli başlı özellikleri ve avantajları şu bağlantıdan okunabilir:

http://www.ulakbus.org/wiki/yazilim_tasarim_analizi_belgesi.html#riak

Bu dökümanda 5 node riak ve yük dengelemek için haproxy kurulum ve konfigürasyonu anlatılacaktır.

5 makinada üzerinde başka bir uygulama kurulmamış bulunan Ubuntu 14.10 (trusty) dağıtımının kurulu olduğu varsayılmıştır.

Kurulum için tavsiyemiz en az 2 CPU/VCPU ile 8 GB RAM bulunan sanal ya da gerçek sunucular kullanmanız yönündedir.

Bu kurulumu, geliştirme ortamınız için, 1 CPU ve 1 GB RAM ile 3 node olarak VirtualBox veya benzeri bir sanallaştırma ortamı üzerinde yapabilirsiniz.

Ön Hazırlıklar¶

Öncelikle her bir makinenin hostname ve IP adreslerinin düzgün şekilde ayarlandığından emin olalım. Bizim örneğimizde IP adresleri ve hostnamelerin şu şekilde olduğu kabul edilmiştir.

0.0.10    node1.example.org
0.0.11    node2.example.org
0.0.12    node3.example.org
0.0.13    node4.example.org
0.0.14    node5.example.org

Hostname ayarlamak için

# sudo hostnamectl set-hostname node1

komutunu kullanabilirsiniz.

Fully qualified domain name için de /etc/hosts dosyasına aşağıdaki gibi bir girdiyi eklememiz gerekmektedir.

# sudo vim /etc/hosts

...
10.0.0.10   node1.example.org   node1

İlgili değişikliği yaptıktan sonra

$ hostname -f

çıktısınının node1.example.org şeklinde alan adı ve hostname ile birlikte olduğundan emin oluyoruz.

Bu işlemleri yaptıktan sonra eğer sisteminizde yoksa bazı yardımcı paketlerin kurulması gereklidir:

apt-get install -y curl wget

Java Kurulumu¶

Riak Search için java gerekmektedir. Aşağıdaki komutlarla sistemimize Java kuruyoruz.

apt-get update -qq && apt-get install -y software-properties-common && \
     apt-add-repository ppa:webupd8team/java -y && apt-get update -qq && \
     echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && \
     apt-get install -y oracle-java8-installer

Kurulumu aşağıdaki komut ile doğrulayabiliriz:

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Riak Kurulumu¶

Riak kurulumu birkaç yol ile yapılabilir. Kaynak kod derlemek bunlardan birisidir. Fakat bu pek pratik değildir. Biz kaynak koddan kendimiz derleyerek elde ettiğimiz deb paketlerini kullanacağız. Packagecloud.io da tuttuğumuz paketleri sisteminize yüklemek için

$ curl -s https://packagecloud.io/install/repositories/zetaops/riak/script.deb.sh | sudo bash
$ apt-get install -y riak

komutlarını kullanabilirsiniz.

Riak’ın düzgün çalışabilmesi için dosya limitlerini değiştirmemiz gerekmektedir. Bunu kalıcı şekilde yapmak için

echo '* soft nofile 65536' >>   /etc/security/limits.conf
echo '* hard nofile 65536' >>   /etc/security/limits.conf
echo "session required        pam_limits.so" >> /etc/pam.d/common-session-noninteractive
echo "session required        pam_limits.so" >> /etc/pam.d/common-session

komutlarını kullanabilirsiniz.

Riak kurulumunu

$ sudo riak-admin status
Node is not running!

komutuyla doğrulayabilirsiniz.

Paketlerin kurulumunun ardından riak servisi başlamayabilir. Bu durumda yukarıdaki gibi Node is not running! çıktısı alırsınız. Servisi başlatmak için

$ sudo service riak start

komutunu kullanabilirsiniz. Bu komut hiçbir çıktı üretmeyebilir. Servisin başladığından emin olmak için yeniden

$ riak-admin status
1-minute stats for 'riak@127.0.0.1'
-------------------------------------------
connected_nodes : []
consistent_get_objsize_100 : 0
consistent_get_objsize_95 : 0
consistent_get_objsize_99 : 0
consistent_get_objsize_mean : 0
consistent_get_objsize_median : 0
....

komutunu çalıştırabiliriz. Eğer riak çalıştıysa, konfigürasyonuyla ilgili oldukça uzun bir çıktı üretecektir.

Riak’ın üzerinde çalışacağı sistemin performansı ile ilgili daha birçok parametre vardır. Oldukça detaylı bu ayarlar ayrı bir belgede ele alınacaktır. Başlangıç için bu düzenlemeler yeterlidir ve Riak kararlı şekilde çalışabilir.

Riak Konfigürasyonu¶

Riak standart bir kurulumda /etc/riak dizini altındaki riak.conf dosyası ile konfigüre edilir. Bazı özellikler ise hala eski tip konfigürasyon dosyaları olan advanaced.config ve app.config dosyaları ile yapılır. Riak başlama esnasında bu dosyalara bakıp validasyon yapar ve tek bir nihayi konfigürasyon üretir. Dolayısı ile bu dosyalarda yapılacak her değişikliğin ardından riak servisi yeniden başlatılmalıdır.

sudo service riak restart

komutuyla Ubuntu üzerinde Riak servisini yeniden başlatabilirsiniz.

Konfigürasyon için ilk adım nodename değiştirmektir. riak.conf içindeki nodename = riak@127.0.0.1 değerini nodename = riak@10.0.0.10 şeklinde makine IP adresi ile değiştirmek gerekir. Bunu bir editör yardımı ile yapabilirsiniz. Ya da basitçe aşağıdaki komut ile de ilgili değişikliği yapabilirsiniz.

sed -i.bak "s/riak@127.0.0.1/riak@10.0.0.10/" /etc/riak/riak.conf

Riak servislerinin bağlandığı IP adreslerini de düzenlememiz gerekmektedir. Farklı bir hosttan haproxy ile erişeceğimiz bu servislerin bağlandığı IP adresleri host makinenin IP adresi 10.0.0.10 veya 0.0.0.0 şeklinde ayarlanabilir. Bu amaçla riak.conf dosyasındaki

listener.http.internal = 127.0.0.1:8098
listener.protobuf.internal = 0.0.0.0:8087

değerleri

listener.http.internal = 10.0.0.10:8098
listener.protobuf.internal = 10.0.0.10:8087

şeklinde değiştirilmelidir.

Riak Search için yine riak.conf dosyasındaki search = off değerini search=on şeklinde değiştirmemiz gereklidir.

Bu değişikliklerin ardından riak servisi yeniden başlatılmalıdır.

Buraya kadar yapılan işlemler 5 node için tekrar edilmelidir.

Cluster Oluşturma¶

5 node düzgün bir şekilde yapılandırıldıktan sonra Riak nodelar cluster olmak için hazırdır. Cluster oluşturmak için bir node seçilmeli ve diğer nodelardan bu node’a clustera katılma isteği gönderilmelidir.

Birinci node’u (10.0.0.10) seçtiğimizi varsayarsak diğer nodelarda sırayla

riak-admin cluster join riak@10.0.0.10

komutu çalıştırılır.

Diğer 4 node’da bu komut sırayla çalıştırılır. Cluster’a katılma talebi başarıyla gerçekleştiyse şöyle bir mesaj ile karşılaşırız:

Success: staged join request for 'riak@10.0.0.11' to 'riak@10.0.0.10'

Bütün nodlarda başarıyla cluster katılım talebini yaptıktan sonra, herhangi bir node’da sırasıyla şu komutlar çalıştırılarak yeni cluster değişiklikleri uygulanır:

riak-admin cluster plan
riak-admin cluster commit

Birinci komut cluster ile ilgili yeni değişiklikleri bize gösterir. Bu komutun çıktısı aşağıdaki gibidir:

=============================== Staged Changes ================================
Action         Nodes(s)
-------------------------------------------------------------------------------
join           'riak@10.0.0.10'
join           'riak@10.0.0.10'
join           'riak@10.0.0.10'
join           'riak@10.0.0.10'
-------------------------------------------------------------------------------


NOTE: Applying these changes will result in 1 cluster transition

###############################################################################
                         After cluster transition 1/1
###############################################################################

================================= Membership ==================================
Status     Ring    Pending    Node
-------------------------------------------------------------------------------
valid     100.0%     20.3%    'riak@10.0.0.10'
valid       0.0%     20.3%    'riak@10.0.0.11'
valid       0.0%     20.3%    'riak@10.0.0.12'
valid       0.0%     20.3%    'riak@10.0.0.13'
valid       0.0%     18.8%    'riak@10.0.0.14'
-------------------------------------------------------------------------------
Valid:5 / Leaving:0 / Exiting:0 / Joining:0 / Down:0

Transfers resulting from cluster changes: 51
  12 transfers from 'riak@10.0.0.10' to 'riak@10.0.0.11'
  13 transfers from 'riak@10.0.0.10' to 'riak@10.0.0.12'
  13 transfers from 'riak@10.0.0.10' to 'riak@10.0.0.13'
  13 transfers from 'riak@10.0.0.10' to 'riak@10.0.0.14'

Bu tablolar bize cluster değişikliğinin ardından ring dağılımını ve clusterin yeni üyelerini gösterir.

Sonuncu commit komutuyla da bu değişikler aktif hale getirilir.

Kullanıcılar¶

Projemiz şu an geliştiriciler ve sistem yöneticileri tarafından test edilmektedir. Şu anda kullanıcılarımız için bir belge bulunmamaktadır. Ulakbüs beta kullanım açıldığında, kullanıcı belgelerini de paylaşmaya başlayacağız.

Geliştirmeye Yeni Başlayanlar¶

Yeni geliştiriciler, ilk olarak Geliştirme Ortamının Kurulumu belgesiyle başlayabilirler. Bu belgede geliştirme ortamının Vagrant üzerinde kurulması detaylı şekilde anlatılmaktadır.

Geliştirmeye başlamadan önce geliştiriciler için hazırladığımız Yazılım Tasarım Analizi Belgesi belgesi, sistemin genel görünüşü ve tek tek bileşenleri hakkında detaylı bilgiler içermektedir ve geliştirme sürecinin daha hızlı anlaşılmasına yardımcı olacaktır.

ULAKBUS, iş akışı temelli bir web çatısı olan ZEngine üzerine kuruludur. Bu sebeple ZEngine ile İş Akışı Temelli Uygulama Geliştirme başlıklı belge, iş akışı kavramları ile tanışmak ve web çatısının genel özellikleri hakkında temel bilgiler için oldukça faydalı olacaktır.

Ulakbüs’ü Geliştirelim belgesi ise örnek bir uygulama içermektedir. Web çatısınının üzerine ULAKBUS kodunun nasıl yerleştiği, iş akışı diyagramının nasıl çizildiği, modellerin nasıl tanımlandığı, iş akışı adımlarına karşılık gelen view / task veya servislerin nasıl yazıldığı hakkında açıklamalar ve örnek kodlar içermektedir.

Geliştirme yaparken ilgileneceğimiz diğer önemli bir konu ise arka ve önuç ilişkisinin kavranmasıdır. Bu ilişkiyi ve önucun nasıl çalıştığını tüm detayları ile ULAKBUS UI–API İlişkisi belgesinde bulabilirsiniz.

Diğer yardımcı belgeler:

Komut Satırı Yönetim Aracı

Komut satırı yönetim aracı, ULAKBÜS uygulamasının hem yönetimi hem de geliştirilmesi için basit ve etkili bir arayüzdür. Komut satırından veritabanı yönetimi, model şema göçü, fake data üretimi, veri aktarımı ve daha birçok işlem kolaylıkla yapılabilmektedir.
Zato

Zato, ULAKBUS projesinin temel bileşenlerinden birisidir. Bu belge hem Zato hakkında hem de genel olarak ESB (Kurumsal Veriyolu) / SOA (Servis Temelli Uygulama) kavramları hakkında bilgi içerir.
Zato İpuçları

Zato’nun yönetimi ile ilgili ipuçları içerir.

Bu belgelere ek olarak, geliştirme faaliyetinizi toplulukla paylaşmak ve ULAKBUS depolarına göndermek isterseniz GitHub ve Git iş akışımızı detaylı şekilde tarif ettiğimiz Ulakbus Depolarına Katkı Yapmak belgemize göz atabilirsiniz.

Eğer bir sorunla karşılaşırsanız, destek sayfamızda yer alan kanallardan destek alabilirsiniz. Destek için iletişim kurmadan önce lütfen sorununuzun ne olduğunu açık ve sarih olarak bildirmeniz gerektiğini unutmayınız. “- Bu çalışmıyor” şeklindeki sorularınıza alabileceğiniz en iyi cevap sessizlik olacaktır.

Nasıl soru sorulacağını akıllıca soru sorma yolları belgesinden öğrenebilirsiniz.

Kolay gelsin o/