Piawaian menakrif kejuruteraan perisian sebagai tiga kategori utama; Pemberian Tujuan, Pemodelan, dan Simulasi. Setiap satu aspek memainkan peranan penting dalam membimbing usaha kejuruteraan ke arah penghasilan penyelesaian dan pengabulan sesebuah tujuan.
Pelaksanaan mengikuti turutan aspek-aspek ini juga adalah disengajakan. Suatu tujuan mestilah wujud dalam proses pembentukan. Interaksi pula tidak dapat disimulasi tanpa wujudnya model. Akan tetapi, walaupun turutan ini penting semasa permulaan proses kejuruteraan, harus kita ingat bahawa proses ini boleh berulang-ulang tatkala kita ingin berbuat demikian. Suatu perubahan dalam tujuan mungkin mencetus perubahan dalam simulasi tapi tak semesti dalam modelnya. Suatu perubahan dalam model tak semestinya memerlukan perubahan dalam tujuan atau simulasi.
Proses pemberian tujuan adalah kebolehan kita dalam mencari jawapan kepada soalan "mengapa kita mencari penyelesaian". Bagi contoh, katakan kita menghadapi isu dalam mengenalpasti jumlah barangan yang dipamer atas rak sesebuah kedai runcit. Kita merasa perhitungan manual tidaklah cekap, maka kita perlu membina sebuah sistem untuk mencapai hasrat ini.
Penaakulan amatlah bergantung pada kebolehan kita memerhati masalah dan kemudiannya menghurai masalah itu untuk merangka sebuah penyelesaian. Oleh demikian, matlamat pemberian tujuan adalah untuk mencari apa sebab kita mengambil tindakan.
Maka kita punyai pemerhatian, penghuraian sebab (masalah), dan niat untuk sebuah penyelesaian. Semua aspek-aspek ini membentuk bahagian Pemberian Tujuan dalam kejuruteraan perisian.
Kita hidup dalam dunia serba boleh diperhati. Inspirasi kita dicetus oleh cita-cita kita untuk mencapai lebih lagi. Mimpi-mimpi kita menzahirkan halangan dan rintangan yang perlu kita atasi untuk meneruskan perjalanan dan mengabul impian. Dari saat seseorang pelajar muda mengguna kalkulator untuk menyelesai persamaan rumit sampailah ke saat pelajar itu menjadi seorang angkasawan, mnghitung lintasan satelit-satelit yang mengorbit bumi.
Pemerhatian adalah keupayaan kita dalam mengenalpasti isu yang menghalang pencapaian sesuatu matlamat. Isu-isu mungkin semudah menghitung barangan atas rak gerai runcit, juga boleh serumit memahami mengapa kita tidak dapat mengambil gambar planet yang terletak berjuta-juta tahun cahaya dari bumi. Inilah apa yang jurutera-jurutera panggil sebagai masalah yang boleh diperhati.
Semakin agung tujuan, semakin rumit sesebuah masalah. Tetapi adanya permulaan dengan tujuan yang lebih kecil, bolehlah kita melatih minda untuk menangani yang lebih besar - langkah demi langkah, masalah demi masalah.
Penghuraian hasil pemerhatian merupakan satu seni tersendiri kerana penghuraian masalah yang dilakukan dengan baik boleh membawa kita ke pertengahan jalan dalam pencarian penyelesaian. Semakin jelas penghuraian, semakin kita yakin bahawa masalah itu boleh difahami orang-orang lain yang membantu mencari penyelesaian.
Penghuraian tidak semestinya dengan perkataan. Ia juga boleh dilakukan melalui gambaran dan segi bentuk. Tidak hairan sesetengah tamadun kuno yang paling maju menggunakan gambaran dan segi bentuk untuk menghurai kisah-kisah dan sejarah. Gambaran adalah satu bahasa sejagat, di mana ia lebih senang difahami dan ditafsir oleh sesiapa yang merasa hubungan dengannya; jauh lebih cepat dari mempelajari satu bahasa lisan. Gambaran atau segi bentuk mungkin merupakan cara terbaik untuk meggambarkan suatu ilham, bak kata pepatah - sekeping gambar seribu makna.
Penghuraian memerlukan keghairahan dalam menyelesai masalah. Sama ada ia ditulis, dibicara, atau digambar. Minda yang ghairah mampu menyampaikan kandungan tersirat kegentingan sesebuah masalah dalam usaha mencari penyelesaian. Penghuraian sesebuah masalah merupakan satu bahagian besar dalam pembentangan penyelesaian. Keupayaan kita dalam penyampaian ilham kepada jurutera-jurutera lain dan kepada yang ingin melabur serta mengguna penyelesaian ini, adalah salah satu aspek paling genting dalam kejuruteraan perisian.
Sebahagian dari tujuan ialah cara untuk mengabulnya. Dalam industri kejuruteraan perisian, kita tidak boleh mengamalkan "matlamat menghalalkan cara". Satu sebab utama mengapa begitu banyak sekali perisian gagal di dunia ini adalah kerana aspek perangkaan penyelesaian sering dilihat sebagai satu bahagian remeh dalam tujuan. Anda mungkin pernah dengar kisah jurutera-jurutera dalam situasi saat-saat akhir yang memutus untuk menghantar kerja bermutu rendah demi mencapai sasaran. Dalam Piawaian kita, ini adalah satu pencabulan. Suatu penyelesaian bukan sahaja mesti mencapai matlamat tetapi juga mesti membawa tujuannya yang tersendiri, dalam membantu isu seni bina sekeliling seperti pengoptimuman, kebolehbacaan, kebolehkonfigurasian, dan kelanjutan usia.
Menjadikan perangkaan penyelesaian sebahagian dari tujuan, adalah apa yang kita panggil sebagai kejuruan perisian.
Pemodelan merupakan aspek kedua terpenting dalam kejuruteraan perisian. Kita boleh ukir model dari watak-watak dalam mana-mana masalah, sama ada watak-watak ini adalah makhluk hidup, objek, atau lain-lain. Kita cuma ukir ciri-ciri yang bersangkut paut dengan masalah yang sedang kita cuba selesai sahaja, dan buang yang lain. Sebagai contoh, apabila kita cuba menghitung bilangan barangan atas rak kedai runcit, maka kita perlukan satu model untuk barangan ini.
Satu contoh yang lebih jelas ialah apabila kita ingin mengesan barangan mudah rosak dalam kedai runcit. Ciri yang kita mahu ambil tahu ialah tarikh luput barangan. Ciri-ciri lain seperti label, warna, berat, atau butiran lain, terletak di luar skop proses pemodelan dan penyelesaian ini.
Pemodelan tidak dapat wujud tanpa suatu tujuan, kerana tujuan itu menakrif skop atau rangka kerja pemodelan. Pemodelan tanpa suatu tujuan menyebabkannya menraik penglibatan tanpa terhad segala unsur-unsur yang wujud di alam yang boleh diperhati ini.
Perhubungan antara pemberian tujuan dan ciri-ciri pemodelan adalah berkadar. Semakin rumit sesuatu tujuan, semakin pasti proses pemodelan itu memerlukan lebih banyak ciri-ciri dari dunia nyata untuk mengukir rangka penyelesaian.
Kita mengungkap model dalam bahasa pemprograman sebagai kelas, atau class. Merujuk barangan mudah rosak di atas, kita boleh menulisnya seperti berikut:
public class Barang
{
public DateTimeOffset TarikhLuput {get; set;}
}Nama class mewakili jenis, atau type, keseluruhan bagi barang. Memandangkan semua barangan mempunyai ciri yang sama iaitu TarikhLuput, maka namanya harus kekal se-umum mungkin.
Sekarang, bayangkan tujuan kita bertambah rumit. Katakan masalah baru ialah bagaimana kita mengenal pasti barangan lebih mahal supaya ia boleh diletak di bahagian hadapan kedai untuk dijual sebelum barangan lebih murah. Dalam kes ini, model kita memerlukan satu ciri baru seperti Harga supaya program komputer atau sesuatu penyelesaian boleh menentukan yang mana lebih berharga. Model baru kita akan kelihatan seperti berikut:
public class Barang
{
public double Harga {get; set;}
public DateTimeOffset TarikhLuput {get; set;}
}Model mentadbir keseluruhan proses simulasi sesuatu masalah (dan penyelesaiannya). Model-model sendiri terdiri daripada tiga kategori utama; Pembawa Data, Operasi, dan Konfigurasi. Mari kita bincangkan jenis-jenis tersebut:
Model pembawa data mempunyai satu tujuan utama, iaitu membawa data melintasi sistem-sistem. Model pembawa data boleh berbeza berdasarkan jenis data yang dibawa. Sesetengah model pembawa data membawa model-model lain untuk mewakili sistem yang rumit. Sesetengah pula cuma mewakili rujukan kepada data asal yang diwakilinya.
Model pembawa data dalam gaya hubungan boleh dipecah kepada tiga kategori berlainan. Kategori-kategori ini menjadikan lebih jelas kawasan keutamaan dari segi pembangunan, reka bentuk, dan kejuruteraan. Contohnya, kita tidak dapat memulakan pembangunan model sekunder/sokongan sekiranya tiada model primer. Mari kita bincangkan dengan lebih mendalam:
Model-model primer adalah tiang-tiang bagi setiap sistem. Reka bentuk dan kejuruteraan mana-mana sistem jua tidak dapat diteruskan tanpa sebuah takrifan jelas dan pembinaan model-model primer. Contohnya, jika kita membina sebuah sistem persekolahan, model seperti Pelajar, Guru, dan MataPelajaran dianggap sebagai model-model primer.
Model skema storan hubungan primer tidak mempunyai kunci asing atau rujukan kepada sebarang model fizikal yang lain. Kita panggil model-model ini Primer kerana mereka boleh wujud sendiri tanpa bergantung pada yang lain. Dalam kata lain, model primer seperti Pelajar tetap boleh wujud dalam sebuah sistem persekolahan tak kira sama ada sebuah rekod Guru wujud atau tidak. Ini dipanggil kebergantungan fizikal.
Walau bagaimanapun dari segi konsep atau lojik, model primer mungkin bersandaran pada model-model lain. Contohnya, model Pelajar mempunyai perhubungan lojik dengan Guru kerana mana akan adanya pelajar tanpa seorang guru dan sebaliknya juga. Model Pelajar juga mempunyai perhubungan konsep dengan hos dan perkhidmatan hos berjiran. Contohnya, terdapat perhubungan konsep antara model Pelajar dan model Notifikasi berkenaan dengan aliran niaga. Secara konsepnya mana-mana pelajar sekolah bergantung pada notifikasi untuk hadir ke kelas dan untuk melengkap serta menghantar assignment atau untuk menghadiri majlis-majlis lain.
Sementara itu, model-model sekunder pula mempunyai kebergantungan sepenuhnya terhadap model-model primer. Dalam sesebuah model pangkalan data hubungan, model sekunder lazimnya mempunyai kunci asing yang merujuk model lain dalam skema keseluruhan pangkalan data. Malah dalam sistem storan tanpa hubungan, model-model sekunder boleh diwakili sebagai entiti terkandung dalam sebuah entiti lebih besar atau mempunyai rujukan longgar kepada entiti lain.
Mari kita bincangkan contoh-contoh model sekunder. Model Komen dalam media sosial tidak boleh wujud tanpa model Pos. Anda tidak dapat menambah komen terhadap sesuatu yang tidak wujud. Dalam pangkalan data hubungan, model komen akan kelihatan seperti berikut:
Merujuk contoh di atas, model sekunder Komen mempunyai satu kunci asing IDPOS yang merujuk kunci primer Id dalam model Pos. Dalam sistem tanpa hubungan pula, model-model sekunder dengan senangnya boleh dikenal pasti sebagai entiti yang terkandung dalam sebuah entiti lain. Contohnya:
{
"id": "contoh-id",
"kandungan": "contoh-pos",
"komen": [
{
"id": "id-komen",
"kandungan": "contoh-komen"
}
]
}Model-model sekunder secara amnya mungkin mempunyai perhubungan lojik dan konsep dengan model-model lain dalam hos sama, hos berjiran, atau sistem luaran. Walau bagaimanapun kebarangkalian wujudnya perhubungan konsep adalah jauh lebih rendah berbanding model-model primer.
Model-model hubungan berperanan sebagai penjalin dua model primer. Tanggungjawab utama mereka adalah untuk merealisasikan hubungan jamak dua belah, atau many-to-many, antara dua entiti. Contohnya, seorang Pelajar mungkin mempunyai beberapa guru; dan seorang Guru mungkin mempunyai beberapa pelajar. Dalam kes ini, kita perlukan satu model hubungan untuk bertindak sebagai model perantara.
Model-model hubungan/perantara tidak seharusnya mempunyai sebarang butiran. Mereke cuma mengandungi rujukan-rujukan kepada model lain, dan itulah kunci primernya. Maka terhasil lah satu kunci komposit yang menggabung dua atau lebih kekunci asing. Mari kita perhatikan contoh berikut:
Terdapat juga situasi di mana suatu model menjalinkan beberapa entiti serta membawa datanya sekali. Saya sarankan supaya tidak mengikuti haluan ini untuk mengekalkan kesucian reka bentuk sistem dan untuk mengawal kerumitan model-model anda. Walau bagaimanapun, kadang-kadang pendekatan ini diperlukan dalam perlaksanaan atau aliran niaga tertentu. Dalam kes begini, kita boleh cadangkan satu model hibrid yang boleh membawa butiran berkenaan perhubungan antara dua entiti bebas.
Model hibrid, atau kacukan ertinya, dapat menghuraikan hubungan boleh-putus dalam satu perhubungan jamak dua belah dalam senario padam-lembut, atau soft-delete. Mari kita perhatikan satu contoh model hibrid yang boleh terjadi di alam nyata. Katakan seorang ahli kumpulan ingin keluar kumpulan. Kita anggap keahliannya sebagai Nyahaktif dan lampirkan sebabnya tanpa memadam rekod itu. Ia akan kelihatan seperti berikut:
Model hibrid menggabung model-model sekunder seperti model sekunder menggabung model-model primer. Dengan membenarkan pelbagai entiti berhubung antara satu sama lain tanpa batas eksklusif, ia mewujudkan suatu persekitaran berhubungan. Dalam model data tanpa hubungan, keutuhan rujukan mungkin boleh menjadi lebih longgar disebabkan sifat lurus, atau linear, skema itu.
Model-model operasi kebanyakannya menyasar aspek simulasi dalam sesuatu sistem perisian. Fikirkan tentang semua operasi primitif, kompleks, dan pendedahan yang diperlukan oleh suatu senario mudah dalam usaha menjayakan perlaksanaan sebuah simulasi. Katakan kita cuba menyelesai suatu masalah yang akan memudahkan proses pendaftaran pelajar di sekolah. Proses pendaftaran ini memerlukan beberapa simulasi untuk menambah maklumat pelajar ke dalam sistem perkomputeran.
Model operasi lah yang akan mengendali pendedahan, pemprosesan, dan penyepaduan keseluruhan proses ini melalui perkhidmatan bagi API1/UI2 untuk memasuk, menghantar, menambah, dan menyimpan/mengekal maklumat pelajar ke dalam sistem persekolahan.
Rujukan pantas:
1API, atau Application Programmable Interface, merujuk kepada suatu permukaan boleh-program aplikasi di mana aplikasi lain boleh menggunakan permukaan ini untuk berinteraksi dengannya.
2UI, atau User Interface, merujuk kepada suatu permukaan aplikasi di mana pengguna boleh berinteraksi dengannya.
Piawaian memberi tumpuan khusus buat model-model operasi kerana mereka mewakili teras mana-mana sistem dari segi aliran niaga. Model operasi boleh dibahagikan kepada tiga kategori utama; Persepaduan, Pemprosesan, dan Pendedahan.
Mari kita bincangkan model-model operasi.
Tanggungjawab utama model operasi Persepaduan adalah untuk menghubungkan mana-mana sistem sedia ada dengan sumber-sumber luaran yang boleh ditempatkan dalam persekitaran setempatnya; seperti membaca tarikh atau waktu, atau membaca maklumat dari API luaran, atau mengekal data dalam sesuatu pangkalan data.
Model Persepaduan seperti ini dipanggil Broker. Mereka memainkan peranan sebagai penghubung antara model operasi Pemprosesan dan sistem luaran. Contohnya seperti berikut:
public partial class BrokerAPI
{
public async ValueTask<Pelajar> HantarPelajarAsync(Pelajar pelajar) =>
this.brokerApi.HantarAsync<Pelajar>(pelajar, url);
}Rujukan pantas:
Async, atau asynchronous, merujuk kepada kejadian/proses yang boleh berlaku serentak tanpa menunggu proses/kejadian yang sebelumnya selesai. Contohnya sebelum proses HantarPelajarAsync pertama selesai, kita boleh membuat lagi HantarPelajarAsync untuk kali kedua ketiga dan seterusnya.
Model Persepaduan di atas menawarkan keupayaan memanggil API luaran sambil mengabstrak keluar butiran konfigurasi dari model operasi Pemprosesan.
Seperti mana-mana jenis model operasi yang lain, mereka tidak memegang data tetapi sebaliknya mengguna pemalar dan harta persendirian kelas untuk berkongsi maklumat dalaman dengan kaedah-kaedah awam dan peribadinya. Model BrokerAPI di sini mewakili satu simulasi persepaduan dengan sistem luaran.
Kita akan bincang Broker secara lanjut dalam bab-bab seterusnya untuk memahami peraturan dan garis panduan dalam pembangunan broker sumber atau sistem luaran.
Model pemprosesan adalah pemegang semua simulasi yang berkaitan dengan niaga. Perkara seperti pendaftaran pelajar, permohonan kad perpustakaan baru, atau pengambilan maklumat pelajar berdasarkan kriteria tertentu. Model pemprosesan boleh jadi sama ada primitif/asas, peringkat-tinggi/pemprosesan, atau canggih/aturan.
Model pemprosesan secara umumnya bergantung sama ada pada model persepaduan, atau pada dirinya seperti khidmat pemprosesan perkomputeran, atau pada satu sama lain.
Mari kita lihat satu contoh mudah khidmat asas/primitif:
public partial class KhidmatPelajar : IKhidmatPelajar
{
private readonly IBrokerStoran brokerStoran;
...
public async ValueTask<Pelajar> TambahPelajarAsync(Pelajar pelajar) =>
await this.brokerStoran.MasukkanPelajarAsync(pelajar);
}Rujukan Pantas:
Terjemahan Operasi Pangkalan Data
| Bahasa Inggeris | Bahasa Malaysia |
|---|---|
| Select | Pilih |
| Insert | Masukkan |
| Update | Kemaskini |
| Delete | Padam |
Khidmat peringkat lebih tinggi akan kelihatan seperti berikut:
public partial class KhidmatPemprosesanPelajar : IKhidmatPemprosesanPelajar
{
private readonly IKhidmatPelajar khidmatPelajar;
...
public async ValueTask<Pelajar> KemaskiniMasukkanPelajarAsync(Pelajar pelajar)
{
....
Pelajar mungkinPelajar = await this.khidmatPelajar
.DapatkanPelajarMelaluiIdAsync(pelajar.Id);
return mungkinPelajar switch
{
null => await this.khidmatPelajar.TambahPelajarAsync(pelajar),
_ => await this.khidmatPelajar.UbahsuaiPelajarAsync(pelajar)
}
}
}Khidmat aturan yang lebih canggih pula akan menggabung beberapa khidmat asas dan khidmat pemprosesan seperti berikut:
public partial class KhidmatAturanPelajar : IKhidmatAturanPelajar
{
private readonly IKhidmatPemprosesanPelajar khidmatPemprosesanPelajar;
private readonly IKhidmatPemprosesanKadPerpustakaanPelajar khidmatPemprosesanKadPerpustakaanPelajar;
...
public async ValueTask<Pelajar> DaftarPelajarAsync(Pelajar pelajar)
{
....
Pelajar pelajarDikemaskiniMasukkan = await this.khidmatPemprosesanPelajar
.KemaskiniMasukkanPelajarAsync(pelajar);
...
await this.khidmatPemprosesanKadPerpustakaanPelajar.TambahKadPerpustakaanPelajarAsync(kadPerpustakaanPelajar);
}
}Secara amnya, model-model operasi cuma berperanan dalam penentuan sifat simulasi atau pemprosesan model pembawa data tertentu; mereka tidak berperanan memegang data atau mengekal status. Secara amnya model-model operasi tidak berstatus, yakni mereka tidak mengekal sebarang butiran yang mengalir melalui mereka selain mewakilkan tugasan pengelogan bagi tujuan pemerhatian dan pemantauan.
Model pendedahan mengendali HMI dalam semua senario di mana manusia dan sistem berinteraksi. Mereka mungkin terdiri daripada RESTful API dan SDK mudah atau UI seperti aplikasi sesawang, aplikasi telefon pintar, atau aplikasi desktop, termasuklah sistem/terminal baris arahan - 'command-line'.
Rujukan Pantas:
HMI, atau Human Machine Interface, merujuk kepada suatu permukaan pertemuan antara manusia dan mesin di mana manusia boleh berinteraksi dengan mesin/sistem.
Model operasi pendedahan umpama model persepaduan; mereka mengizin dunia luar untuk berinteraksi dengan sistem anda. Mereka duduk di satu hujung yang lain dan bertanggungjawab menghala setiap permintaan, komunikasi, atau panggilan ke arah model operasi yang betul. Model-model pendedahan tidak pernah berkomunikasi secara langsung dengan model-model persepaduan dan tidak mempunyai sebarang konfigurasi selain kebergantungannya yang disuntik melalui pembinanya.
Model pendedahan mempunyai bahasa tersendiri dari segi operasi; contohnya, model persepaduan mungkin menggunakan bahasa seperti MasukkanPelajar manakala model pendedahan bagi suatu titik akhir API pula akan menggunakan bahasa seperti HantarPelajar bagi operasi yang sama dalam konteks pendedahan.
Satu contoh model pendedahan:
public class AlatKawalanPelajar
{
private readonly IKhidmatAturanPelajar khidmatAturanPelajar;
[HttpGet]
public async ValueTask<ActionResult<Pelajar>> HantarPelajarAsync(Pelajar pelajar)
{
Pelajar pelajarTerdaftar = await this.khidmatAturanPelajar
.DaftarPelajarAsync(pelajar);
return Ok(pelajarTerdaftar);
}
}Model di atas mendedahkan suatu titik akhir API bagi komunikasi RESTful untuk membolehkan pendaftaran pelajar dalam sistem persekolahan. Kita akan bincang secara lanjut jenis-jenis model pendedahan berdasarkan konteks dan sistem di mana ia dilaksanakan.
Model jenis terakhir dalam mana-mana sistem ialah model konfigurasi. Mereka boleh mewakili pintu masuk sesebuah sistem, mendaftar kebergantungan bagi mana-mana sistem, atau wujud sebagai perisian tengah - 'middleware' untuk menghala URL ke arah fungsi-fungsi sewajarnya dalam model pendedahan.
Model konfigurasi biasanya terletak di permulaan pelancaran sistem, bagi mengendali komunikasi masuk dan keluar atau operasi tersirat sistem seperti 'memory caching', 'thread management', dan lain-lain.
Dalam sesebuah aplikasi API mudah, anda mungkin jumpa model seperti berikut:
public class Pelancaran
{
public void MengkonfigurasiParaKhidmat(IKhidmatkhidmat paraKhidmat)
{
paraKhidmat.AddTransient<IBrokerStoran, BrokerStoran>();
paraKhidmat.AddOAuth();
}
}Nota Penterjemah:
Saya menggunakan kata ganda para untuk merujuk kepada kemajmukan sesebuah entiti seperti 'services', supaya kita boleh bezakan antara satu khidmat - 'service' atau sekumpulan (para) khidmat - 'services'.
Seperti yang boleh anda lihat dari contoh kod di atas, model konfigurasi Pelancaran memberi keupayaan mengendali pendaftaran kontrak kepada pelaksanaan kukuhnya melalui suntikan kebergantungan. Ia juga boleh mengendali penambahan sekuriti atau memasang saluran perisian tengah.
Model konfigurasi berbeza antara teknologi berlainan. Model konfigurasi rangka kerja Play dalam Scala boleh berbeza dari Spring atau Flex dalam Python atau Java. Kita akan menggariskan peraturan-peraturan aras tinggi berpandukan Piawaian bagi model-model konfigurasi, tetapi kita tidak akan mendalami butiran pelaksanaannya.
Aspek simulasi dalam kejuruteraan perisian ialah keupayaan kita untuk meniru interaksi antara model-model. Seperti dalam contoh kedai runcit, simulasi boleh jadi suatu perlakuan penjualan barang. Penjualan sesuatu barang memerlukan beberapa modifikasi terhadap barang tersebut dari segi memotong jumlah stok barangan dan memesan semula barangan untuk mengisi stok berdasarkan barang paling berharga dalam stok.
Kita boleh menggambarkan proses simulasi sebagai perhubungan antara model-model, di mana ia diprogram sebagai fungsi - 'functions', cara - 'methods', atau rutin - 'routines'; terma-terma ini membawa maksud yang sama. Jika kita mempunyai khidmat perisian yang bertanggungjawab terhadap penjualan barangan, maka proses simulasi akan kelihatan seperti berikut:
public class KhidmatJualan
{
public void Jual(Barang barang) => Barangan.Singkir(barang);
}Dalam contoh di atas, kita mempunyai model KhidmatJualan yang berfungsi menggerakkan proses jualan sesebuah model barangan dalam dunia nyata. Beginilah caranya anda menghuraikan segalanya dalam pemprograman berorientasikan objek - 'object-oriented programming'. Segala-galanya dilihat sebagai sebuah objek (dari suatu model), dan objek-objek ini berinteraksi dengan satu sama lain (simulasi).
Interaksi object secara amnya boleh diperhati dalam tiga jenis berlainan. Sebuah model mengambil tindakan ke atas sebuah model lain. Contohnya, KhidmatJualan mengambil tindakan Jual ke atas model Barang. Itulah interaksi antara dua model. Dalam contoh yang sama, suatu simulasi boleh jadi suatu kejadian yang berlaku ke atas satu model dari satu model lain, seperti Barang dalam contoh di atas. Jenis simulasi terakhir adalah apabila suatu model berinteraksi dengan dirinya, seperti model yang musnah diri setelah mencapai tujuannya kerana mereka sudah tidak diperlukan lagi, maka mereka musnah diri.
Proses simulasi ialah aspek ketiga dan yang terakhir dalam kejuruteraan perisian. Kita akan mendalami lagi topik ini apabila kita berbincang tentang broker-broker, khidmat-khidmat, dan pendedah-pendedah untuk memberi satu gambaran bagaimana proses pemodelan dan simulasi perisian industri terjadi.
Jika kita ambil pemberian tujuan sebagai sebuah domain/medan atau rangka kerja di mana model-model berinteraksi, maka ilustrasi berikut harus boleh memudahkan dan menyampaikan gambaran ini dengan lebih jelas:
Adalah penting kita faham bahawa perisian komputer boleh memenuhi lebih dari satu tujuan. Perisian komputer boleh berinteraksi dengan perisian lain yang berkongsi tujuan sama. Maka tujuan perisian itu menjadi model, dan persepaduannya menjadi simulasi dalam aspek tersebut. Ini satu contoh 10,000 kaki:
Kerumitan mana-mana sistem yang besar boleh dipecah kepada masalah-masalah yang lebih kecil sekiranya kita menguatkuasakan aspek satu-tujuan atau satu-tanggungjawab dalam setiap pecahan sistem. Itulah apa yang dipanggil oleh seni bina perisian moden sebagai kebutiran - 'granularity' dan kemodularan 'modularity', yang akan kita bincang secara ringkas sepanjang bahagian aspek seni bina Piawaian.
[*] Pemberian Tujuan, Pemodelan, & Simulasi (Bahagian 1) dalam Bahasa Inggeris