Geekly articles weekly

Pemrograman adalah perwujudan gagasan.



Tesis utama artikel ini: Pengembangan perangkat lunak harus dilihat sebagai perwujudan ide melalui transformasi model mental menjadi kode program.
Artikel ini menjelaskan paradigma mewujudkan ide-ide dalam rekayasa perangkat lunak (bahasa Inggris: RPSE: Reifikasi sebagai Paradigma Rekayasa Perangkat Lunak).

Versi bahasa Inggris artikel: RPSE: Reifikasi sebagai Paradigma Rekayasa Perangkat Lunak . Singkatan RPSE digunakan kemudian dalam teks untuk menunjukkan paradigma yang dijelaskan.

Definisi Kunci


Sebelum membahas poin-poin utama dari artikel ini, Anda harus menyetujui arti dari istilah-istilah dasar yang digunakan di dalamnya.

Rekayasa perangkat lunak


Yang kami maksud dengan rekayasa perangkat lunak adalah definisi klasik dari disiplin Rekayasa Perangkat Lunak dari kamus IEEE [1]: Rekayasa perangkat lunak adalah “Penerapan pendekatan yang sistematis, disiplin, terkuantifikasi untuk pengembangan, pengoperasian, dan pemeliharaan perangkat lunak”.

Paradigma


Istilah paradigma yang digunakan dalam artikel ini didasarkan pada definisi klasik dari paradigma Thomas Kuhn [2]: Paradigma adalah lingkaran masalah, seperangkat konsep, aturan dan hukum yang diterima secara umum, metode untuk memecahkan masalah dalam bidang ilmu tertentu.

Lebih lanjut tentang paradigma
Untuk lebih menentukan konsep paradigma yang digunakan di bawah ini, ada baiknya mengutip dua kutipan terkenal dari buku Kuhn:
Dengan paradigma, maksud saya adalah pencapaian ilmiah yang diakui bahwa untuk beberapa waktu memberikan komunitas ilmiah model untuk mengajukan masalah dan solusi mereka ...

Memperkenalkan istilah ini, saya maksudkan bahwa beberapa contoh yang diterima secara umum dari praktik nyata penelitian ilmiah - contoh yang mencakup hukum, teori, penerapan praktisnya dan peralatan yang diperlukan - semuanya bersama-sama memberi kita model-model dari mana tradisi spesifik penelitian ilmiah muncul.

Dualisme dari konsep ini terletak pada kenyataan bahwa, di satu sisi, paradigma dicirikan melalui komunitas spesialis yang mengenalinya. Spesialis dari bidang tertentu yang menentukan, membuat, dan mengembangkan bagian-bagiannya. Di sisi lain, pengakuan terhadap paradigma tertentu berarti bagi seorang spesialis yang bergabung dengan komunitas semacam itu.

Thomas Kuhn mempertimbangkan paradigma ilmiah dalam bukunya. Namun, segera setelah rilis edisi pertama buku tersebut, kegunaan menggunakan konsep ini dalam teknologi dan berbagai bidang kehidupan sosial menjadi jelas. Dalam hal ini, banyak publikasi tentang paradigma dan perubahannya dalam industri otomotif, perencanaan kota, perawatan penyakit tertentu, dll. Mulai muncul dalam literatur khusus dan populer.

Rekayasa perangkat lunak dan terutama komponen penting - pemrograman, tidak terkecuali. Saat ini ada banyak paradigma pemrograman yang bersaing. Artikel terpisah di Wikipedia [3], serta ulasan menarik seperti [4], dikhususkan untuk pencacahan mereka.

Tentang keterbatasan paradigma pemrograman
Para penulis paradigma yang dijelaskan dalam [3] dan [4] berkonsentrasi pada sub-area yang sempit dari rekayasa perangkat lunak, yaitu, menulis program dalam bahasa pemrograman tertentu. Saya pikir banyak profesional setuju bahwa proyek perangkat lunak nyata tidak dapat diselesaikan dalam kerangka hanya satu dari paradigma ini (misalnya, pemrograman fungsional).

Paradigma yang dijelaskan dalam artikel ini, sebaliknya, berlaku untuk berbagai bidang subjek dan fase pengembangan perangkat lunak.

