TERJEMAHAN BUKU

Artificial Intelligence Techniques in Power Systems

KONTROL CERDAS SISTEM KELISTRIKAN

Kelas A
Oleh :
Kelompok 3

Rosi Indra Pratama (141910201017)

Aldianto Wahyu Ramadhan (141910201019)
Mas Jodi Adwitya Pratama (141910201020)

JURUSAN TEKNIK ELEKTRO STRATA 1

FAKULTAS TEKNIK
UNIVERSITAS JEMBER
2017
 BAB 3
PERANCANGAN ORIENTASI OBJEK DAN IMPLEMENTASI SOFTWARE
ANALISIS SISTEM TENAGA
N.B.P. Phillips, J.O. Gann and M.R. Irving

3.1 Pendahuluan
Aplikasi besar dapat dibagi menjadi tiga sub-proses utama:
Desain
Pemrograman
Retensi data
Kecenderungan saat ini terhadap metode orientasi objek berdampak pada masing-masing
bidang berikut ini: metodologi desain tradisional seperti analisis 'top-down' memberi jalan
kepada analisis orientasi objek, bahasa pemrograman konvensional hingga bahasa
pemrograman orientasi objek, dan basis data relasional ke orientasi objek atau diperpanjang
database relasional. Bab ini menyelidiki masalah teknis dan arsitektural yang terlibat dalam
membuat transferensi ini serta keuntungan yang dapat diperoleh melalui proses ini.
Selama beberapa tahun terakhir ini semakin jelas bahwa solusi komputer sistem tenaga
yang saat ini ada tidak memadai. Kebutuhan bisnis hari ini menuntut model data yang
kompleks, akses cepat dan berbagi informasi di seluruh bisnis. Bahasa perangkat lunak
orientasi objek, database dan teknik pengembangan sekarang dipandang sebagai solusi yang
mungkin untuk masalah ini dan banyak penelitian [1-4] telah dikhususkan untuk penerapan
metodologi ini ke analisis dan pengendalian sistem tenaga.

3.1.1 Sistem Arsitektur SIMIAN.

Arsitektur SIMIAN (SIMulation Image and ANimation) adalah kerangka orientasi objek
yang dirancang khusus untuk memungkinkan sharing data antara proses bisnis yang berbeda
dalam lingkungan data yang kompleks.

3.1.2 Bab Struktur

Bab ini menjelaskan pekerjaan penelitian yang dilakukan di Institut Teknologi Tenaga Kerja
Brunei menjadi manfaat dari desain orientasi objek untuk perangkat lunak pemodelan sistem
tenaga. Bab ini pertama kali menyelidiki konsep desain orientasi objek serta teknologi yang
tersedia untuk menerapkan metodologi tersebut. Setelah ini, model berorientasi objek yang
dibuat selama penelitian ini rinci dan penilaian terhadap kekuatan dan kelemahannya disajikan.

3.2 Orientasi Objek

3.2.1 Prinsip Orientasi Objek
Selama beberapa tahun terakhir banyak pekerjaan telah dilakukan pada pengembangan dan
pemrograman perangkat lunak orientasi objek. Teknik ini memungkinkan perancang untuk
lebih dekat menghubungkan objek dunia nyata yang ia inginkan untuk model ke rekan
perangkat lunak mereka. Dengan membiarkan desain yang lebih intuitif, siklus desain harus
sangat difasilitasi.
Konsep utama dari model orientasi objek meliputi :
Objek : Setiap entitas dunia nyata dimodelkan sebagai objek.
Enkapsulasi : Setiap objek tidak hanya berisi data, namun mencakup metode, dimana
dunia luar, seperti yang dirasakan oleh objek, dapat memanipulasi data yang terdapat
dalam objek. Metode ini memberikan antarmuka yang ketat, secara efektif mematikan
akses langsung ke data objek.
Kelas : Semua objek yang berbagi seperangkat metode dan data yang sama
dikelompokkan bersama di kelas.
Pewarisan : Kelas dapat didefinisikan sebagai subkelas dari sejumlah kelas lainnya,
sehingga mewarisi data dan metode kelas-kelas ini: misalnya, sebuah hotel adalah
sub-kelas bangunan, dan kapal pesiar dapat didefinisikan sebagai sub Kelas dari jenis
hotel dan kapal.
Overloading, overriding and late binding : Metode fungsional ini memungkinkan satu
nama operasi fungsi untuk dikaitkan dengan sejumlah fungsi yang berbeda, sehingga
sistem dapat menentukan metode yang benar untuk dipanggil dalam konteks apa pun.
Dari tiga metode untuk mencapai polimorfisme fungsional ini, dua yang pertama
diselesaikan pada waktu kompilasi, sementara yang terakhir diselesaikan 'terlambat',
mis. selama run-time
Bagian berikut menyelidiki penerapan prinsip-prinsip model orientasi objek inti ke tiga bidang
perancangan, pemrograman dan retensi data dalam aplikasi kompleks yang besar.
3.2.2 Desain Orientasi Objek
Paradigma disain konvensional, non-berorientasi objek berfokus pada prosedur yang
dibutuhkan untuk menyelesaikan tugas tertentu. Setelah 5 referensi, metode seperti itu
mengikuti paradigma:
Pilih prosedur yang anda mau;
gunakan algoritma terbaik yang dapat Anda temukan.

