Interfejs
Sučelje ili interfejs (engl. interface) zajednička je deljena granica, posredstvom koje dve ili više komponenti računarskog sistema vrše razmenu informacija. Razmena informacija može se odvijati između softvera, hardverskih komponenti, perifernih uređaja, ljudi ili kao kombinacija navedenih. Pojedine računarske komponente, poput ekrana osetljivih na dodir, mogu istovremeno i primati i slati podatke posredstvom interfejsa, dok neke druge poput mikrofona, jedino omogućavaju prijem podataka.[1]
Hardverski interfejs
[уреди | уреди извор]Hardverski interfejs je prisutan u mnogim uređajima poput: magistrala, uređaja za skladištenje podataka, ulazno-izlaznih uređaja itd. Tehnički, hardverski interfejs opisan je mehaničkim, električnim i logičkim signalima koji se razmenjuju na fizičkom međusklopu dva uređaja, kao i protokolima kojima se vrši sekvencija signala (signaliziranje).[2]
Standardan interfejs, poput SCSI, odvaja dizajn i primenu jedne hardverske komponente od dizajna i primene drugih hardverskih komponenti unutar istog računarskog sistema. Takav modularni pristup omogućava korisnicima i proizvođačima hardvera veliku fleksibilnost u implementaciji računarskog sistema.[2]
Hardverski interfejs može biti paralelan ili serijski. Kod paralelnog interfejsa prenos podataka vrši se kroz nekoliko provodnika istovremeno, dok se kod serijskog interfejsa prenos podataka vrši bajt po bajt korišćenjem jednog provodnika.
Softverski interfejs
[уреди | уреди извор]Pojam softverskog interfejsa, obuhvata široki raspon različitih tipova interfejsa, na različitim nivoima operativnog sistema.[3] Operativni sistem može posredovati u komunikaciji između korisnika i hardverskih komponenti ili programi (aplikacije) koji se pokreću pod određenim operativnim sistemom mogu zahtevati komunikaciju sa drugim programima, nitima istog programa (engl. threads) ili komunikaciju sa delovima samog operativnog sistema.
Dizajn i primena softverskog interfejsa u praksi
[уреди | уреди извор]Ključni princip prilikom dizajna softverskog interfejsa, jeste zabrana nekontrolisanog pristupa računarskim resursima i omogućavanje njihovog korišćenja isključivo kroz dobro definisane ulazne tačke (engl. entry points).[4] Pored zadovoljenja bezbednosnih zahteva, korišćenje softverskog interfejsa omogućava i jednostavnije, funkcionalnije korišćenje kompjuterskih resursa. Softverski interfejs omogućava da različiti programi (ili niti istog programa) dele zajedničke: konstante, tipove podataka, procedure, specifikacije izuzetaka i potpise metoda. Takođe, ponekad se javne varijable programa definišu kao deo softverskog interfejsa.
U toku dizajna i implementacije softverskog interfejsa, treba težiti ka zadovoljenju principa modularnosti. Interfejs programskog modula A mora biti definisano nezavisno od njegove implementacije.
Korisnički interfejs
[уреди | уреди извор]Korisnički interfejs predstavlja tačku interakcije između računara i čoveka što uključuje bilo koju proceduru interakcije (kao što su grafika, zvuk, položaj, kretanje i sl.) gde se podaci prenose između korisnika i računarskog sistema.
Reference
[уреди | уреди извор]- ^ IEEE 100 - The Authoritative Dictionary Of IEEE Standards Terms. NYC, NY, USA: IEEE Press. 2000. стр. 574—575. ISBN 0-7381-2601-2.
- ^ а б Blaauw, Gerritt A.; Brooks, Jr., Frederick P. (1997), „Chapter 8.6, Device Interfaces”, Computer Architecture-Concepts and Evolution, Addison-Wesley, стр. 489—493, ISBN 0-201-10557-8 See also: Patterson, David A.; Hennessey, John L. (2005), „Chapter 8.5, Interfacing I/O Devices to the Processor, Memory and Operating System”, Computer Organization and Design - The Hardware/Software Interface, Third Edition, Morgan Kaufmann, стр. 588—596, ISBN 1-55860-604-1
- ^ Venners, Bill (6. 6. 2005). „Leading-Edge Java: Design Principles from Design Patterns: Program to an interface, not an implementation - A Conversation with Erich Gamma, Part III”. http://www.artima.com/index.jsp: artima developer. Приступљено 3. 8. 2011. „Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that is a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away. ...”
- ^ Gamma; Helm; Johnson; Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. стр. 17–18.
| Државне | |
|---|---|
| Остале | |