Pada keterbatasan paradigma manajemen proyek perangkat lunak
Beberapa penulis, misalnya, dalam tinjauan [5], menyebutkan berbagai pendekatan atau model untuk mengatur dan melakukan proyek perangkat lunak sebagai paradigma. Misalnya, model air terjun, model V, atau model Agile dibandingkan. Tidak mungkin bahwa pendekatan ini, berbeda dengan paradigma pemrograman yang disebutkan di atas, dapat disebut paradigma dalam semangat definisi Kuhn karena kesederhanaan teoretis relatifnya dan kurangnya landasan teori yang luas.

Paradigma yang diusulkan dalam artikel ini juga belum memiliki landasan teoretis yang dikembangkan sendiri, tetapi hari ini jalur pengembangannya sudah terlihat.

Terwujudnya ide


Istilah materialisasi ide (bahasa Inggris: reifikasi ) yang digunakan dalam artikel ini adalah perpanjangan dari definisi klasik reifikasi dalam ilmu komputer: "Reifikasi adalah proses dimana ide abstrak tentang program komputer diubah menjadi model data eksplisit atau objek lain yang dibuat dalam bahasa pemrograman" [6].

Lebih banyak tentang dunia ide, dunia benda dan materialisasi
Inti dari perluasan definisi klasik dari konsep materialisasi yang digunakan dalam artikel ini dapat didefinisikan sebagai berikut.

Sudah sejak awal traktat filosofis yang turun kepada kita, sudah biasa untuk membandingkan Ideal (dunia ide) dengan Material (dunia benda).

Kita dapat merasakan yang terbaik yang terbaik (atau berpikir bahwa kita merasakannya). Indikator perasaan Ideal seperti itu bisa berupa perubahan suasana hati atau pemikiran setelah mendengarkan musik, fragmen buku yang sudah dibaca, dll. Tentu saja, maksud saya adalah efek tidak langsung, misalnya musik, pada kesadaran kita, dan bukan subordinasi fisiologis primitif tubuh terhadap deru konser rock atau ritme disko.

Upaya merumuskan rasa Ideal kita sebagai suatu peraturan tidak mengarah pada kesuksesan.
Penyair besar Rusia, Fedor Ivanovich Tyutchev, berkomentar sangat:
Bagaimana hati mengekspresikan dirinya?
Bagaimana cara memahami Anda?
Apakah dia akan mengerti bagaimana Anda hidup?
Pikiran yang diucapkan itu bohong ... [7]
Bahkan ide-ide praktis seperti perbaikan kecil di sekitar rumah atau menyiapkan variasi baru hidangan yang akrab pada awalnya sulit untuk dirumuskan. Dan hanya setelah musyawarah atau upaya untuk menjelaskan kepada orang lain, gagasan mengambil "garis besar" semakin jelas.

Kita sekarang beralih dari pertimbangan konsep Ideal ke pertimbangan Material. Kita dapat merasakan dan mendaftarkan benda-benda material di sekitar kita, untuk membedakan sifat-sifatnya secara kualitatif. Properti banyak objek dapat diukur secara objektif. Kami juga dapat secara objektif mengidentifikasi hierarki dan struktur lain dari objek material.

Untuk mengevaluasi atau mengukur (untuk mendapatkan karakteristik kuantitatif) tidak perlu memiliki item. Sudah cukup memiliki modelnya. Selain itu, dalam banyak situasi yang praktis menarik, model dapat digunakan tanpa objek. Model dapat didiskusikan dengan orang lain. Model dapat dinegosiasikan. Model dapat distandarisasi (diformalkan).

Dalam beberapa bidang aktivitas manusia, standardisasi model telah berjalan sejauh bagian-bagian (misalnya, baut berulir) dibuat berdasarkan model standar (misalnya, gambar) oleh orang yang berbeda atau senapan mesin tidak dapat dibedakan dari sudut pandang teknologi.

Menyadari ketidakakuratan relatif dari definisi yang diusulkan, nanti dalam artikel ini saya akan membagi dunia fenomena dunia batin dan dunia luar kita menjadi dua bagian:

U = M + I

di mana himpunan M terdiri dari fenomena mereka yang dapat didaftarkan atau diukur secara objektif (dunia material) dan I - segalanya.

Apakah formula ini berlaku untuk semua fenomena dunia di sekitar kita adalah pertanyaan filosofis terbuka. Kemudian dalam artikel ini, kami mempersempit cakupan formula ini ke dunia fenomena dari dunia rekayasa perangkat lunak.