Metodologi ini ditandai dalam proses desain modular 'top-down': perancang pertama-tama
menghasilkan spesifikasi keseluruhan proses, dan kemudian secara progresif membagi desain
menjadi sub-proses komponen. Misalnya sebuah proses untuk membaca sebuah file bisa dibagi
dua seperti yang ditunjukkan pada Gambar 3.1. Setiap lapisan dalam diagram menggambarkan
spesifikasi komponen desain yang lebih rinci yang dibutuhkan untuk membangun induk
(tingkat yang lebih tinggi). Misalnya, membaca data membutuhkan dua sub-proses 'Read Data
Element' dan 'Check End of File'. Tanda panah menggambarkan aliran data antara proses, dan
proses apapun hanya dapat terhubung ke orang tua langsung atau anak-anaknya sendiri.
Misalnya 'Close File' mungkin tidak berkomunikasi dengan proses 'Check End of File'.

\
Gambar 3.1 Filosofi Desain Modular Top Down

Metode analisis ini menghasilkan definisi fungsional yang modular dengan rapi.
Namun, mekanisme analisis top down tidak menginstruksikan perancang pada bentuk
data yang dilewatkan di antara blok fungsional. Ini harus berasal dari tempat lain - fungsi
'Elemen Baca Elemen' tidak mengatakan apakah data ada dalam struktur data agregat ASCII,
heksadesimal atau majemuk tertentu.
Bahkan dalam metode analisis yang lebih terstruktur, seperti VDM [6], penekanan dalam
desain adalah pada pra dan pasca-syarat fungsi. Namun, analisis terperinci dan terstruktur ini
menentukan data keadaan sebuah proses. Untuk melanjutkan contoh membaca file, fungsi
'Baca Data' bisa memiliki pra / post-syarat berikut ini:

Ini menyiratkan bahwa proses tersebut harus memiliki penanda data akhir-of-file sebagai
bagian dari informasi negara untuk proses tersebut. Namun, dorongan utama analisis masih
bergantung pada rancangan blok fungsional, dengan data merupakan produk dari analisis ini.

3.2.3 Analisis Orientasi Objek

Analisis orientasi objek kontras menekankan fungsi dan data. Perancang berkembang dengan
menghasilkan daftar 'objek' yang akan dibutuhkan untuk aplikasi, dan kemudian setiap objek
dianalisis untuk menghasilkan daftar fungsi yang mungkin menjadi objek objek.
Sejumlah penulis [7-10] telah meresmikan proses perancangan ini, dua yang terakhir
mengambil rute serupa yang dijelaskan di bawah ini.
Proses perancangan dilakukan setelah Referensi 9 dalam langkah-langkah berikut:
Mengembangkan sebuah deskripsi bahasa alami dari sebuah masalah.
Membangun model objek bersama dengan kamus data kelas, relasi dan atribut.
Membangun model dinamis dari sistem.
Membangun model fungsional dari sistem.
Masing-masing tindakan ini, yang pertama, mencakup aspek yang berbeda dari sistem akhir.
Model objek mendefinisikan kelas dan hubungan antara objek yang berbeda serta informasi
keadaan yang harus dimiliki masing-masing kelas. Model dinamis mendefinisikan perilaku
kelas dan mengizinkan transisi negara, sedangkan model fungsional menunjukkan perilaku
sistem secara keseluruhan.

3.2.3.1 Pernyataan Masalah

Seperti dalam semua mekanisme analisis, ruang lingkup aplikasi harus didefinisikan.
Spesifikasi bahasa Inggris ini berfungsi sebagai titik awal untuk analisis. Dalam desain
orientasi objek, spesifikasi sederhana ini bahkan bisa sangat berguna dalam menentukan kelas
secara langsung yang akan dibutuhkan untuk membangun aplikasi. Karena kelas akan dipilih
untuk mencerminkan entitas dunia nyata, kata benda dalam spesifikasi membentuk rangkaian
kelas super yang dibutuhkan, sementara verba tersebut menyediakan sub-set metode yang
diperlukan dalam penerapan kelas atau ' tugas 'kelas
Misalnya diberi sebuah pernyataan masalah :
Buatlah sebuah model perangkat lunak untuk mewakili jaringan distribusi listrik. Model
tersebut harus mencakup pembangkit listrik secara langsung seperti line dan sakelar, dan
objek tak langsung / objek kontrol yang terhubung secara tidak langsung seperti stepper,
hubungan tanah dan servos. Model yang dihasilkan akan menggabungkan konektivitas antar
item dan memiliki tampilan grafis untuk menampilkan jaringan ke pengguna. Model harus
memungkinkan pengguna untuk mengubah jaringan setiap saat, secara otomatis memperbarui
kedua konektivitas dan tampilan grafis. Sistem harus dirancang dalam arsitektur terbuka
yang memungkinkan aplikasi lain mengakses jaringan dan data industri melalui antarmuka
yang sama.
Mengumpulkan kata benda berhuruf tebal menghasilkan daftar jenis kelas potensial berikut ini:
Tabel 3.1 Contoh Kelas Kandidat
Jaringan Distribusi Listrik Tenaga Listrik Pabrik
Line Sakelar
Objek Tak Terhubung secara Tidak
Objek Kontrol
Langsung
Stepper Hubungan Tanah
Servo Tampilan Grafis
Pengguna Model
Arsitektur Terbuka Aplikasi
Antarmuka Biasa

Beberapa kata benda ini, seperti Open Architecture, mungkin akan tidak ditampilkan pada
daftar.
Demikian juga kata kerja di setiap kalimat menghasilkan sejumlah fungsi yang
dibutuhkan. Misalnya, dalam kasus 'Jaringan Distribusi Ketenagalistrikan' yang diusulkan, kita
memiliki fungsi anggota kandidat sebagai berikut:
Merubah
Pembaruan (grafis / tampilan)
Sertakan (item pabrik)
Tampilan
Teknik sederhana inilah yang menghasilkan titik awal untuk pembangunan objek kelas dalam
sebuah aplikasi.