Atau, merumuskannya sebagai tesis: Seluruh rangkaian fenomena yang terkait dengan rekayasa perangkat lunak dapat dibagi menjadi subset dari yang ideal dan subset dari materi. Selain itu, fenomena material dicatat atau diukur berdasarkan model mereka.
Proses membuat atau memodifikasi sistem perangkat lunak berakhir dalam banyak kasus dengan penciptaan satu atau kode lain, yang, menggunakan komputer, ditampilkan dalam proses fisik (fenomena dunia nyata).

Proses ini dimulai dengan munculnya ide-ide tertentu tentang sistem masa depan di benak pelanggan atau pengembang. Kami akan menyebut ide dan ide ini sebagai model mental .

Tentang Model Menengah
Dalam sistem sederhana atau dengan penambahan / perubahan sederhana pada sistem besar, pengembang segera menulis kode atau mengkonfigurasi sistem berdasarkan model mentalnya. Namun, dalam kebanyakan kasus, model antara kompleksitas dan tingkat formalisasi yang berbeda dibuat - dari daftar persyaratan sederhana hingga model formal yang luas (misalnya, model UML atau BPMN)

Terwujudnya ide di bidang yang berdekatan dengan Rekayasa Perangkat Lunak


Jelas bahwa definisi di atas tidak secara radikal baru dan digunakan secara luas (secara sadar atau tidak sadar) di bidang pekerjaan intelektual yang berdekatan dengan pemrograman. Misalnya, pertimbangkan dua bidang seperti itu - teknik mesin dan matematika.

Kedua bidang ini telah menggunakan materialisasi gagasan untuk waktu yang lama dan efektif. Mereka harus banyak belajar tentang pemrograman dalam hal ini.

Dalam teknik mesin, kita melihat siklus lengkap dari materialisasi ide - dari munculnya ide di kepala perancang melalui pemikirannya melalui, merinci, memetakan ke dalam model, dan akhirnya - manufaktur dari bahan tertentu.

Situasinya berbeda dalam matematika.

Pada materialisasi ide dalam matematika
Fakta menarik dan pertimbangan mengenai materialisasi gagasan dalam matematika dapat ditemukan dalam paragraf 7.3 dalam buku [8].

"Produk akhir" matematika adalah model formal dengan sifat yang telah terbukti benar.

Dari sudut pandang ini, pemrograman ada di tengah. Ini dapat digambarkan secara grafis sebagai berikut:



Dengan demikian, matematika menggunakan sejumlah besar model yang lebih abstrak dan hampir tidak berlaku untuk bidang model yang sangat spesifik seperti gambar teknik.

Teknik mesin, sebaliknya, menggunakan model abstrak yang relatif sedikit, tetapi banyak yang spesifik. Misalnya, benda-benda yang objek fisiknya dapat dibuat dengan jelas.

Dari sudut pandang ini, pemrograman ada di tengah.

Mengapa pemrograman di tengah?
Produk pemrograman terakhir adalah kode perangkat lunak. Dan meskipun itu, ketika dieksekusi pada perangkat keras, dipetakan ke objek fisik tertentu (sinyal listrik dan bidang berbagai sifat fisik), objek ini sulit untuk dibandingkan dengan mur, roda gigi, dan badan mobil. Di sisi lain, kode program dekat dengan rumus matematika, dan kadang-kadang itu adalah refleksi langsung mereka. Namun, dalam sistem perangkat lunak nyata, Anda perlu mempertimbangkan banyak aspek khusus dari lingkungan dan interaksi dengan pengguna atau sistem lain. Ini membuat kode program lebih spesifik daripada rumus matematika.

Apa yang bisa dipelajari oleh rekayasa perangkat lunak dari wilayah sekitar dalam hal penggunaan model
Pertimbangkan dulu matematika.

Multimodel dunia


Selama beberapa ribu tahun perkembangannya, matematika telah belajar untuk menggambarkan fenomena yang sama dari dunia nyata atau imajiner dalam istilah yang sangat berbeda. Orang-orang Yunani kuno belajar untuk mengganti deskripsi verbal murni tugas-tugas dengan angka-angka geometris dan dengan bantuan mereka memecahkan masalah yang praktis penting. Kemudian, muncul pemahaman tentang pertukaran segmen di pesawat dan angka. Kemudian konsep variabel aljabar dan reduksi masalah geometri menjadi sistem persamaan aljabar dikristalisasi.

Saat ini, siswa sekolah menengah sudah tahu bahwa masalah yang sama dapat diselesaikan dengan cara yang berbeda (misalnya, secara geometris atau aljabar) dan bahwa model matematika yang sama, misalnya, persamaan aljabar, menggambarkan banyak perbedaan fisik, kimia, dll. fenomena.

Morfisme model dan konsistensi konsep dan notasi


Matematika telah belajar dengan baik tidak hanya untuk menggambarkan objek dan proses nyata atau imajiner yang sama menggunakan model yang sifat matematisnya sangat berbeda. Suatu pencapaian penting matematika adalah kemampuan untuk menentukan tingkat kesamaan model dari berbagai cabang matematika, serta kemampuan untuk mengubah mereka menjadi satu sama lain. Banyak solusi terobosan untuk masalah matematika paling penting dalam beberapa tahun terakhir pada dasarnya adalah rantai bukti terpisah, yang masing-masing menggunakan alat khusus dari bagian khusus matematika. Pada persimpangan bukti yang sangat khusus ini, matematika dengan terampil mengubah model dari satu bagian matematika menjadi model bagian lain. Dalam pemrograman, sesuatu yang serupa terjadi sekarang ketika mengkompilasi kode sumber program dan ketika menghasilkan kode dari DSL (Domain Specific Language) atau metadata. Tetapi budaya bekerja dengan model di bidang rekayasa perangkat lunak jauh di belakang yang matematika.

Model dalam teknik mesin


Dan apa yang bisa dipelajari rekayasa perangkat lunak dari materialisasi dalam rekayasa?
Di banyak industri, dan bahkan dalam keprihatinan besar, ada rantai model formal dan semi formal yang terkoordinasi. Rantai ini diakhiri dengan model, yang menjadi dasar pembuatan dan pemasangan benda fisik - perangkat dan mesin. Sebagai aturan, untuk sebagian besar jenis model perantara, ada metode formal untuk memeriksa kebenarannya (standar teknis). Model adalah bahasa komunikasi utama para spesialis dari berbagai profil dalam proses perancangan dan pembuatan produk-produk teknik.

Terhadap latar belakang ini, situasi di IT terlihat jauh lebih buruk. Hanya dalam keprihatinan TI yang sangat besar dalam beberapa tahun terakhir telah dilakukan upaya untuk membangun serangkaian model dan proses yang sebanding. Perusahaan kecil dan perusahaan rintisan TI, sebagai suatu peraturan, tidak hanya tidak mengembangkan model dan proses formal, tetapi bahkan tidak mencurigai keberadaan mereka. Situasi ini saat ini ditentukan oleh faktor-faktor berikut:

  • Kurangnya efisiensi model dan proses yang ada
  • Kurangnya ketenaran model-model ini di luar kekhawatiran besar
  • Pendidikan yang tidak memadai untuk pengembang dan terutama manajer
  • Tumpukan pendidikan universitas dari kebutuhan nyata rekayasa perangkat lunak.

Definisi dan kontur paradigma materialisasi gagasan (RPSE)


Kami telah mengidentifikasi semua konsep yang diperlukan untuk memberikan definisi dasar dari paradigma yang diusulkan. Ini dia:
Pengembangan perangkat lunak adalah perwujudan ide melalui transformasi model mental menjadi kode yang dijalankan pada komputer.

Dalam kerangka paradigma yang diusulkan:

  1. Semua proses pengembangan perangkat lunak utama adalah varian spesifik (implementasi) dari proses membangun rantai model mental dan material. Model paling spesifik terakhir dalam rantai ini adalah, sebagai aturan, kode program.
  2. Inti dari pengembangan perangkat lunak adalah menciptakan rantai seperti itu.
  3. Semua masalah utama optimasi pengembangan, mengurangi biaya dan meningkatkan kualitasnya dapat dikurangi untuk mengoptimalkan pembangunan rantai model yang sesuai.

Mengapa Materialisasi dan Bukan Modeling?
Perhatikan bahwa meskipun definisi RPSE mengacu pada pembangunan rantai model, namun demikian diusulkan untuk menyebut materialisasi paradigma daripada pemodelan. Dengan demikian, upaya dilakukan untuk menekankan kekhasan rantai model yang menjadi semakin tidak abstrak / ideal dan semakin konkret / material.