3.2.3.2 Model Objek

Setelah menghasilkan daftar sementara dari kelas yang dibutuhkan untuk aplikasi kelas lebih
lanjut dapat dibangun untuk merangkum kesamaan antara kelas sambil menambahkan kelas
lebih lanjut yang tidak disertakan dalam analisis pertama berlalu.
Melanjutkan contoh sebelumnya, kita dapat menambahkan item tanaman yang
diabaikan seperti Generator, Infeed, Junction, Transformer dll., Sementara juga menambahkan
kelas abstrak untuk mengelompokkan akar kelas bersama: Generator dan Umpan merupakan
sumber tenaga listrik; Kabel, Lines dan Transformer Windings semua komponen koneksi
sederhana. Kelas umum mewarisi fungsionalitas dan data dari kelas akar yang sama.
Hal tersebut merupkan poindalam analisis sifat dari setiap kelas menjadi suatu
kepentingan. Kelas tersebut membagikan atribut yang sama ia menjadi kandidat alami untuk
berbagi kelas akar. Namun, hanya karena dua benda seperti Mobil dan Wortel keduanya
berbagi atribut ' Harga Tentu, itu tidak berarti tentu bahwa mereka harus berbagi akar yang
sama, tapi tergantung pada aplikasi dan atribut lainnya.
Penetapan warisan hirarki adalah dari inti orientasi objek. Namun, perawatan harus
dilakukan untuk tidak menggunakan warisan berlebihan. Objek juga dapat mencakup yang lain
serta mewarisi dari mereka. Kedua, konvensional, pendekatan menghasilkan kelas menjadi
agregat komposisi kelas lain secara struktur konvensional atau di non orientasi objek. Aturan
umum untuk penetapan warisan hirarki sebagai lawan yang secara hubungan dapat dinyatakan
sebagai :
Jika kedua kelas memiliki hubungan CIS A maka mereka terkait melalui warisan.
Jika dua kelas memiliki hubungan 'HAS A', maka satu adalah agregat komponen
lain.
Beberapa pasangan kelas bisa sulit dikategorikan, dan ini sering terjadi hubungan yang dapat
memberikan kedua masalah konstruksi dan pemeliharaan nantinya. Misalnya, bagaimana
kaitan Vektor dan Matriks? Dalam hal ini seseorang dapat menentukan keduanya dengan dua
cara:
Vektor IS merupakan jenis dari Matriks (hanya dengan dimensi tunggal).
Matriks HAS merupakan serangkaian varian vektor co-variant atau contra-variant.
Either way akan bekerja untuk matriks dua dimensi, tapi jika di kemudian hari matriks
multidimensi dipertimbangkan, metode pertama menjadi lebih baik.
Terakhir, hubungan antara kelas dievaluasi; Junction dapat dihubungkan ke satu atau
lebih objek jaringan lainnya, Steppers dapat dihubungkan ke Transformer Windings dll.
Hasil analisis ini menghasilkan model objek, yang menggambarkan kelas, atribut dan
hubungan kelas mereka. Ini digambarkan dalam diagram hubungan entitas yang diperluas yang
diilustrasikan untuk sebagian contoh sebelumnya pada Gambar 3.2.

3.2.3.3 Model Dinamis

Model dinamis mengilustrasikan metode yang dapat dilakukan setiap objek. Metode ini
membentuk antarmuka fungsional eksternal ke objek. Mereka juga mulai menggambarkan
dependensi antar kelas. Misalnya menampilkan jaringan pada tampilan grafis yang menyatakan
bahwa tampilan dan jaringan grafis dalam beberapa hal terkait. Asosiasi semacam itu harus
dijaga seminimal mungkin, untuk mengurangi risiko kelas menjadi saling bergantung satu
sama lain.
Interdependensi antara kelas dapat dikurangi jika kelas tertentu hanya diperbolehkan
untuk berkomunikasi dengan kelas tertentu lainnya. Lieberherr & Holland mengusulkan
seperangkat aturan saat merancang metode kelas yang mereka namai 'hukum Demeter'. Hukum
ini, yang dinyatakan dalam versi ketat atau kelas, secara efektif mendefinisikan kelas mana
yang dapat berkomunikasi dengan kelas tertentu (sebut metode). Ini tidak membatasi
penggunaan teknik berorientasi objek karena program orientasi objek yang dirancang dengan
buruk dapat diubah menjadi bentuk yang baik yang mematuhi hukum Demeter.
Versi C ++ yang ketat dari hukum Demeter dapat dinyatakan sebagai:

Kepatuhan terhadap hukum Demeter harus mengurangi jumlah ketergantungan antar kelas dan
membuat penggunaan kembali kode lebih banyak dalam sejumlah aplikasi.
 Mesin negara berhingga yang telah selesai digunakan untuk menggambarkan hubungan
ini. Mealy kondisi mesin dan Harel statechart notasi [10] keduanya digunakan oleh Rumbaugh
untuk menangkap metode yang mungkin memiliki kelas.

3.2.3.4 Model Fungsional

Model fungsional menggambarkan perilaku sistem, dan analisis Rumbaugh diwakili melalui
diagram alir data. Ini mewakili, seperti namanya, arus data antar fungsi. Meskipun tidak
menunjukkan urutan fungsi yang harus dijalankan untuk mencapai hasilnya, namun tidak
memberikan informasi yang berharga mengenai pesan yang disampaikan di antara semua
fungsi model.