Definisi di atas memiliki karakteristik dan variasi sendiri di berbagai bidang rekayasa perangkat lunak. Hanya dalam sejumlah kecil kasus yang terjadi bahwa di kepala seorang programmer, sebuah gagasan yang jelas tentang bagaimana menyelesaikan tugas sebelum dia benar-benar matang, yang kemudian diterjemahkan ke dalam kode bahasa pemrograman dalam waktu singkat. Dalam sebagian besar proyek dunia nyata, proses menemukan solusi dan implementasinya hidup berdampingan, berkembang secara paralel dan berinteraksi satu sama lain. Yaitu model mental, kode, dan seringkali model perantara (dalam bentuk tes, gambar, model formal seperti UML) tumbuh dan berubah secara paralel, saling memengaruhi.

Opsi Definisi
Sangat sering beberapa orang mengerjakan suatu masalah pada saat yang bersamaan. Masing-masing dari mereka memiliki model mentalnya sendiri dan, mungkin, model-model menengahnya dan fragmen kode.

Seringkali kode dalam beberapa bahasa pemrograman hampir tidak ada, karena menciptakan solusi baru datang ke pengelolaan topeng konfigurator atau generator, seperti ketika bekerja dengan alat pengembangan dalam sistem seperti SAP atau WebSphere.

Pilihan untuk mengubah kode yang ditulis secara manual atau dibuat secara otomatis menjadi kode yang dapat dieksekusi juga menjadi sangat beragam belakangan ini.

Dan akhirnya, konsep prosesor tempat kode dijalankan juga telah berkembang secara signifikan dalam beberapa tahun terakhir. Jika sebelumnya itu adalah prosesor yang ada di papan, yang pada gilirannya dimasukkan ke dalam cangkang desktop, laptop dan rak server, sekarang set ini telah diperluas oleh berbagai chip dari berbagai ukuran yang dibangun ke dalam ponsel, konsol game, kamera pengintai, " peralatan rumah pintar, dll. Belum lagi komputer kuantum.

Namun demikian, RPSE, berdasarkan sifat umumnya, berlaku untuk semua area yang tercantum di atas.

Apa lagi yang bisa dikatakan tentang paradigma tertentu saat ini, mungkinkah untuk secara lebih akurat menguraikan konturnya?

Langkah selanjutnya untuk memperbaiki paradigma setelah mencoba memberikan definisi utamanya adalah upaya untuk membuat daftar kategori utama dari fenomena yang dipengaruhi. Mengingat definisi Kuhn, kita perlu mencoba mendaftar jenis-jenis model yang diperkenalkan dan digunakan RPSE.

Model RPSE dapat dibagi menjadi tiga kategori utama:

  • Model mental
  • Kode dalam bahasa pemrograman atau yang setara sebagai model kode yang dapat dieksekusi.
  • Model menengah.

Yang paling tidak dieksplorasi dalam triad ini adalah model mental. Apa sebenarnya yang dimaksud oleh mereka?

Model mental adalah istilah untuk ide-ide yang ada di kepala pelanggan, programmer dan peserta lain dalam proses dan atas dasar yang akhirnya kode executable muncul. Kehadiran model seperti itu tidak dapat dibantah dan dapat didaftarkan pada tingkat mental, misalnya, oleh programmer sendiri.Pada tingkat perkembangan teknologi saat ini, model-model ini tidak dapat diukur dengan andal oleh instrumen.

Salah satu cara yang berhasil untuk memperbaiki dan mengukur model-model tersebut adalah dengan menggunakan media ide. Jelas, proses wawancara atau yang serupa secara dramatis mempengaruhi model mental itu sendiri. Kita masing-masing pasti pernah mengalami situasi lebih dari sekali ketika upaya untuk merumuskan masalah untuk berkonsultasi dengan seorang kolega saja mengarah pada "wawasan", dan seringkali ke solusi untuk masalah tersebut.

Wawancara memungkinkan, berdasarkan pertanyaan yang diformulasikan dengan benar, untuk secara relatif membangun model-model dengan kompleksitas yang berbeda-beda. Yang paling umum adalah:
Model struktural:

  • Daftar dengan nilai biner, enumerasi, numerik, string, dan lainnya.
  • Grafik dan struktur data jaringan

Model deskripsi perilaku:

  • Tujuh model formal untuk menentukan perilaku
  • Model formal untuk menentukan perilaku (misalnya, mesin negara terbatas)

Pada teori model mental
Pola-pola ini merupakan cerminan dari pola mental. Tingkat kedekatan model mental dengan model nyata harus ditangani oleh psikologi atau pedagogi teoretis. Sayangnya, penulis tidak mengetahui pekerjaan serius di bidang ini. (Ini tidak berarti bahwa pekerjaan seperti itu tidak ada).

Mengapa rekayasa perangkat lunak membutuhkan paradigma ujung ke ujung?


Kehadiran paradigma "lintas sektoral" membuka kemungkinan-kemungkinan berikut bagi para peserta untuk menggunakan paradigma proses menciptakan, memodifikasi, dan menggunakan perangkat lunak:

  • Kemampuan untuk semua peserta dalam proses menggunakan terminologi yang sama.
  • Kemampuan untuk membangun proses ujung ke ujung untuk menciptakan perangkat lunak baru.
  • Kemampuan untuk mengevaluasi parameter prosesnya, hasil antara dan mengelolanya.
.

Tujuan utama pengembangan paradigma


Masalah teoretis


Seperti yang telah berulang kali dicatat, termasuk dalam buku Kuhn [2], dalam kebanyakan kasus, para ilmuwan terlibat dalam memecahkan masalah potensial yang sedang dipecahkan, dan mereka cenderung untuk mengambil masalah yang tidak begitu jelas cara pendekatannya. Tapi ini persis tugas kita. Inilah yang utama:

  1. Definisi konstruktif dari konsep model mental.
  2. Menemukan kriteria konstruktif untuk menilai tingkat abstrak / idealitas vs. spesifisitas / materialitas model.
  3. Menemukan kriteria untuk memilih kandidat untuk peran model menengah dan tambahan.
  4. Seleksi dan pengembangan kriteria dan metode untuk membandingkan model dari berbagai jenis, termasuk pelacakan langsung dan mundur
  5. Pengembangan metode untuk transformasi model otomatis dan otomatis.

Tugas praktis


Seiring dengan tugas-tugas teoritis untuk pengembangan dan implementasi paradigma yang dijelaskan dalam praktik rekayasa perangkat lunak, perlu untuk menyelesaikan setidaknya masalah praktis berikut:

  1. Pembuatan alat untuk: a) Ekstraksi dan pemasangan model mental. b) Transformasi mental model secara otomatis dan otomatis menjadi model menengah. c) Jejak dan perkiraan perubahan dalam isi model yang dapat ditransformasikan
  2. Pembuatan literatur teknis dan pendidikan yang diperlukan dan materi pendidikan medial lainnya.
  3. Organisasi forum dan konferensi tentang hal ini

Kesimpulan


Artikel ini mencoba untuk mendefinisikan paradigma rekayasa perangkat lunak sebagai perwujudan gagasan. Kata untuk mendefinisikan (dan tidak terbuka) digunakan di sini bukan secara kebetulan. Bahkan, peserta dalam proyek-proyek TI telah lama terlibat dalam penciptaan, transformasi dan penggunaan model, mungkin tanpa disadari.

Dalam pengertian definisi Kuhn yang ketat, pendekatan yang dideskripsikan belum dapat mengklaim hak untuk disebut paradigma, tetapi hanya kandidat untuk paradigma, karena ia tidak memiliki komunitas luas orang yang mendukungnya dan sistem yang dikembangkan dengan baik dari model yang saling berhubungan. Namun, saya ingin percaya bahwa kekurangan akan segera diatasi.

Ini adalah artikel pertama dari serangkaian artikel yang direncanakan. Dalam artikel berikut ini saya akan berbicara tentang model mental dan menengah.

Sastra


1. Daftar Istilah Standar IEEE untuk Terminologi Rekayasa Perangkat Lunak, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. Struktur Revolusi Ilmiah. Edisi ke-3. Chicago, IL: University of Chicago Press, 1996.
3. Paradigma pemrograman: en.wikipedia.org/wiki/Programming_paradigm (negara bagian - 08/27/2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Paradigma Dan Model Rekayasa Perangkat Lunak Esai Teknologi Informasi
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state - 08.28.2018 )
6. Reifikasi (ilmu komputer) en.wikipedia.org/wiki/Reification_ (computer_science) (negara bagian - 08/27/2018)
7. Fedor Ivanovich Tyutchev. Silentium! (Silence (lat.), 1829.
8. Borovik, Alexandre. Matematika di bawah mikroskop: catatan tentang aspek kognitif dari praktik matematika. American Mathematical Society. ISBN-13: 978-0821847619.

Ilustrasi: geralt

Source: https://habr.com/ru/post/id425321/

More articles:


All Articles