3.2.4 Kesimpulan Metodologi Orientasi Objek

Meskipun hanya satu metodologi desain berorientasi objek yang telah dibahas, prinsip-prinsip
proses perancangannya bersifat generik. Pergeseran dalam proses desain jauh dari model
fungsional yang ketat ke model berorientasi objek harus memberikan sejumlah manfaat bagi
perancang.
Konsep inti memberdayakan perancang sistem berorientasi obyek dengan sejumlah
manfaat.
Gambar 3.2 Contoh model objek OMT untuk sistem tenaga sederhana
3.2.4.1 Kemudahan Desain
Keuntungan pertama, disinggung di Bagian 3.1, adalah lebih intuitif untuk disain dalam
kerangka kerja berorientasi objek. Metode iterasi pertama yang sederhana untuk menentukan
kelas yang dibutuhkan untuk sebuah aplikasi dapat dengan mudah menuliskan spesifikasi
program; kata benda dalam spesifikasi membentuk rangkaian kelas super yang dibutuhkan,
sementara verba menyediakan sub-set metode yang diperlukan dalam pelaksanaan kelas.

3.2.4.2 Modularitas
Prinsip enkapsulasi menghasilkan antarmuka publik ke dunia luar untuk setiap objek.
Pengguna objek tidak perlu tahu dan dipisahkan dari implementasi internal objek. Dengan
demikian, perubahan pada data internal objek diisolasi ke objek sendiri, dan tidak ada
perubahan eksternal yang perlu dilakukan.

3.2.4.3 Ekstensibilitas
Jika model perlu diperluas melalui penambahan kelas lebih lanjut, penggunaan pewarisan
seringkali dapat mengurangi beban kerja yang dibutuhkan. Sebagai contoh, diberi model
analisis sistem tenaga yang berisi kelas Generator, penambahan kelas baru - Coal-Fired
Generator - tidak memerlukan usaha besar: perancang hanya menciptakannya sebagai subkelas
metode spesifik Generator dan overloads di kelas baru Sebagian besar kode tidak harus
diimplementasikan kembali.

3.2.4.4 Penggunaan Kode Kembali

Karena kodenya bersifat modular dan extensible, maka akan lebih mudah untuk digunakan
kembali. Pustaka kelas mandiri dapat dibangun untuk melakukan fungsi crossapplication yang
umum digunakan (Message Handlers, Generic List classes dll.). Kelas-kelas ini kemudian
dapat dengan mudah 'dimasukkan ke dalam' ke aplikasi baru dengan mudah.

3.2.5 Kerugian dari Desain Orientasi Objek

3.2.5.1 Kinerja
Fleksibilitas prinsip-prinsip desain orientasi objek memungkinkan perancang untuk
menghasilkan aplikasi lebih cepat. Namun, sejumlah konsep model inti menghasilkan kinerja
run-time yang buruk daripada yang dapat dicapai dengan program khusus.
Enkapsulasi mensyaratkan bahwa semua perintah untuk memanipulasi keadaan objek
(data yang terdapat dalam suatu objek) dikirim ke metode antarmuka, yang kemudian
 mengubah keadaan objek. Ini menghasilkan panggilan fungsional tambahan yang
meningkatkan overhead panggilan program. Beberapa bahasa pemrograman
berorientasi objek, C ++ misalnya, menyediakan fungsionalitas untuk mengurangi
overhead ini (inline function calling).
Bila menggunakan metode pengikatan akhir, metode yang tepat untuk digunakan
diselesaikan pada saat runtime, yang memerlukan pemrosesan substansial dalam pohon
warisan besar.
Tambahan kinerja yang tepat sangat bervariasi, tergantung pada sejumlah faktor: bahasa
pemrograman, bentuk aplikasi, dan secara inheren disain. Beberapa penulis [11,12]
menyarankan bahwa dalam aplikasi tertentu, jumlah overhead tambahan antara 30 dan 50%
dari program konvensional. Namun, yang lain menyarankan bahwa peningkatan disain karena
striktur inheren dari metodologi orientasi objek sebenarnya dapat menghasilkan program yang
lebih efisien.

3.3 Arsitektur SIMIAN

Arsitektur SIMIAN (SIMulation Image and ANimation) adalah kerangka orientasi objek
yang dirancang khusus untuk memungkinkan sharing data antara proses bisnis yang berbeda
dalam lingkungan data yang kompleks.
Arsitektur SIMIAN terdiri dari lima komponen utama.
Protokol komunikasi objek terdistribusi
Sistem manajemen database obyek-orientasi (OODBMS)
Hirarki kelas arsitektur umum
Hirarki kelas aplikasi yang berasal dari kelas umum
Sejumlah 'aplikasi'
Inti arsitektur SIMIAN adalah konsep objek terdistribusi dan CORBA (Common Object
Request Broker Architecture) standar komuniksi. Konsep ini, didukung pada sebagian besar
platform utama (Microsoft's OLE & DCOM, Apple & IBM OpenDoc) memungkinkan sebuah
objek dalam satu proses untuk mengeksekusi metode umum objek dalam proses lain tanpa
memerlukan pengetahuan yang pasti tentang di mana atau bagaimana objek penerima
diimplementasikan sistem berbasis integrasi. Dengan demikian pendekatan ini difasilitasi
disamping kemampuan untuk mendistribusikan beban pemrosesan.
Setiap 'objek' aplikasi terdiri dari opsional, antarmuka pengguna grafis dan server 'objek'
yang berinteraksi dengan satu atau lebih datastore dan (opsional) pengguna, sementara
pemberitahuan aplikasi 'yang tertarik' diubah ke model data. Pesan dikirim dari objek kelas
server ke objek pengendali event di bawah kondisi yang telah ditentukan, di mana mereka
dikirim secara asynchronous, ke aplikasi yang telah mendaftarkan minat sebelumnya pada
elemen data spesifik. Dengan mekanisme ini, hasil dari satu objek aplikasi mungkin diperbarui
secara otomatis dalam aplikasi lain. Situasi ini diilustrasikan pada Gambar 3.3.

Gambar 3.3 Gambaran Arsitektur SIMIAN

BIPS pada awalnya menerapkan arsitektur SIMIAN di C ++, dengan menggunakan database
ObjectStore untuk menyediakan repositori data pusat yang dibutuhkan, dan CORBA (Common
Object Request Broker Architecture) standar komunikasi. Menggunakan dari database
berorientasi objek dalam industri sistem tenaga harus mengarah pada peningkatan kinerja
sambil menangani data yang semakin kompleks dan ekstensif set. Selain itu kompleksitas objek
itu sendiri sangat disederhanakan mengadopsi desain dan implementasi orientasi objek.
3.3.1 Hirarki Gambaran dari Kelas SIMIAN
Bagian atas hierarki kelas SIMIA mendefinisikan fungsionalitas dasar yang umum
untuk semua objek di dalam sistem. Setiap lapisan didefinisikan untuk melakukan fungsi
tertentu (Gambar 3.4).

Gambar 3.4 Hirarki Kelas SIMIAN

Superclass abstrak, perilaku dinamis dan kelompok kelas pesan membentuk kelas inti
arsitektur, terlepas dari penerapannya. Kelompok kelas selanjutnya bergantung pada aplikasi.
Gambar 3.5 hanya menggambarkan topologi jaringan dan hierarki kelas model, meskipun
dalam aplikasi lain, seperti yang diperlukan untuk mengintegrasikan sistem SCADA ke dalam
arsitektur, kelas hierarki tersebut akan ditempatkan pada posisi hierarki paralel di dalam
diagram dan disajikan dari yang terpisah. (meskipun dihubungkan melalui CORBA) database
obyek-orientasi.
Bagian berikut menjelaskan implementasi komponen-komponen dari arsitektur SIMIAN
dan implikasinya terhadap aplikasi dan algoritma.

3.3.2 Kelas Dasar Arsitektur SIMIAN

Gambar 3.5 menggambarkan, mengikuti notasi OMT, hirarki kelas untuk hierarki kelas
dasar SIMIAN, menggabungkan lapisan perilaku dan pesan dinamis dari hirarki kelas
SIMIAN.
3.3.2.1 Dinamika Perilaku Objek
Salah satu prinsip utama arsitektur SIMIAN adalah fleksibilitas dan kemampuan
diperpanjang yang harus disediakan sistem, memungkinkan tingkat penyesuaian pada saat run-
time. Meskipun produsen perangkat lunak mungkin berusaha menyediakan fasilitas bagi
sebagian besar pengguna, akan selalu ada fungsi yang tidak tercakup. Beberapa fleksibilitas
juga dituntut jika sistem memungkinkan perpanjangan waktu yang mudah dari waktu ke waktu
(terlepas dari fungsi migrasi skema basis data).

Gambar 3.5 Hirarki Kelas Inti SIMIAN

Dalam tahap desain sebuah aplikasi orientasi objek adat kebiasaan objek adalah sering
didirikan oleh mesin untuk mendefinisikan keadaan logika yang diusulkan kelas dalam sistem
[1,9,15] .Yang berlaku kondisi untuk kelas ini kemudian diterjemahkan ke dalam kode program
untuk menciptakan anggota data internal dan batasan eksternal untuk kelas .
 Perancangan dari kelas SIMIAN juga mengikuti prinsip ini, tetapi bukan
menerjemahkan model kondisi mesin ke statis, pernyataan pemrograman, menuntut agar setiap
objek dalam sistem dikaitkan dengan mesin kondisi eksplisit.
Mendeklarasikan perilaku objek dalam mesin kondisi eksplisit memberikan sejumlah
manfaat atas mekanisme tradisional dari pernyataan program.
Enkapsulasi dari perilaku objek eksplisit dalam satu kelas.
Perilaku objek, meski dikaitkan dengan pewarisan kelas, tidak sesuai dengan itu,
menghilangkan kesulitan yang terkait dengan kondisi dan pewarisan [16].
Mesin kondisi dimodifikasi pada saat run-time.
Pengguna dapat mengubah perilaku suatu objek
Perubahan kondisi mungkin dipicu secara dinamis melalui satu antarmuka pengguna.
Perilaku suatu objek mungkin terkait dengan pengguna melalui satu mekanisme dan bukan
serangkaian atribut yang beragam (sehingga mempermudah perancangan antarmuka
pengguna).
Keadaan mesin internal masing-masing objek memberikan model perilaku dinamis
untuk objek kepemilikan. Dari Gambar 3.5, masing-masing mesin kondisi dapat didasarkan
pada mesin induk induk. Pengeditan run-time dapat dilakukan dengan membuat mesin anak
(secara analog dengan pewarisan kelas) - melibatkan perubahan hanya pada contoh perilaku
kelas, atau alternatifnya ke mesin kondisi terkait, mengubah perilaku semua benda kelas yang
terkait dengan mesin yang diberikan serta semua anaknya.
Setiap mesin kondisi berisi satu set keadaan internal, satu set pemicu eksternal dan satu
set transisi. Setelah semua masukan menyatakan untuk transisi adalah VALID, transformasi ke
keadaan keluaran dipertimbangkan. Jika transisi selesai (lihat di bawah), sebuah pesan dikirim
ke objek aplikasi Event Handler untuk memberi tahu aplikasi yang tertarik mengenai
kemungkinan perubahan data contoh kelas.

3.3.3 Navigasi Mesin Kondisi

Kelas mesin kondisi juga memiliki fungsi publik untuk secara dinamis menavigasi melalui
contoh kondisi bagian internal. Menggunakan teknik algoritma genetika (GA), pengguna dapat
menentukan kondisi awal dan akhir mesin dan mengharuskan sebuah rute dievaluasi yang akan
melakukan transformasi dari keadaan awal sampai akhir. Transisi yang dibutuhkan untuk
melakukan transformasi ini kemudian dapat disampaikan kepada pengguna.
 Misalnya, setelah terjadi gangguan pada jaringan listrik, pertanyaannya, 'Tindakan apa
yang perlu dilakukan untuk menyambung kembali pasokan?' Bisa ditanyakan mesin konidisi
yang sesuai. Daftar operasi yang dikembalikan dari GA kemudian akan memungkinkan
operator untuk membangun kembali pasokan ke konsumen yang terkena dampak.
Meskipun terbatas penggunaannya saat ini (karena probabilitas transisi suatu kondisi
gagal untuk menyelesaikan (lihat di bawah) tidak dimasukkan ke dalam sistem), konsep ini
menggambarkan kekuatan representasi mesin kondisi eksplisit untuk perilaku objek.

3.3.3.1 Fungsi Dinamika

Setiap transisi dapat dikaitkan dengan sejumlah contoh kelas saDynamicFunction Contoh kelas
saDynamicFunction berfungsi sebagai pesan sinkron yang menuntut pelaksanaan fungsi
anggota kelas (dari kelas mana pun yang diwarisi dari kelas dasar abstrak) yang ditentukan
untuk objek kepemilikan. Pesan-pesan ini dapat diproses sebelum (sebagai prasyarat untuk
eksekusi transisi) atau setelah berhasil menyelesaikan transisi (sebagai efek samping dari
transisi).
Karena kelas eksekusi fungsi objek terdistribusi disisipkan di dalam kelas Fungsi
Dinamis, kinerja transisi suatu negara dapat memicu fungsi non-lokal maupun dalam proses.
Hal ini memungkinkan berbagai prasyarat untuk transisi harus didefinisikan, sementara
penerapan prasyarat dikeluarkan dari sistem pusat.

3.3.3.2 Variabel Kondisi

Fungsi Dinamis memungkinkan perilaku berbeda ditunjukkan setiap kali keadaan objek
berubah. Secara wajar, Variabel Negara memungkinkan variabel anggota kelas untuk
menunjukkan nilai yang berbeda tergantung pada keadaan mesin.
Misalnya, rating daya untuk saluran udara dan kabel bawah tanah bergantung pada suhu
medium sekitarnya (udara atau bumi). Daripada menyediakan empat variabel dan metode akses
terkait di dalam kelas Line / Cable, nilainya dapat dihubungkan ke empat keadaan yang
didefinisikan untuk konduktor - satu nilai yang terkait dengan masing-masing negara.
Untuk menggambarkan bagaimana sub sistem perilaku dinamis yang lengkap cocok,
pertimbangkan contoh berikut.
Sebagai bagian dari kelas CircuitBreaker, ada dua kondisi yang sesuai dengan status
Open dan Closed dari perangkat. Pengkodean konvensional kelas akan memerlukan pembuatan
fungsi publik untuk membuka dan menutup saklar serta data internal untuk menahan keadaan
saklar saat ini. Di bawah mekanisme Mesin kondisi untuk menentukan antarmuka ke kelas,
kelas menggunakan mesin kondisi yang berisi dua negara Terbuka dan Tertutup, serta kondisi
bagian pemicu 'openSwitch', 'closeSwitch' dan transisi terkait, yang diilustrasikan pada Gambar
3.6.
Model ini mungkin memadai untuk simulasi pemodelan sistem daya dari saklar, namun
sama sekali tidak memadai untuk aplikasi kontrol yang memerlukan lebih banyak pengaman
untuk dibangun ke dalam model switch. Untuk menambahkan kendala ini pada perilaku sistem
konvensional memerlukan pengodean ulang kelas. Namun, di bawah sistem SIMIAN,
dukungan untuk aplikasi kontrol hanya dapat dimasukkan dengan mengubah definisi mesin
agar sesuai dengan Gambar 3.7.

Gambar 3.6 Kondisi Mesin Switch Toggle Sederhana

 Gambar 3.7 Kondisi Mesin Penambah Switch

Pada Gambar 3.7, perubahan keadaan saklar sekarang memerlukan konfirmasi - dua kondisi
memicu tambahan dan dua keadaan internal tambahan dimasukkan. Selain itu, fungsi dinamis
(sendMessage) sekarang dikaitkan dengan transisi dari 'Switch Open Pending' menjadi 'Open'.
Fungsi sendmessage (umum untuk semua objek) mengirimkan pesan ke event handler
SIMIAN, yang selanjutnya akan diteruskan ke objek aplikasi yang relevan untuk memberikan
sinyal yang dapat didengar di meja kontrol.
Penting untuk dicatat bahwa penggabungan fungsi ini dapat dilakukan selama sistem
run-time. Mesin kondisi dapat diedit oleh petugas yang berwenang setiap saat, sedangkan
kaitan antara kode inti dan sinyal yang terdengar adalah melalui pesan yang melintas protokol
ke aplikasi independen (yang mungkin atau mungkin tidak mengakses inti OODBMS).

3.3.3.3 Komunikasi Objek Terdistribusi

Seperti yang dijelaskan dalam Pendahuluan dan disebutkan dalam contoh di atas, setiap objek
di dalam sistem dapat mengirim pesan ke objek lain di dalam sistem. Kelas Objek dalam hirarki
kelas Core menyediakan fungsionalitas ini.
 Meskipun pesan akhirnya melewati dua objek, semua pesan diarahkan melalui aplikasi
Event Handler yang menentukan aplikasi mana yang memerlukan pesan tersebut.
Objek dalam aplikasi, selama siklus eksekusi mereka, mendaftarkan minat pada objek
atau kategori pesan. Ketika sebuah pesan tiba di event handler, sebuah pengecekan untuk
kepuasan baik kendala dilakukan. Jika berhasil, objek yang terdaftar menarik adalah 'dipanggil
kembali' dengan isi pesan masuk.

3.4 Kelas Sistem Tenaga Arsitektur SIMIAN

Gambar 3.8 menggambarkan bagian atas hirarki kelas untuk sistem tenaga kelas
pemodelan aplikasi.
Kelas Objek yang diperkenalkan pada bagian sebelumnya berfungsi sebagai kelas dasar
untuk arsitektur sistem tenaga. Pewaris utama kelas Objek, sehubungan dengan hirarki
komponen sistem daya, adalah kelas Model. Kelas ini mengenkapsulasi konektivitas topologi
antara komponen model sistem tenaga.
Hirarki kelas berbasis SIMIAN, seperti pada penulis lain [2,3,17], berdasarkan klasifikasi
topologi item / jaringan tanaman. Setiap entitas topologi dalam arsitektur mewarisi dari kelas
Model yang menyediakan fungsionalitas penelusuran topologi serta metode interkoneksi /
pemutusan untuk kelas yang diwarisinya. Setelah kelas Model, divergensi hirarki terjadi atas
dasar kardinalitas kemungkinan antar-koneksi ke model topologi lainnya.
Seperti yang digambarkan pada Gambar 3.8, model dapat dihubungkan ke model lain
melalui kelas Link (Setiap Link harus terhubung ke dua Model, sementara Model dapat
dihubungkan ke sejumlah Link). Meskipun, pada tingkat kelas Model dalam hierarki, model
dapat dihubungkan ke sejumlah model lain, jumlah pasti dari model yang dapat dihubungkan
dengan instance apapun dikendalikan melalui eksekusi fungsi virtual di kelas pewaris. Pada
tingkat berikutnya.
 Gambar 3.8 Hirarki Kelas Sistem Tenaga SIMIAN

bawah, grup A kemungkinan memiliki koneksi nol, Port memiliki satu, Pipa memiliki dua dan
Web memiliki kemungkinan interkoneksi ke objek lain. Pembatasan lebih lanjut dapat
diperkenalkan di kelas anak untuk melarang interkoneksi tanaman tertentu (seperti barang
pabrik yang beroperasi pada tingkat voltase yang berbeda-beda, misalnya 132 kV langsung ke
415 V).
Selain interkoneksi, model dapat diwakili oleh model lain, dan mungkin juga mengandung
model lain.
3.4.1 Model Agregasi
Dalam pemodelan sistem tenaga sering ada kebutuhan untuk menggabungkan entitas
(baik fisik maupun abstrak) menjadi satu 'model komponen'. Misalnya, saklar pemilih bus
secara logis terdiri dari dua switch, namun sebenarnya adalah 'komponen' tunggal (dualitas
juga terlihat antara transformer dan belitan dan jaringan distribusi dan gardu induk di
dalamnya).

3.4.2 Model Representasi

Meskipun model utama jaringan akan berkonsentrasi pada komponen, begitu teknik
analisis (seperti analisis aliran atau analisis kesalahan) diterapkan pada model industri, data
sering diubah menjadi struktur data khusus untuk algoritma numerik. Proses ini sia-sia karena
menghilangkan model fisik dari model analisis. Lebih dari itu, (misalnya), topologi jaringan
node-flow flow flow pada dasarnya serupa dengan topologi tanaman fisik, namun ditunjukkan
dengan cara yang berbeda. Model node-branch dengan demikian dianggap hanya sebagai
representasi baru dari model jaringan. Masing-masing contoh kasus aliran aliran terdiri dari,
melalui asosiasi agregasi model, tanaman fisik di jaringan. Selain itu, interkonektivitas antara
node arus beban baru dan nodus sekitarnya tidak direkonstruksi: konektivitas didirikan antara
fisik.

Gambar 3.9 Skema Model Representasi

3.4.3 Model Ketepatan
Setiap model dikaitkan dengan akurasi. Karena, melalui asosiasi agregasi, mungkin ada
banyak pandangan tentang area jaringan, ketepatan menentukan sejauh mana algoritma mana
yang harus dipelajari sebelum mengambil representasi tanaman fisik. Misalnya, algoritma
mungkin memerlukan sejumlah segmen garis / kabel secara seri atau garis abstrak yang
parameternya sebuah amalgam dari masing-masing bagian. Keakuratan analisis mana yang
harus dilakukan menentukan representasi mana yang valid.
Konsep ini memiliki dua produk:
Menjadi mungkin untuk melakukan analisis dengan ketepatan yang ditentukan
pengguna. Di daerah di mana akurasi komputasi sangat penting, model yang paling
rinci dapat digunakan, dan sebaliknya di daerah yang tidak penting - meningkatkan
kinerja komputasi dengan biaya sedikit pun.
Jika sedikit detail atau tidak akurat diketahui untuk item tanaman, model secara
eksplisit ditandai sebagai modul analisis yang memungkinkan secara tidak akurat,
misalnya, menurunkan keakuratan secara keseluruhan dan menginformasikan
pengguna tentang akurasi studi yang diharapkan - yang mengarah pada penilaian
pengguna yang lebih akurat terhadap hasil analisisnya.

3.4.4 Kelas Hirarki Model Industri

Di bawah model dan konektivitas dapat ditemukan kelas komponen. Sebagian besar
kelas menempati posisi yang konsisten dengan definisi Ports, Pipes and Webs. Transformers
bukan subkelas dari Pipa karena konektivitas topologi sebenarnya karena gulungan -
transformator menjadi komposit ('Web') subclass. Perhatikan juga bahwa analisis dan objek
abstrak jaringan saling bercampur dalam hirarki dengan fisik model industri. Misalnya, aliran
beban kelas Node dan Cabang berada di samping kelas Busbar dan Line.

3.5 Aplikasi Arsitektur Aliran Beban

Jaringan IEEE 30-Bus digunakan untuk menguji penerapan SIMIAN Arsitektur. Eksekusi
analisis aliran beban pada suatu jaringan listrik dihitung tegangan pada titik-titik tertentu dalam
jaringan, dan dengan derivasi arus listrik dalam jaringan Permintaan atas informasi ini
memerlukan eksekusi analisisnya. Begitu permintaan diterima dari pengguna, jika tidak ada
representasi arus beban terkait dengan model, urutan peristiwa berikut terjadi:
 Modelnya menetapkan, melalui representasi dan sekitarnya konektivitas, apakah bisa
melakukan aliran beban. Jika tidak, permintaan itu diteruskan ke model komposit di
atasnya. Proses ini berlanjut secara rekursif sampai sebuah model ditemukan, minimal,
merupakan satu pulau dengan beban dan generasi.
Model yang memuaskan kemudian dibangun, dari komponen agregat, representasi
jaringan arus beban baru yang terdiri dari simpul arus beban / cabang yang terkait
dengan komponen sistem tenaga yang relevan.
Model jaringan arus beban kemudian menanyakan komponennya untuk membangun
model Jacobi untuk Newton-Raphson simulasi aliran beban, dan simulasi dijalankan.
Setelah selesai, hasilnya akan menyebar kembali ke model representasi, memperbarui
masing-masing node / elemen cabang dan pada gilirannya model dan tautan tanaman
fisik - sehingga memuaskan permintaan pengguna.
Proses ini tidak perlu jika ada representasi load flow dari jaringan ada bila parameter
jaringan berubah, ikatan ketat antara fisik dan model analitis memungkinkan evaluasi ulang
analisis yang malas. Misalnya, sebuah perubahan pada topologi jaringan hanya akan
menyebabkan node / cabang arus beban terkait langsung dengan topologi baru - tidak perlu
menghitung ulang keseluruhan topologi simpul-cabang Demikian juga perubahan pada
parameter, katakanlah nilai Line RIX, tidak memerlukan penghitungan ulang topologi.
Perubahan terhadap keakuratan yang dibutuhkan baik dari analisis maupun yang tersusun
Model mungkin atau mungkin tidak memerlukan penyesuaian ulang topologi aliran beban.
Untuk tinggi Keakuratan, setiap urutan satu atau lebih elemen garis seri diubah menjadi sebuah
cabang. Dengan akurasi rendah dan impedansi garis rendah, aliran beban node pada keduanya
akhir digabungkan dan analisis kinerja ditingkatkan.

3.6 Kesimpulan
Dari hasil awal, arsitektur SIMIAN nampaknya bisa diterapkan dan sistem yang efisien
untuk pemodelan sistem tenaga. Pekerjaan masa depan akan menyelidiki efek penskalaan
dalam ukuran jaringan. Jaringan IEEE 30-Bus adalah tidak realistis kecil dibandingkan dengan
studi perencanaan distribusi khas 5000 node.
Kemampuan perilaku dinamis dari sistem SIMIAN ditemukan memungkinkan
perpanjangan yang mudah, sekaligus mempertahankan sifat arsitektur yang berorientasi objek.
Integrasi GUI untuk parameter model penjelajahan dan representasi topologi jaringan
diimplementasikan dengan dinamis fungsi, dan fungsionalitas mesin negara. Penggunaan
mekanisme yang umum tidak hanya disederhanakan desain tapi juga memungkinkan kelas GUI
resultan untuk menjadi dibangun dengan cara yang sangat generik dan sebagai aplikasi
independen sepenuhnya benda. Dalam memasarkan 'aplikasi' ke platform perangkat keras yang
berbeda, seperti PC, Kemampuan terakhir ini mengharuskan hanya satu bagian ini yang perlu
di porting objek aplikasi server mungkin tetap berada di workstation. Selain itu, otomatis
update informasi antar aplikasi dan OODBMS diselesaikan secara mulus melalui sistem
penanganan event. Dari ini Pengalaman, nampaknya aplikasi yang lebih kompleks, misalnya
SCADA, bisa Jadilah 'melesat' dengan cara yang sebanding.