150
Osnovi Informacionih sistema i Softverskog inenjerstva 1/150 --------------------------------------------------------------------------- ---------------------------------------------------- Univerzitet u Novom Sadu Fakultet tehničkih nauka Novi Sad Katedra za računarske nauke i informatiku Prof.dr Branko Perišić OSNOVI INFORMACIONIH SISTEMA i SOFTVERSKOG INŽENJERSTVA Materijal za praćenje predavanja 2004/2005 Prof. dr Branko Perišić 1 Argumenti mogu imati podrazumeva nu vrednost

informacioni sistemi knjiga

Embed Size (px)

DESCRIPTION

informacioni sistemi knjiga

Citation preview

Page 1: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 1/110-------------------------------------------------------------------------------------------------------------------------------Univerzitet u Novom SaduFakultet tehničkih nauka Novi SadKatedra za računarske nauke i informatiku

Prof.dr Branko Perišić

OSNOVI INFORMACIONIH SISTEMA i

SOFTVERSKOG INŽENJERSTVA

Materijal za praćenje predavanja2004/2005

Novi SadFebruar 2005.g.

Prof. dr Branko Perišić 1

Page 2: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 2/110-------------------------------------------------------------------------------------------------------------------------------

Struktura predmeta i očekivani rezultati

Repetitorijum objektnog programiranja Elementi objektne platforme Objektno programiranje na jeziku C++

osnovni elementi Objektno programiranje na jeziku C++

napredni elementi

Osnovni pojmovi informacionih sistema

Pojam sistema, informacije i informacionog sitema.

Koncept savremene organizacije informacionih sistema.

Faze evolucije informacionih sistema.

Metodološki aspekti projektovanja informacionih sistema

Osnovni pojmovi softverskog inženjerstva

Prof. dr Branko Perišić 2

Page 3: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 3/110-------------------------------------------------------------------------------------------------------------------------------

S a d r ž a j

0. O procesu obrazovanja u inženjerstvu..............4

0.1. Osnovni principi rešavanja problema u inženjerstvu.......................................................................................................................... 5

1. Objekt-orijentisani pristup rešavanju problema i objektno programiranje........................................................................................................7

2. Osnovi softverskog inženjerstva...........................................................45

POGLED NA Softversko Inženjerstvo SA ASPEKTA PROIZVODA:................................................53

3. Osnovni pojmovi informacionih sistema......................................82

3.1. Značaj i uloga informatike u složenim organizacijama u svetlu primene upravljačkih informacionih sistema..............................82

3.2. Koncept savremene organizacije upravljačkih informacionih sistema.......................................................................................................86

3.3. Faze evolucije informacionih sistema........................................................87

3.4. Metodološki aspekti projektovanja informacionih sistema ..........93

Prof. dr Branko Perišić 3

Page 4: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 4/110-------------------------------------------------------------------------------------------------------------------------------

U v o d

0. O procesu obrazovanja u inženjerstvu

Proces obrazovanja uopšte, a posebno u oblasti inženjerstva, obuhvata u osnovi šest faza koje se nadovezuju jedna na drugu (Slika 1.1.).

Slika 1.1. Faze u procesu obrazovanja

(a) ZNANJE

Znanje je u osnovi određno skupom činjenica vezanih za određene pojmove i zajedničkom terminologijom koja te pojmove uvodi. U bilo kojoj oblasti ljudske delatnosti, a samim tim i u inženjerstvu, faza “sticanja znanja” prethodi ostalim fazama edukacije i predstavlja njihovu podlogu.

(b) SHVATANJE

Shvatanje predstavlja najniži nivo razumevanja pojmova, činjenica i terminologije, pri čemu je značajno uočavanje odnosa među pojmovima, načina prelaska sa jedne predstave na drugu i generisanje objašnjenja vezanih kako za pojmove tako i za njihove odnose i/ili veze. U ovoj fazi dolazi do usvajanja ili generisanja skupa APSTRAKCIJA odnosno GENERALIZACIJA vezanih za konkretnu oblast izučavanja.

(c) PRIMENA

Faza primene je prva faza u procesu edukacije u kojoj inženjerske discipline vide opravdanje svog postojanja. Svo akumulirano znanje prožeto shvatanjem kao “vezivnim materijalom” i iskazano kroz apstraktne i/ili uopštene postupke, u ovoj fazi se mora primeniti na KONKRETNU SITUACIJU. Zbog toga proces obrazovanja inženjera zahteva što je moguće pre PRIMENU usvojenog i shvaćenog u cilju REŠAVANJA POJEDINAČNIH PROBLEMA, RAZLIČITOG STEPENA SLOŽENOSTI, koji pripadaju klasi primerenoj do tada usvojenom i shvaćenom.

(d) ANALIZA

Analiza predstavlja aktivnost vezanu za identifikaciju sastavnih delova analiziranog sistema, odnosa među tim delovima i otkrivanje veza koje nisu eksplicitno iskazane. U inženjerskim disciplinama predstavlja fazu

Prof. dr Branko Perišić 4

Z N A NJ E

SHVATANJE

PRIMENA

ANALIZA

SINTEZAOCENA

Page 5: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 5/110-------------------------------------------------------------------------------------------------------------------------------obrazovanja koja uključuje primenu znanja, razumevanja i iskustva nastalog primenom, na nepoznate ili nedovoljno poznate situacije sa ciljem njihovog razumevanja i predstavljanja u formi pogodnoj za razumevanje strukture nepoznatog ili nedovoljno poznatog.

(e) SINTEZA

Sinteza predstavlja fazu u kojoj se vrši kombinovanje elemenata i delova u cilju kreiranja ranije nepoznate ili nejasne strukture. Ova faza rezultira PROIZVODOM nezavisno od forme njegovog predstavljanja.

(f) OCENA(EVALUACIJA)

Ova faza u procesu edukacije obezbeđuje podloge za kvalitativnu i kvantitativnu ocenu vrednosti METODA, PROCESA i PRODUKATA. U svakodnevnoj praksi smo svedoci OCENJIVANJA kvaliteta određene metode, procesa ili proizvoda od strane onih koji nisu prošli celokupan proces edukacije prema modelu sa Slike 1.1.

0.1.Osnovni principi rešavanja problema u inženjerstvu

Pojam INŽENJER izveden je iz latinskog termina:

IN GENIOSUS (u nepoznatom)

i može se slobodno prevesti kao “ ONAJ KOJI SE KREĆE PO NEPOZNATOM ”. Suština inženjerstva je upravo sadržana u njegovom imenu, biti inženjer znači stalno se kretati po nepoznatom, neistraženom ili nerealizovanom. Sa druge strane inženjerstvo predstavlja PRIMENJENU DISCIPLINU i kao posledicu te pretpostavke imamo potrebu STVARANJA u prisustvu ograničenja nametnutih od strane okruženja u kome se to stvaranje dešava.

Osnovni principi rešavanja problema u inženjerstvu proistiću iz primene metoda opažanja na konkretne situacije i predstavljaju prirodan način reagovanja čoveka na nepoznato okruženje.

Šta je PROBLEM?

Odgovor na gornje pitanje je vrlo teško generalno dati i nije nam ni namera da generalizujemo, budući da je neophodno obratiti posebnu pažnju na GENERIČKU OBLAST, kojoj konkretno inženjerstvo pripada, no moguće je izolovati određeni broj koraka koje je ISKUSTVENO potrebno izvršiti da bi se PROBLEM, kao odraz NEPOZNATOG, doveo u domen rešivog.

Inženjerstvo se zadovoljava JEDINO REŠAVANJEM PROBLEMA, te je celokupan postupak podređen REŠENJU. Normalna reakcija čoveka na nepoznato je STRAH. Normalna akcija - POBEĆI, no ako se odupremo iskonskoj potrebi da pobegnemo od nepoznatog prva prirodna reakcija je IDENTIFIKACIJA - ŠTA JE TO ŠTO NAS JE UPLAŠILO?

Dejstvo nepoznatog uzrokovalo je dakle odgovor koji je u biti analitičarski i predstavlja polaznu osnovu za uspešno rešavanje bilo kog problema. Ako uspemo identifikovati problem, bez obzira kako je on definisan, koju filozofsku kategoriju predstavlja ili kojoj oblasti pripada, postižemo smanjenje polazne neodređenosti, uvek prisutne u sklopu nepoznatog, što, kao posledicu, ima smanjenje ili potpuno eliminisanje “straha”.

Prof. dr Branko Perišić 5

Page 6: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 6/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 6

Page 7: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 7/110-------------------------------------------------------------------------------------------------------------------------------

POGLAVLJE 1.

1. Objekt-orijentisani pristup rešavanju problema i objektno programiranje

Smatra se da je složenost problema koje je neko u stanju da reši derektno srazmerna predmetu (šta?) i kvalitetu (kako?) apstrakcije kojom raspolaže. Svi programski jezici obezbeđuju podršku određenim apstraktnim kategorijama. Asemblerski jezik poseduje nizak nivo apstrakcije u odnosu na fizičku mašinu (hardware). Većina imperativnih programskih jezika (FORTRAN, BASIC, C) su samo apstrakcije asemblerskog jezika pa, iako predstavljaju značajan napredak u odnosu na asemblerski jezik, u biti njihove apstrakcija leže kategorije koje odgovaraju arhitekturi računarskog sistema a ne problema koji se rešava. U ovom slučaju, zadatak programera je da uspostavi korespondenciju između domena rešenja (apstraktnog modela mašine) i domena problema (apstraktnog modela realnog sveta). Napor koji je neophodno uložiti u ovo preslikavanje, a koji u jednom delu leži u samoj strukturi korišćenog programskog jezika, često nema adekvatnu valorizaciju budući da rezultira programima niskog stepena semantike.

Alternativa prethodno opisanom pristupu je modeliranje problem koji se rešava. Prvi programski jezici koji su razvijeni na problemskoj orijentaciji uvode specifične apstrakcije realnosti na kojima zasnivaju postupak preslikavanja domena problema u domen rešenja. Tipični primeri su sledeći pristupi:

1. Sve probleme je moguće apstrahirati listom i operacijama nad njom (LISP – LISt Processing).

2. Svi problemi su algoritamske prirode (APL-Algoritmic Programming Language).

3. Svi problemi se daju iskazata kao lanci odlučivanja (PROLOG – PROgramming LOGic).

4. Svi problemi se mogu iskazati kao skup apstraktnih ograničenja i manipulacija sa njima (Constraint Based Programming).

Svi navedeni pristupi predstavljali su dobra rešenja za određenu usku klasu problema za koju su objektivno i dizajnirani, no svaki pokušaj generalizacije i iskoraka van inicijalnog domena gotovo bez izuzetka rezultira neuspehom.

Prof. dr Branko Perišić 7

Page 8: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 8/110-------------------------------------------------------------------------------------------------------------------------------

Objekt-orijentisani pristup posebnim čini obezbeđenje alata i mehanizama za iskazivanje problema pojmovima iz domena problema. Apstrakcije koje ono uvodi su dovoljno opšte tako da programer nije ograničen jednim domenom primene.

Objekt-orijentisano programiranje:

Predstavlja implementacionu metodu kod koje su programi organizovani kao kooperativni skup objekata pri čemu svaki objekat predstavlja instancu neke klase iz hijerarhiji klasa nastale na bazi relacija nasleđivanja (inheritance).

Objekt-orijentisani dizajn:

Predstavlja projektantsku metodu koja obuhvata proces objekt-orijentisane dekompozicije i notaciju za iskazivanje logičkih i fizičkih kao i statičkih i dinamičkih modela posmatranog sistema.

Objekt-orijentisana analiza:

Predstavlja analitičarsku metodu koja zahteve(requirements) posmatra iz perspektive KLASA i OBJEKATA koji pripada domenu problema.

Razlikujemo četiri osnovna:

1. APSTRAKCIJA (Abstraction)2. ENKAPSULACIJA (Encapsulation)3. MODULARNOST (Modularity)4. HIJERARHIJA (Hierarchy)

i tri sporedna:

5. TIPIZACIJA (Typing)6. KONKURENCIJA (Concurency)7. PERSISTENCIJA (Persistency)

elementa objektnog modeliranja.

Prof. dr Branko Perišić 8

Page 9: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 9/110-------------------------------------------------------------------------------------------------------------------------------

Apstrakcija:

Apstrahiranje je osnovni način na koji ljudska bića izlaze na kraj sa složenošću (complexity). Ona proistiće iz uočavanja sličnosti između elemenata posmatranja, situacija ili procesa u stvarnom svetu i odluke da se skoncentrišemo na te sličnosti i za trenutak ignorišemo pojedinačne razlike koje postoje (Hoare C.A. R.).

Shaw definiše apstrakciju kao ‘’...pojednostavljeni opis ili specifikaciju sistema koja ističe neka a zanemaruje druga svojstva sistema’’.

Beryins, Gray i Neumann smatraju ‘’ da se bilo koji koncept kvalifikuje kao apstrakcija ako i samo ako se on može opisati, shvatiti i analizirati nezavisno od mehanizama koji će na kraju biti iskorišćeni za njegovu implementaciju.’’

Definicija: Apstrakcija određuje esencijalne karakteristike nekog

objekta po kojima se on razlikuju od drugih vrsta objekata i time omogučava njegovo jasno izolovanje posmatrano iz perspektive analitičara.

Prof. dr Branko Perišić 9

Page 10: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 10/110-------------------------------------------------------------------------------------------------------------------------------

Prema Alan Kay-u, čisto pristup objekt orijentisanom programiranju poseduje pet esencijalnih karakteristika:

1. Sve je objekat. Posmatrajmo objekat kao sofisticiranu promenljivu koja omogučava: uskladištenje vrednosti i podršku operacijama nad tom vrijednošću.

2. Program se transformiše u skup objekata koji sarađuju razmenom poruka. Poruku možemo posmatrati kao mehanizam poziva operacije nad objektima.

3. Svaki složeni objekat je izveden kao kolekcija objekata.

4. Svaki objekat pripada određenom tipu tj. predstavlja instancu KLASE (tip = klasa).

5. Svi objekti iste klase mogu primati iste poruke – polimorfizam.

Pojam klase:

Identični objekti, osim njihovog stanja u toku izvršenja programa, grupisani su u ‘’klase objekata’’. Kretiranje apstraktnog tipa podataka (klasa) predstavlja fundamentalni koncept objekt-orijentisanog programiranja. Apstraktni tipovi podataka se gotovo identično ponašaju kao i ugrađeni tipovi: moguće je kreirati ‘’promenljive’’ tog tipa (objekat ili instanca klase) i manipulisati sa njima (slanje poruka ili zahteva). Sve instance jedne klase (objekti) dele ista svojstva dok u isto vreme svaki objekat poseduje vlastiti identitet. There must be a way to make a request of the object so that it will do something, such as complete a transaction, draw something on the screen or turn on a switch. And each object can satisfy only certain requests. The requests you can make of an object are defined by its interface, and the type is what determines the interface. A simple example might be a representation of a light bulb:

Prof. dr Branko Perišić 10

Light

on()off()brighten()dim()

Type Name

Interface

Page 11: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 11/110-------------------------------------------------------------------------------------------------------------------------------

Light lt; lt.on();

The interface establishes what requests you can make for a particular object. However, there must be code somewhere to satisfy that request. This, along with the hidden data, comprises the implementation. From a procedural programming standpoint, it’s not that complicated. A type has a function associated with each possible request, and when you make a particular request to anobject, that function is called. This process is usually summarized by saying that you “send a message” (make a request) to an object, and the object figures out what to do with that message (it executescode). Here, the name of the type/class is Light, the name of this particular Light object is lt, and the requests that you can make of a Light object are to turn it on, turn it off, make it brighter or make it dimmer. You create a Light object by declaring a name (lt) for that object. To send a message to the object, you state the name of the object and connect it to the message request with a period (dot). From the standpoint of the user of a pre-defined class, that’s pretty much all there is to programming with objects. The diagram shown above follows the format of the UnifiedModeling Language (UML). Each class is represented by a box, with the type name in the top portion of the box, any data members that you care to describe in the middle portion of the box, and themember functions (the functions that belong to this object, which receive any messages you send to that object) in the bottom portion of the box. Often, only the name of the class and the public memberfunctions are shown in UML design diagrams, and so the middle portion is not shown. If you’re interested only in the class name, then the bottom portion doesn’t need to be shown, either.

The hidden implementationIt is helpful to break up the playing field into class creators (thosewho create new data types) and client programmers4 (the classconsumers who use the data types in their applications). The goalof the client programmer is to collect a toolbox full of classes to use4 I’m indebted to my friend Scott Meyers for this term.1: Introduction to Objects 31for rapid application development. The goal of the class creator isto build a class that exposes only what’s necessary to the clientprogrammer and keeps everything else hidden. Why? Because ifit’s hidden, the client programmer can’t use it, which means thatthe class creator can change the hidden portion at will withoutworrying about the impact to anyone else. The hidden portionusually represents the tender insides of an object that could easilybe corrupted by a careless or uninformed client programmer, sohiding the implementation reduces program bugs. The concept ofimplementation hiding cannot be overemphasized.In any relationship it’s important to have boundaries that arerespected by all parties involved. When you create a library, youestablish a relationship with the client programmer, who is also aprogrammer, but one who is putting together an application byusing your library, possibly to build a bigger library.If all the members of a class are available to everyone, then theclient programmer can do anything with that class and there’s noway to enforce rules. Even though you might really prefer that the

Prof. dr Branko Perišić 11

Page 12: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 12/110-------------------------------------------------------------------------------------------------------------------------------client programmer not directly manipulate some of the members ofyour class, without access control there’s no way to prevent it.Everything’s naked to the world.So the first reason for access control is to keep client programmers’hands off portions they shouldn’t touch – parts that are necessaryfor the internal machinations of the data type but not part of theinterface that users need in order to solve their particular problems.This is actually a service to users because they can easily see what’simportant to them and what they can ignore.The second reason for access control is to allow the library designerto change the internal workings of the class without worryingabout how it will affect the client programmer. For example, youmight implement a particular class in a simple fashion to easedevelopment, and then later discover that you need to rewrite it inorder to make it run faster. If the interface and implementation are32 Thinking in C++ www.BruceEckel.comclearly separated and protected, you can accomplish this easily andrequire only a relink by the user.C++ uses three explicit keywords to set the boundaries in a class:public, private, and protected. Their use and meaning are quitestraightforward. These access specifiers determine who can use thedefinitions that follow. public means the following definitions areavailable to everyone. The private keyword, on the other hand,means that no one can access those definitions except you, thecreator of the type, inside member functions of that type. private isa brick wall between you and the client programmer. If someonetries to access a private member, they’ll get a compile-time error.protected acts just like private, with the exception that aninheriting class has access to protected members, but not privatemembers. Inheritance will be introduced shortly.

Reusing the implementationOnce a class has been created and tested, it should (ideally)represent a useful unit of code. It turns out that this reusability isnot nearly so easy to achieve as many would hope; it takesexperience and insight to produce a good design. But once youhave such a design, it begs to be reused. Code reuse is one of thegreatest advantages that object-oriented programming languagesprovide.The simplest way to reuse a class is to just use an object of that classdirectly, but you can also place an object of that class inside a newclass. We call this “creating a member object.” Your new class canbe made up of any number and type of other objects, in anycombination that you need to achieve the functionality desired inyour new class. Because you are composing a new class fromexisting classes, this concept is called composition (or moregenerally, aggregation). Composition is often referred to as a “has-a”relationship, as in “a car has an engine.”1: Introduction to Objects 33Car Engine(The above UML diagram indicates composition with the filleddiamond, which states there is one car. I will typically use a simplerform: just a line, without the diamond, to indicate an association.5)Composition comes with a great deal of flexibility. The memberobjects of your new class are usually private, making theminaccessible to the client programmers who are using the class. Thisallows you to change those members without disturbing existing

Prof. dr Branko Perišić 12

Page 13: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 13/110-------------------------------------------------------------------------------------------------------------------------------client code. You can also change the member objects at runtime, todynamically change the behavior of your program. Inheritance,which is described next, does not have this flexibility since thecompiler must place compile-time restrictions on classes createdwith inheritance.Because inheritance is so important in object-orientedprogramming it is often highly emphasized, and the newprogrammer can get the idea that inheritance should be usedeverywhere. This can result in awkward and overly-complicateddesigns. Instead, you should first look to composition whencreating new classes, since it is simpler and more flexible. If youtake this approach, your designs will stay cleaner. Once you’ve hadsome experience, it will be reasonably obvious when you needinheritance.5 This is usually enough detail for most diagrams, and you don’t need to get specificabout whether you’re using aggregation or composition.

Inheritance:reusing the interfaceBy itself, the idea of an object is a convenient tool. It allows you topackage data and functionality together by concept, so you canrepresent an appropriate problem-space idea rather than beingforced to use the idioms of the underlying machine. These conceptsare expressed as fundamental units in the programming languageby using the class keyword.It seems a pity, however, to go to all the trouble to create a classand then be forced to create a brand new one that might havesimilar functionality. It’s nicer if we can take the existing class,clone it, and then make additions and modifications to the clone.This is effectively what you get with inheritance, with the exceptionthat if the original class (called the base or super or parent class) ischanged, the modified “clone” (called the derived or inherited or subor child class) also reflects those changes.BaseDerived(The arrow in the above UML diagram points from the derivedclass to the base class. As you will see, there can be more than onederived class.)A type does more than describe the constraints on a set of objects; italso has a relationship with other types. Two types can havecharacteristics and behaviors in common, but one type may containmore characteristics than another and may also handle moremessages (or handle them differently). Inheritance expresses thissimilarity between types using the concept of base types and1: Introduction to Objects 35derived types. A base type contains all of the characteristics andbehaviors that are shared among the types derived from it. Youcreate a base type to represent the core of your ideas about someobjects in your system. From the base type, you derive other typesto express the different ways that this core can be realized.For example, a trash-recycling machine sorts pieces of trash. Thebase type is “trash,” and each piece of trash has a weight, a value,and so on, and can be shredded, melted, or decomposed. From this,more specific types of trash are derived that may have additionalcharacteristics (a bottle has a color) or behaviors (an aluminum canmay be crushed, a steel can is magnetic). In addition, some

Prof. dr Branko Perišić 13

Page 14: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 14/110-------------------------------------------------------------------------------------------------------------------------------behaviors may be different (the value of paper depends on its typeand condition). Using inheritance, you can build a type hierarchythat expresses the problem you’re trying to solve in terms of itstypes.A second example is the classic “shape” example, perhaps used in acomputer-aided design system or game simulation. The base typeis “shape,” and each shape has a size, a color, a position, and so on.Each shape can be drawn, erased, moved, colored, etc. From this,specific types of shapes are derived (inherited): circle, square,triangle, and so on, each of which may have additionalcharacteristics and behaviors. Certain shapes can be flipped, forexample. Some behaviors may be different, such as when you wantto calculate the area of a shape. The type hierarchy embodies boththe similarities and differences between the shapes.36 Thinking in C++ www.BruceEckel.comShapedraw()erase()move()getColor()setColor()Circle Square TriangleCasting the solution in the same terms as the problem istremendously beneficial because you don’t need a lot ofintermediate models to get from a description of the problem to adescription of the solution. With objects, the type hierarchy is theprimary model, so you go directly from the description of thesystem in the real world to the description of the system in code.Indeed, one of the difficulties people have with object-orienteddesign is that it’s too simple to get from the beginning to the end. Amind trained to look for complex solutions is often stumped by thissimplicity at first.When you inherit from an existing type, you create a new type.This new type contains not only all the members of the existingtype (although the private ones are hidden away and inaccessible),but more importantly it duplicates the interface of the base class.That is, all the messages you can send to objects of the base classyou can also send to objects of the derived class. Since we know thetype of a class by the messages we can send to it, this means thatthe derived class is the same type as the base class. In the previousexample, “a circle is a shape.” This type equivalence via inheritanceis one of the fundamental gateways in understanding the meaningof object-oriented programming.1: Introduction to Objects 37Since both the base class and derived class have the same interface,there must be some implementation to go along with that interface.That is, there must be some code to execute when an object receivesa particular message. If you simply inherit a class and don’t doanything else, the methods from the base-class interface come rightalong into the derived class. That means objects of the derived classhave not only the same type, they also have the same behavior,which isn’t particularly interesting.You have two ways to differentiate your new derived class fromthe original base class. The first is quite straightforward: Yousimply add brand new functions to the derived class. These newfunctions are not part of the base class interface. This means thatthe base class simply didn’t do as much as you wanted it to, so youadded more functions. This simple and primitive use forinheritance is, at times, the perfect solution to your problem.

Prof. dr Branko Perišić 14

Page 15: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 15/110-------------------------------------------------------------------------------------------------------------------------------However, you should look closely for the possibility that your baseclass might also need these additional functions. This process ofdiscovery and iteration of your design happens regularly in objectorientedprogramming.

Prof. dr Branko Perišić 15

Page 16: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 16/110-------------------------------------------------------------------------------------------------------------------------------

Mehanizam kontrole pristupa Enkapsulacija

(skrivanje informacija – Information hiding) OO jezici pružaju mogućnost kontrole pristupa atributima i

metodama klase, čime se postiže mogućnost skrivanja internih detalja realizacije klase (enkapsulacija).

Nivoi pristupa: public – javni atributi i metode, moguć pristup spolja (od

strane korisnika klase) protected – zaštićeni atributi i metode, moguć pristup

samo od strane klasa-naslednika private – strogo privatni atributi i metode, moguć pristup

samo od strane metoda te klase

Primer:

class Student {protected:

int BrojIndeksa;char Prezime[20];char Ime[20];int GodinaStudija;

// i ostali atributi......public: int PreuzmiBrojIndeksa(void);

void UpisiBrojIndeksa(int ABrojIndeksa);

// i ostale metode......};

int main(int argc, char* argv[]){

Student S; //Objekat – instanca klase Student //jedini način da se promeni broj indeksa: S.PostaviBrojIndeksa(10001);

Prof. dr Branko Perišić 16

Page 17: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 17/110------------------------------------------------------------------------------------------------------------------------------- S.BrojIndeksa = 10001; // Kompajler javlja grešku kod pokušaja direktnog pristupa zaštićenom atributu!!!

}

Prof. dr Branko Perišić 17

Page 18: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 18/110-------------------------------------------------------------------------------------------------------------------------------

Konstruktori i destruktori

Problem: Pošto nije dozvoljen direktan pristup privatnim atributima klase kako je moguće izvršiti inicijalizaciju objekta klase odnosno njegovih atributa?

1. Definisati javnu metodu koja to realizuje?

Primer: void student::init(int BrojIndeksa,charPrezime[20],charIme[20],

int GodinaStudija);

Problem: Da li će svaki korisnik klase pozvati metodu init pri instanciranju objekta?

2. Obezbediti automatsko inicijalizovanje pri instanciranju.

Posebna metoda (funkcija članica) koja obezbeđuje inicijalizaciju objekta klase naziva se KONSTRUKTOR (constructor).Implicitno se poziva pri kreiranju objekta klase.Ima isto ime kao klasa, nema tip koji vraća, može imati argumente i može se preklapati.Primer: class Student {protected:

int BrojIndeksa;char Prezime[20];char Ime[20]; int GodinaStudija; // i ostali atributi......public: int PreuzmiBrojIndeksa(void); void UpisiBrojIndeksa(int ABrojIndeksa); Student(int IBrojIndeksa,charIPrezime[20],char IIme[20],int IGodinaStudija); // Konstruktor // i ostale metode......};

Prof. dr Branko Perišić 18

Page 19: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 19/110-------------------------------------------------------------------------------------------------------------------------------

Inicijalizacija atributa:Atributi se inicijalizuju pri instanciranju objekta, pre izvršavanja tela konstruktora,

po redosledu deklarisanja. Vrijednosti na koje se inicijalizuju atributi navode se

u zaglavlju konstruktora.

Kako će se inicijalizovati atributi koji su KONSTANTNI (inicijalizacija nije dozvoljena), koji su REFERENCE (inicijalizacija nije moguća) ili koji su INSTANCE neke druge KLASE (inicijalizacija nije definisana)?

Primer:class Y { int y;public: Y(int i) {y=i;} //konstruktor Y::Y;};class X { const int xi; //konstanta; int &ri; //referenca; Y xy; //objekat klase Y;public: X(int &); //konstruktor X::X;};

X::X (int &i) { xi = i; //xi je konstanta! ri = i; //inicijalizacija reference?! //??? // a kako pozvati Y::Y};

X::X (int &i): xi(i), ri(i), xy(i) {};

Prof. dr Branko Perišić 19

Inicijalizacija OBJEKTOM i

Page 20: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 20/110-------------------------------------------------------------------------------------------------------------------------------

Konstruktor kopije (copy constructor)

Kada se objekat x1 klase X inicijalizuje drugim objektom x2 iste klase C++ po definiciji obavlja prostu inicijalizaciju dodelom vrednosti atributa objekta x2 atributima objekta x1.

Ako su atributi pokazivači ili reference na pridruženi dinamički objekat proizvoljnog tipa T, prosta inicijalizacije će jedino postaviti vrednost pokazivača.

Prof. dr Branko Perišić 20

Objekat x2 klase XDinamički objekat tipa T

za objekat x2

Objekat x1 klase X

Prosta inicijalizacija

Dinamički objekat tipa T za objekat x1

COPY

Ispravna inicijalizacija

Page 21: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 21/110-------------------------------------------------------------------------------------------------------------------------------

KONSTRUKTOR KOPIJE je konstruktor klase X koji se može pozvati samo sa jednim argumentom tipa X a poziva se uvek kada se neki objekat inicijalizuje drugim objektom iste klase.

Primer:

class X { int *pi;public: X(int i): pi(new int(i)) {} //konstruktor; X(const X&); //konstruktor kopije;

//....};

X::X(const X &x) { //kreira se dinamički objekatpi=new int(*x.pi); // pi je pokazivač na

njega};

X f(X x) {

X x2=x1; //poziva se konstruktor kopije za x2//...

return x2; //poziva se konstruktor kopije za //za privremeni objekat u koji se //smešta rezultat

};

void g() {X xa=3, xb=1; //poziva se konstruktorxa=f(xb); //poziva se konstruktor kopije samo za

//formalni argument x1 //u xa seprepisujeprivremeni objekat

//koji čuva vraćenu vrednost};

X::X(X) //konstruktor koji unosi beskonačnu rekurziju

Prof. dr Branko Perišić 21

Page 22: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 22/110-------------------------------------------------------------------------------------------------------------------------------

Destruktor

Posebna metoda koja obezbeđuje ukidanje objekta klase naziva se DESTRUKTOR (destructor).Ima isto ime kao klasa sa znakom ~ ispred. Nema argumente, nema tip koji vraća i ne može se preklapati. Redosled poziva destruktora je obrnut od redosleda poziva konstruktora.Kada se sve poziva destruktor:Kada se na kraju izvršavanja programa ukida statički objekat.

Kada se izlazi iz oblasti važenja objekta. Kada se ukida neki objekat klase. Kada se dinamički kreiran objekat (new) ukida operatorom

delete, neposredno pre oslobađanja dela dinamičke memorije koju je zauzeo.

Kada se ukida privremeni objekat (vraćene vrijednosti iz funkcija).

Kada se ukida neko objekat klase naslednika poziva se destruktor klase predka koji ukida deo nasleđen od klase predka.

Kada se destruktor eksplicitno pozove.

Destruktori se najčešće koriste kada objekti neke klase sadže reference ili pokazivače na objekte koji su im pridruženi. To mogu biti dinamički objekti nekog drugog tipa ili neki sistemski resurs (semafor, buffer i sl.) ili kada je pri ukidanju objekta potrebno obaviti neke dodatne operacije.Primer:class X { int *pi; public: X(int i): pi(new int(i)){} //konstruktor; X(const X&): pi(new int(*x.pi)){} //konstr.kopije; ~X() {delete pi;} //destruktor //....};

Prof. dr Branko Perišić 22

Page 23: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 23/110-------------------------------------------------------------------------------------------------------------------------------

Preklapanje (prekrivanje) operatoraNa ugrađene tipove u sklopu C++ moguće je primeniti podržane

operatore.

Kod definisanja korisničkih tipova standardne operatore je nekada neophodno redefinisati ako se želi zadržati semantika operatora ali promeniti način izvođenja operacija.

Ako se u programu definiše NOVO ZNAČENJE OPERATORA tada kažemo de je on PREKLOPLJEN ili PREKRIVEN (overloaded).

Značenje operatora za korisničke tipove definiše se posebnim funkcijama koje se nazivaju operatorske funkcije (operator functions).

Ograničenja:

Operatorska funkcija mora biti članica klase ili imati bar jedan argument tipa klase, nabrajanja,referenci na klasu ili reference na nabrajanje.

Nije moguće promeniti ugrađeni broj operanada, prioritet i način grupisanja (asocijativnost).

Ne mogu se predefinisati značenja operatora za ugrađene tipove.

Ne mogu se uvoditi operatori koji ne postoje u jeziku.

Prof. dr Branko Perišić 23

Page 24: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 24/110-------------------------------------------------------------------------------------------------------------------------------

Primer:

class complex { double realni,imaginarni;public:

complex(double r=0,double i=0): realni(r),imaginarni(i) {} //konstruktorfriend complex operator+ (complex,complex);friend complex operator- (complex,complex);friend complex operator* (complex,complex);

};

complex operator+ (complex c1, complex c2) {return complex(c1.realni+c2.realni, c1.imaginarni+c2.imaginarni);

}

complex operator- (complex c1, complex c2) {return complex(c1.realni-c2.realni,c1.imaginarni-c2.imaginarni);

}

complex operator* (complex c1, complex c2) {return complex(c1.realni*c2.realni-c1.imaginarni*c2.imaginarni,c2.realni*c1.imaginarni+ c1.realni*c2.imaginarni);

}

Nije dozvoljeno pleklapanje sledećih operatora:

. .* :: ?: sizeof

Operatorske funkcije se mogu pozivati eksplicitno ( c1 operator+ c2)

ili implicitnoc1 + c2

Prof. dr Branko Perišić 24

Page 25: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 25/110-------------------------------------------------------------------------------------------------------------------------------

Mehanizam Nasleđivanja(generalizacija/specijalizacija)

Ukoliko je klasa B jedna vrsta klase A, na način da:

o poseduje sve atribute klase A, ali i neke dodatne i/ili o poseduje dodatne metode u odnosu na klasu A i/ili

redefiniše postojeće

kažemo da je klasa B specijalizacija klase A.

Primer:

Student-prodekan je specijalizacija studenta, jer poseduje sve što i student, ali ima sopstvene atribute i metode koje podržavaju njegove dodatne aktivnosti u okviru studentskog organizovanja

U okviru OO programskih jezika, specijalizovana klasa se realizuje uz oslonac na mehanizam nasleđivanja.Specijalizovana klasa se naziva naslednik i/ili potomak, a osnovna predak.

Primer nasleđivanja:

class StudentProdekan: public Student {int GodinaMandata;

// Nasledio je sve atribute i metode od studenta, i// uveo je svoj dodatni atribut: godinu mandata}

Ne nasleđuju se: konstruktori, destruktori, operator=, kao i funkcije deklarisane sa klauzulom friend.

Nasleđivanje se predstavlja usmerenim grafom

Prof. dr Branko Perišić 25

Page 26: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 26/110-------------------------------------------------------------------------------------------------------------------------------

(hijerarhija klasa)

Pristup elementima klase

ime_klase::ime_člana_klasePrivatno, zaštićeno i javno izvođenje klasa

Koncept nasleđivanja u sklopu jezika C++ razdvojen je od koncepta kontrole prava pristupa.

Prof. dr Branko Perišić 26

A

B C

D E

F

Klasa A je direktni predak klasa B i C, dok je za klase D, E i F ona

indirektni predak

Klasa F je specijalizacija klasa

B, D i E(multiple inheritance)

Page 27: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 27/110-------------------------------------------------------------------------------------------------------------------------------

Ako je klasa B potomak klase A tada objekti klase B uvek nasleđuju sve članove (atribute i metode) klase A, bez obzira na način ostvarivanja nasleđivanje (public, protected, private).

Zavisno od načina realizacije nasleđivanja pristup određenim nasleđenim članovima (atributi i metode) je negde dozvoljen a negde nije.

Javno (public) izvođenje: Javni članovi (atributi i metode) klase pretka (osnovne klase) ostaju javni članovi klase potomka (izvedene klase). Zaštićeni (protected) članovi klase pretka ostaju zaštićeni članovi klase potomka. (Realizuje koncept nasleđivanja – is a cind of)

Zaštićeno (protected) izvođenje: Javni i zaštićeni članovi (atributi i metode) klase pretka (osnovne klase) postaju zaštićeni (protected) članovi klase potomka (izvedene klase).(Uvedeno je radi potpunosti semantike jezika C++.Realno nema nikakvu posebnu ulogu.)

Privatno (private) izvođenje: Javni i zaštićeni članovi (atributi i metode) klase pretka (osnovne klase) postaju privatni (private) članovi klase potomka (izvedene klase). (Realizuje koncept sadržavanja – javni članovi osnovne klase su sakriveni u izvedenoj klasi i nisu vidljivi korisnicima. Objekti izvedene klase sadrže objekat osnovne klase u sebi - is a part of).

Privatni članovi (atributi i metode) klase pretka (osnovne klase) ostaju uvek privatni (private) članovi te klase tako da im direktno ne mogu pristupati izvedene klase.

Primer 1.:

class Osnovna { int pb;

Prof. dr Branko Perišić 27

Page 28: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 28/110-------------------------------------------------------------------------------------------------------------------------------public: int jb; void put(int x) { pb=x;}};

class Izvedena: public Osnovna { int pd;public: void write(int a, int b, int c) { pd= a; jb= b; pb= c; //pogrešno pb je private put(c); //ispravno pb-u se može //pristupiti jedino metodom }};

Primer 2.:

class Osnovna { int pb;protected: int zb;public: int jb; void put(int x) { pb=x;}};

class Izvedena: public Osnovna { int pd;public: void write(int x) { jb=zb=x; //ok! javni i zaštićeni su dostupni pb= x; //pogrešno pb je private }}; void f(x) { Osnovna b; b.zb=5; // pristup zaštićenom članu!}

Prof. dr Branko Perišić 28

Page 29: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 29/110-------------------------------------------------------------------------------------------------------------------------------

Realizacija nasleđivanja

Unutar objekta izvedene klase (zapravo strukture koja sadrži podatke članove)postoji podobjekat osnovne klase (zapravo struktura koja sadrži podatke članova osnovne klase).

Primer 1.:

class A { int a;public: void f();};Objekat ove klase realizuje se kao struktura podataka koja sadrži samo podatak član (jedan celi broj).

Primer 2.:

class B : public A { int b;public: void g();};class C : private B { int c;public: void h();};Objekat klase C realizuje se na sledeće načine:

Prof. dr Branko Perišić 29

int a;

int a;

int b;

int c;

int c;

int b;

int a;

Page 30: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 30/110-------------------------------------------------------------------------------------------------------------------------------

Konstruktori i destruktori izvedenih klasa

Redosled izvršavanja konstruktora pri kreiranju objekta izvedene klase:

1. Poziv konstruktora osnovne klase.2. Inicijalizacija članova po redosledu

deklarisanja.3. Izvršavanje tela konstruktora izvedene klase.

Redosled izvršavanja destruktora pri ukidanju objekta izvedene klase:

1. Izvršavanje tela destruktora izvedene klase.2. Ukidanje članova, po redosledu suprotnom od

redosleda inicijalizacije.3. Poziv destruktora osnovne klase.

Primer:#include <iostream.h>class X { //...public: X() {cout<<”Konstruktor klase X.\n”;} ~X() {cout<<”Destruktor klase X.\n”;}};class Osnovna { //...public: Osnovna() {cout<<”Konstruktor Osnovne klase.\n”;} ~Osnovna() {cout<<”Destruktor Osnovne klase.\n”;}};class Izvedena { X px; //...public: Izvedena() {cout<<”Konstruktor Izvedene klase.\n”;} ~Izvedena(){cout<<”Destruktor Izvedene klase.\n”;}};void main() { Izvedena d;}

Prof. dr Branko Perišić 30

Page 31: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 31/110-------------------------------------------------------------------------------------------------------------------------------

Šta će se pojaviti na standardnom izlazu?

Prof. dr Branko Perišić 31

Page 32: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 32/110-------------------------------------------------------------------------------------------------------------------------------Kao posledica kreiranja objekta d klase Izvedena u skladu sa pravilima pozivanja konstruktora biće pozvan konstruktor Osnovne klase.

(Ispis: Konstruktor Osnovne klase.)

Nakon toga sledi inicijalizacija članova Osnovne klase. Po okončanoj inicijalizaciji članova Osnovne klase sledi inicijalizacija članova izvedene klase. Kako izvedena klase sadrži objekat px klase X aktivira se konstruktor klase X.

(Ispis: Konstruktor klase X.)

Nakon inicijalizacije članova objekta px sledi inicijalizacija ostalih članova Izvedene klase što je zadatak konstruktora Izvedene klase.

(Ispis: Konstruktor Izvedene klase.)

Kako u telu main() nema više niti jedna operacija program se završava čime se pojavljuje potreba za ukidanjem objekta d Klase Izvedena. U skladu sa principima nasleđivanja aktivira se destruktor Izvedene klase.

(Ispis: Destruktor Izvedene klase.)

Kako je u sklopu objekta d nastao objekat px klase X neophodno ga je ukinuti. To se obavlja automatski pozivom destruktora klase X.

(Ispis: Destruktor klase X.)

Napokon, pošto je objekat d nasledio atribute klase Osnovna stekli su se uslovi za njihovo ukidanje pa se poziva destruktor Osnovne klase.

(Ispis: Destruktor Osnovne klase.)

Prof. dr Branko Perišić 32

Page 33: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 33/110-------------------------------------------------------------------------------------------------------------------------------

Višestruko nasleđivanje(Multiple inheritance)

Višestruko nasleđivanje podrazumeva situaciju u kojoj jedna klasa (izvedena) nesleđuje osobine više drugih (osnovnih) klasa.

C++ višestruko nasleđivanje realizuje mehanizmom višestrukog izvođenja, pod istim uslovom kao kod jednostavnog nasleđivanja.

Deklaracija višestrukog nasleđivanja u C++ se realizuje navođenjem svih osnovnih klasa u zaglavlju izvedene klase.

Značenje načina izvođenja (public, private ili protected) je identično kao kod jednostavnog izvođenja.

Primer: (pogledati hijerarhiju strana 10.)class KlasaA { int a; //...};class KlasaB: public KlasaA { int b; //...};class KlasaC : public KlasaA { int c; //...};

class KlasaD: public KlasaC { int d; //...};class KlasaE: public KlasaC { int e; //...};class KlasaF: public KlasaB, public KlasaD, private KlasaE {

//...};

Prof. dr Branko Perišić 33

Page 34: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 34/110-------------------------------------------------------------------------------------------------------------------------------

Višestruki podobjekti:

U primeru hijerarhije (strana 10.) KlasaF nasleđuje KlasuA po tri indirektne grane:

1. Kao direktni naslednik KlaseB koja je izvedena iz KlaseA.

2. Kao direktni naslednik KlaseD koja je izvedena iz KlaseC, koja je izvedena iz KlaseA.

3. Kao direktni naslednik KlaseE koja je izvedena iz KlaseC, koja je izvedena iz KlaseA.

A B C D E F

Dinamička struktura koja opisuje objekat KlaseF sadrži u sebi višestruke članove nasleđenih klasa tako da je za referenciranje pojedinih članova neophodno definisati potpunu putanju (pathname).

F::B::a = F::E::c //Koja je posledica?

Prof. dr Branko Perišić 34

a a

b

a

c

a

c

d

a

c

e

a

b

a

c

d

a

c

e

B

D

E

f

Page 35: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 35/110-------------------------------------------------------------------------------------------------------------------------------

Virtuelne osnovne klase

Ako je potrebno da izvedena klasa poseduje samo jedan podobjekat indirektne osnovne klase tada je neophodno tu osnovnu klasu deklarisati kao virtuelnu.class A { //...};class B: virtual public A {//...};class C: virtual public A {//...};class D : public A, public B {//...}; A B C DOsnovnu klasu treba deklarisati kao virtualnu kad god se iz te osnovne klase izvodi vi še klasa, a iz njih se višestruko izvodi neka zajednička klasa i još je potrebno da objekti izvedenih klasa imaju samo jedan podobjekat osnovne klase.

Prof. dr Branko Perišić 35

Page 36: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 36/110-------------------------------------------------------------------------------------------------------------------------------

Neka klasa može imati i virtuelne i nevirtuelne indirektne osnovne klase.

Primer:

class A { //...};class B: virtual public A {//...};class C: virtual public A {//...};class D : public A {//...};

class E :public B,public C,public D,public A {//...};

Klase E ima tri podobjekta klase A pri čemu je jedan zajednički za podobjekte B i C, drugi je poseban za podobjekat D dok je treći sopstveni za objekat Z.

A B C D E

A A

B C D A

E

Prof. dr Branko Perišić 36

a a

b

-sizeof(a)

a

c

-sizeof(a)

a

d

a

b

c

z

-sizeof(a)

a

a

d

-sizeof(b)

Page 37: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 37/110-------------------------------------------------------------------------------------------------------------------------------

Principi inicijalizacije kod višestrukog nasleđivanja

1. Inicijalizacije osnovnih klasa:1.1. Virtuelne osnovne klase:

o po redosledu pojavljivanja u grafu izvođenja po dubini (počev od poslednje izvedene klase), sleva u desno.

o inicijalizuje ih samo poslednja izvedena klasa. Ostale preskaču njihovu inicijalizaciju.

1.2. Nevirtualne direktne osnovne klaseo po redosledu deklarisanja u deklaraciji klase

2. Inicijalizacije članova izvedene klase:o po redosledu deklarisanja u deklaraciji klase

3. Telo konstruktora izvedene klase

Primer (1.):

class A {public: A(int);};class B {public: B(int);};class X : public A, public B {public: X(int i): A(i+1),B(i+2) {/*...*/} //Konstruktor};

Najpre se poziva konstruktor osnovnih klasa (A i B) po redosljedu po kome su deklarisane bez obzira na redosled inicijalizatora u zaglavlju konstruktora. Posle toga se pozivaju konstruktori članova izvedene klase i na kraju se izvršava telo konstruktora izvedene klase.

Prof. dr Branko Perišić 37

Page 38: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 38/110-------------------------------------------------------------------------------------------------------------------------------Navođenjem inicijalizatora u konstruktoru izvedene klase mogu se jedino inicijalizovati direktne osnovne klase i članovi nasleđeni od osnovnih klasa.

Vurtuelne osnovne klase:

Primer (2.):

class V {public: V(int);};class A : virtual public V {public: A(int i): V(i);};

class B : virtual public V {public: B(int i): V(i);};class X : public A, public B, private virtual V{public: X(int i):A(i),B(i),V(i) {/*...*/} //Konstruktor};

Objekat klase X poseduje samo jedan podobjekat virtuelne osnovne klase V. Kada se instancira objekat klase X (poslednja izvedena klasa), najpre se inicijalizuje podobjekat tipa V iz konstruktora klase X. Zatim se poziva konstruktor klase A koji ne vrši inicijalizaciju podobjekta V. Posle toga se poziva konstruktor klase B koji tekođe ne inicijalizuje podobjekat V. Na kraju se izvršava telo konstruktora klase X. Na taj način se podobjekat V inicijalizuje samo jednom i to od strane konstruktora najdublje deklarisane izvedene klase(most derived class).

Pravila:1. Ako se prilikom projektovanja hijerarhije klasa

predviđa višestruko nasleđivanje, a zahtevana je deoba informacija enkapsuliranih u posmatranoj osnovnoj klasi, osnovna klasa se treba deklarisati kao virtuelna.

2. Ako je hijerarhija klasa duboka, poželjno je da osnovna klasa poseduje podrazumjevani

Prof. dr Branko Perišić 38

Page 39: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 39/110-------------------------------------------------------------------------------------------------------------------------------

konstruktor. Ako to nije moguće, tada u sklopu svake izvedene klase treba iskoristiti private virtual deklaraciju za tu osnovnu klasu.

Prof. dr Branko Perišić 39

Page 40: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 40/110-------------------------------------------------------------------------------------------------------------------------------

Polimorfizam

Polimorfizam je mehanizam OO jezika koji omogućava izvršavanje metode-naslednika (potomka – child), mada se objektu pristupa kao da je u pitanju predak (parent).

Pravilno iskorišćen, ovaj mehanizam pruža mogućnost uključivanja novih klasa u projekat, bez potrebe izmene postojećih klasa

Funkcije (metode) članice izvedene klase (child) koje imaju novu verziju u sklopu izvedene klase nazivaju se virtualnim funkcijama (metodama). Deklaracija virtual ispred deklaracije funkcije (metode).

Polimorfizam omogućava ponovno korišćenje koda (code reusability).

U sklopu jezika C++ polimorfizam je podržan konceptima virtualnih metoda (virtual methode) i dinamičkog povezivanja (dynamic binding).

Primer:

geometrijski lik

krug trougao kvadrat linija

Svi znaju da se iscrtaju (metoda draw()) ali se svaki od njih iscrtava različito. Pretpostavimo da imamo crtež koja sadrži (contains) proizvoljan broj različitih geometrijskih likova a da je implementacija kolekcije

Prof. dr Branko Perišić 40

Page 41: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 41/110-------------------------------------------------------------------------------------------------------------------------------

obavljena nizom pokazivača na pojedinačne objekte (geometrijske likove).

Kako iscrtati crtež?Rešenje:

void draw_painting () { for (int i=0; i< figure_number;i++)

figure_array[i]-> draw();}Virtuelne metode:

Metode osnovne klase koje se u izvedenim klasama mogu realizovati specifično za svaku izvedenu klasu nazivaju se vurtuelnim metodama. Deklarišu se ključnom reči virtual ispred identifikatora metode osnovne klase. Ove metode se ne povezuju u izvršnu verziju u trenutku prevođenja već u trenutku izvršavanja (dinamičko povezivanje – dynamic binding). Nije dozvoljeno da se funkcija izvedene klase razlikuje od funkcije osnovne klase po tipu rezultata koji vraća.

Izvedena klasa može ali ne mora definisati svoju verziju virtuelne metode osnovne klase.

Kada se poziva virtuelna metoda objekta izvedene klase, uvek se izvršava verzija svojstvena toj klasi, bez obzira što se tom objektu možda pristupa preko pokazivača ili reference na osnovnu klasu (polimorfizam).

Primer:class B {public : virtual void vf1(); virtual void vf2(); virtual void vf3();

void f();};

class D: public B {public : void vf1(); //nova verzija metode vf1; void vf2(int); // sakriva B::vf2; int vf3(); //greška: razlika u tipu rezultata;

void f(); // nije virtuelna metoda!;};void main() { D d; B *pb = &d; //standardna konverzija D* u B*; pb -> vf1(); //poziva se D::vf1()(pb je pointer na D);

Prof. dr Branko Perišić 41

Page 42: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 42/110------------------------------------------------------------------------------------------------------------------------------- pb -> vf2(); //poziva se B::vf2()(jer vf2 u D sakriva); pb -> f(); //poziva se B::f();}

Zašto je d.vf2() pogrešno?

Poziv virtuelne metode se razrešava prema objektu na koji ukazuje pokazivač (ili na koji upuzuje referenca), a ne prema tipu tog pokazivača (ili reference).

Poziv nevirtuelne funkcije se razrešava u odnosu na tip pokazivača (ili reference), a ne u odnosu na tip objekta na koji pokazuje taj pokazivač (ili na koji upućuje referenca).

Eksplicitni poziv metode sa kvalifikatorom ime_klase::ime_metode ne aktivira virtuelni mehanizam (tada se poziva verzija metode klase koja je eksplicitno navedena).

Virtuelni mehanizam omogućava da se sva zajednička svojstva različitih klasa grupišu u jedinstven interfejs njihove zajedničke klase.

Dinamičko vezivanje (dynamic binding):

Ako se poziv funkcije povezuje sa konkretnim kodom funkcije koji se izvršava već u fazi prevođenja, radi se o statičkom (ranom) vezivanju.

Ako se poziv funkcije povezuje sa konkretnim kodom funkcije koji se izvršava u fazi izvršavanja programa, radi se o dinamičkom (kasnom) vezivanju.

Ako se virtuelna metoda poziva preko pokazivača ili reference na objekat onda je vezivanje najčešće dinamičko.

Ako se poziva virtuelna funkcija konkretnog objekta, vezivanje može biti statičko ali i dinamičko.

Prof. dr Branko Perišić 42

Page 43: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 43/110-------------------------------------------------------------------------------------------------------------------------------

Primer:

class Osnovna { //...public: virtual void f(); //...};

class Izvedena: public Osnovna { //...public: void f(); //...};

void g1(Osnovna b) { //Vezivanje je statičko!; b.f(); //Najčešće ne aktivira virtuelni mehanizam;}; //Odnosi se na lokalni objekat b tipa Osnovna;

void g2(Osnovna *pb) { //poziv preko pokazivača; pb -> f(); //Nije poznat tip u vreme prevođenja;}; //Vezivanje je dinamičko;void g3(Osnovna &rb) { //poziv preko reference; rb.f(); //Nije poznat tip u vreme prevođenja;}; //Vezivanje je dinamičko;void main() { Izvedena d; g1(d); //poziva se Osnovna::f(); g2 (&d); //poziva se Izvedena::f(); g3(d); //poziva se Izvedena::f(); Osnovna *pb=new Izvedena; //konverzija Izvedena* u Osnovna*; pb->f(); //poziva se Izvedena::f(); Osnovna &rb=d; //konverzija iz Izvedena& u Osnovna&; rb.f(); //poziva se Izvedena::f(); Osnovna b=d; b.f(); //poziva se Osnovna::f(); delete pb; pb=&b; pb->f(); //poziva se Osnovna::f();}

Prof. dr Branko Perišić 43

Page 44: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 44/110-------------------------------------------------------------------------------------------------------------------------------Zaključak: Ako se za neku klasu predviđa nasleđivanje, a posebno ako ona ima virtuelne metode, argumente tipa te klase u sve metode treba prenositi preko pokazivača ili referenci, jer to obezbeđuje dinamičko vezivanje.

Prof. dr Branko Perišić 44

Page 45: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 45/110-------------------------------------------------------------------------------------------------------------------------------

Virtuelne funkcije i virtuelne osnovne klase:

Pravilo dominacije: Ime D::f dominira nad imenom B::f ako je B osnovna klasa

klase D. Kada se prolaskom kroz graf izvođenja naiđe na više od

jedne funkcije, jednog objekta ili jedne konstante tipa nabrajanja sa datim imenom, obraćanje tom imenu je dvosmisleno, osim ako neko ime dominira nad ostalim. Ako je to slučaj obraćanje se odnosi na ime koje dominira.

Primer:

class V {public: void f(); int x;};class B: public virtual V {public: void f(); int x;};class D: public B, public virtual V {public: void g(){ x++; // na koji x se odnosi? f(); // na koji f() se odnosi? }};

Kako klasa B dominira klasi V a klasa D dominira klasi B i pošto B redefiniše x i f osnovne klase V u definiciji klase D x i f se odnose na B::x i B::f.

Prof. dr Branko Perišić 45

Page 46: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 46/110-------------------------------------------------------------------------------------------------------------------------------

Pravila koja se odnose na virtuelne funkcije:

Kontrola prava pristupa virtuelnoj metodi vrši se u skladu sa njenom deklaracijom, i na ta prava ne utiču pravila vezana za metode koje je kasnije redefinišu.

Ako se unutar konstruktora ili destruktora pozove virtuelna metoda, pozvaće se ona verzija virtuelne metode koja odgovara klasi čiji je to konstruktor, odnosno destruktor.

Primer:

class B {public: virtual void f(); //virtuelna metoda f;};

class D: public B {private: void f(); //redefinisana metoda f;};

void main () { D d; B *pb=&d; D *pd=&d; pb->f(); //ok. B::f je public, a poziva se D::f; pd->f(); //greška! D::f je private;}

Virtuelni destruktor: Destruktor može biti vurtualan (konstruktor ne može) Ako je destruktor virtuelan, prvi destruktor koji se

poziva određuje se na osnovu tipa objekta, a ne tipa pokazivača ili reference na objekat.

Destruktor osnovnih klasa se uvek implicitno poziva.

Prof. dr Branko Perišić 46

Page 47: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 47/110-------------------------------------------------------------------------------------------------------------------------------

Pravilo: Ako neka osnovna klasa ima virtuelne metode potrebno je da i njen destruktor (ako ga ima) bude virtuelan.

Prof. dr Branko Perišić 47

Page 48: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 48/110-------------------------------------------------------------------------------------------------------------------------------

Apstraktne klase

Apstraktna klasa predstavlja generalizaciju konkretne klase u cilju korišćenja polimorfizma. Nema objekte!

Primer:

Klasa Osoba iz koje se izvode klase Muškarci i Žene nema objekata budući da ne postoje instance klase Osoba koje ujedno nisu instance ili klase Muškarci ili klase Žene. Zbog toga je klasa Osoba apstraktna.

Apstraktne klase realizuju koncept GENERALIZACIJE.

Prof. dr Branko Perišić 48

Osoba

Muškarci Žene

Page 49: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 49/110-------------------------------------------------------------------------------------------------------------------------------

Realizacija virtuelnog mehanizma

Za svaku klasu koja poseduje virtuelne metode, formira se tabela pokazivača na verzije virtuelnih metoda za tu klasu.

Svaki objekat klase koja sadrži virtuelne metode poseduje pokazivač na tabelu virtuelnih metoda svoje klase. Ovaj pokazivač implicitno inicijalizuje konstruktor svake klase.

Pri pozivu virtuelne metode, pristup metodi je posredan, preko pokazivača na tabelu virtuelnih metoda unutar objekta, i pokazivača iz tabele virtuelnih metoda (dinamičko vezivanje).Primer:class B {public: int b; virtual void f(); virtual void g();};class D: public B { int d;public: void g();}; Objekat klase D D virt.tabela

Prof. dr Branko Perišić 49

vtblptr

int b

int d

&B::f

&D::g

D nije redefinisao f()

D je redefinisao g()

Page 50: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 50/110-------------------------------------------------------------------------------------------------------------------------------

P O G L A V LJ E 2. 2. Osnovi softverskog inženjerstvaKAKO DEFINISATI

PROJEKTOVANJE SOFTVERA KAO PROFESIJU?

IEEE & ACM – Software Engineering Body Of Knowledge (rezultat višegodišnjeg napora oko 300 inženjera) – objedinjava skup potrebnih znanja za profesiju Softver inženjer.

POSTOJI FORMALNI ATESTI (Software engineering Licencing and acreditation)

NE POSTOJE USAGLAŠENI KRITERIJUMI ZA OCENU PROIZVODA (Ne postoji etalon softverskog proizvoda. Postoji nekmoliko stotina standarda – internih i eksternih, koji regulišu domen softverskog proizvoda).

DEFINICIJE: IEEE:

(1) PRIMENA: SISTEMATIČNOG, DISCIPLINOVANOG I MERLJIVOG PRISTUPA RAZVOJU, EKSPLOATACIJI I ODRŽAVANJU SOFTVERA.

(2) PRIMENA INŽENJERSTVA NA SOFTVER!Computer Society Software Engineering

Committee(CSSEC):

Prof. dr Branko Perišić 50

Page 51: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 51/110-------------------------------------------------------------------------------------------------------------------------------

INŽENJERSKA GRANA KOJA SE BAVI RAZVOJEM, EKSPLOATACIJOM I ODRŽAVANJEM SOFTVERA.

DISCIPLINA SOFTVERSKOG INŽENJERSTVA SE OBIČNO OPISUJE TERMINOLOGIJOM VEZANOM ZA ŽIVOTNI CIKLUS SOFTVERA:

(1) ANALIZA ZAHTEVA

(2) IZRADA SPECIFIKACIJA

(3) DIZAJN

(4) IMPLEMENTACIJA

(5) TESTIRANJE

(6) ODRŽAVANJE

OVAKVA PREDSTAVA JE JEDNODIMENZIONALNA I NIJE ADEKVATNA ZA ANALIZU SVIH ASPEKATA PROJEKTOVANJA SOFTVERA.

Prof. dr Branko Perišić 51

ASPEKTI IN@ENJERSKOG KURSA

ASPEKTI IN@ENJERSKOG KURSA

IN@ENJERSKIPOSTUPAK

IN@ENJERSKIPOSTUPAK P R O I Z V O D P R O I Z V O D

Page 52: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 52/110-------------------------------------------------------------------------------------------------------------------------------

STRUKTURA OSNOVNIH ZNANJA IZ OBLASTI

SOFTVERSKOG INŽENJERSTVA

Prof. dr Branko Perišić 52

SOFTWARE ENGINEE

SOFTWARE ENGINEE PROJEKATPROJEKAT

SPECIFIKACIJASOFTVERSKIH

SISTEMA

SPECIFIKACIJASOFTVERSKIH

SISTEMA

VERIFIKACIJAI

VALIDACIJASOFTVERA

VERIFIKACIJAI

VALIDACIJASOFTVERA

GENERISANJE I

ODRŽAVANJE

GENERISANJE I

ODRŽAVANJE

PRINCIPI I PRIMENA DIZAJNA

SOFTVERA

PRINCIPI I PRIMENA DIZAJNA

SOFTVERA

INŽENJERSTVO

SOFTV.SISTEMA

INŽENJERSTVO

SOFTV.SISTEMA

UPRAV.SOFTV.

PROJEKTOM

UPRAV.SOFTV.

PROJEKTOM

PREDUSLOVI

PREDUSLOVI

DISKRETNAMATEMATIKA

DISKRETNAMATEMATIKA

PROGRAMMING-IN-THE-SMALL PROGRAMMING-IN-THE-SMALL

PROGRAMIRANJEPROGRAMIRANJE

STUKTUREPODATAKA

STUKTUREPODATAKA

ALGORITMIALGORITMI

INŽENJERSKEKOMUNIKACIJE

INŽENJERSKEKOMUNIKACIJE

DOPUNSKEOBLASTI

SOFTVERSKOG INŽENJERSTVA

DOPUNSKEOBLASTI

SOFTVERSKOG INŽENJERSTVA

Page 53: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 53/110-------------------------------------------------------------------------------------------------------------------------------

PROCES SOFTVERSKOG INŽENJERSTVAMOŽE SE PREDSTAVITI

DVODIMENZIONALNIM MODELOM

ASPEKTI

Prof. dr Branko Perišić 53

RAZVOJ(zahtevi, analiza,

specifikacijedizajn

primenatestiranje)

RAZVOJ(zahtevi, analiza,

specifikacijedizajn

primenatestiranje)

KOMUNIKACIJE KOMUNIKACIJE

DEJSTVA DEJSTVA

ALATI

ALATI

AKTIVNOSTI

KONTROLA(potvrda kvaliteta,

konfigurisanje,validacija i verifikacija)

KONTROLA(potvrda kvaliteta,

konfigurisanje,validacija i verifikacija)

UPRAVLJANJE(planiranje projekta

alokacija resursa,procena troškova,

ugovaranje...)

UPRAVLJANJE(planiranje projekta

alokacija resursa,procena troškova,

ugovaranje...)

RAD(obuka, prelazak,

rad,gašenje)

RAD(obuka, prelazak,

rad,gašenje)

METODEMETODE

PREDSTAVLJANJEPREDSTAVLJANJE

APSTRAKCIJEAPSTRAKCIJE

11 22

4466

7799

88

3310

10

55

Page 54: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 54/110-------------------------------------------------------------------------------------------------------------------------------

DIMENZIJA AKTIVNOSTI:

AKTIVNOSTI VEZANE ZA PROCES SOFTVERSKOG INŽENJERSTVA MOGU SE PODELITI U ČETIRI GRUPE:

(1) DIZAJN - PROCES KREIRANJA I PROIZVODNJE SOFTVERSKOG PROIZVODA KOJI UKLJUČUJE:

(1) ANALIZU ZAHTEVA(2) IZRADU SPECIFIKACIJA(3) DIZAJN(4) IMPLEMENTACIJU(5) TESTIRANJE

KAKO SE SOFTVER JAVLJA KAO SASTAVNI DEO SLOŽENIJEG PROIZVODA ILI SISTEMA, NEOPHODNO JE NAPRAVITI RAZLIKU IZMEĐU:

SISTEMSKIH AKTIVNOSTI (DIZAJN SISTEMA) I

SOFTVERSKIH AKTIVNOSTI (DIZAJN SOFTVERA)

(2) KONTROLA

KONTROLNE AKTIVNOSTI NISU VEZANE ZA SAM SOFTVERSKI PROIZVOD VEĆ ZA PROCES REALIZACIJE (IZVOĐENJA) RAZVOJNIH AKTIVNOSTI.OBUHVATAJU:

(1) PLAN KVALITETA(2) KONTROLU KVALITETA(3) POTVRDU KVALITETA(4) KONFIGURISANJE(5) NEZAVISNU VERIFIKACIJU I VALIDACIJU

(3) UPRAVLJANJE

(1) IZVRŠNE DIREKTIVE(2) ADMINISTRATIVNE DIREKTIVE(3) NADZORNE DIREKTIVEZA USMERAVANJE ILI

VOĐENJE SOFTVERSKOG PROJEKTA.TIPIČNE AKTIVNOSTI:(3.1) PLANIRANJE PROJEKTA(3.2) ALOKACIJA RESURSA(3.3) ORGANIZOVANJE PROJEKTNOG TIMA(3.4) PROCENA TROŠKOVA REALIZACIJE

Prof. dr Branko Perišić 54

Page 55: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 55/110-------------------------------------------------------------------------------------------------------------------------------

(3.5) UGOVARANJE I NORMATIVNE AKTIVNOSTI

Prof. dr Branko Perišić 55

Page 56: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 56/110-------------------------------------------------------------------------------------------------------------------------------

(4) RAD

RAD PODRAZUMEVA OPERATIVNE ASPEKTE KORIŠĆENJA SOFTVERSKOG PROIZVODA. OBUHVATAJU:

(1) OBUKU KORISNIKA(2) PLANIRANJE ISPORUKE I INSTALACIJE(3) PRELAZAK SA STAROG NAČINA RADA NA NOVI

(MIGRACIJA)(4) OPERATIVNI RAD SOFTVERSKOG PROIZVODA I

ODRŽAVANJE(5) IZVOĐENJE SOFTVERSKOG PROIZVODA IZ

EKSPLOATACIJE

DIMENZIJA ASPEKATA:

INŽENJERSKE AKTIVNOSTI SE TRADICIONALNO DELE NA:

- AKTIVNOSTI ANALIZE

- AKTIVNOSTI SINTEZE

PRI ČEMU JE MOGUĆE IZOLOVATI ŠEST ASPEKATA OVIH AKTIVNOSTI:

(1) APSTRAKCIJE:

OBUHVATAJU FUNDAMENTALNE PRINCIPE I FORMALNE MODELE

MODELI PROCESA RAZVOJA SOFTVERA (VODOPAD, SPIRALNI, IZRADA PROTOTIPA I SL.) PREDSTAVLJAJU MODELE EVOLUCIJE SOFTVERA.

KONAČNI AUTOMATI I PETRIJEVE MREŽE PREDSTAVLJAJU MODELE ZA PREDSTAVLJANJE SEKVENCIJALNOG I KONKURENTNOG PROCESIRANJA – RESPEKTIVNO.

COCOMO - PREDSTAVLJA MODEL OCENE TROŠKOVA IZRADE SOFTVERSKOG PROIZVODA.

MODULARNOST, SKRIVANJE INFORMACIJA (Information hiding) PREDSTAVLJAJU PRINCIPE DIZAJNA SOFTVERA.

Prof. dr Branko Perišić 56

Page 57: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 57/110-------------------------------------------------------------------------------------------------------------------------------

(2) PREDSTAVLJANJE:

OBUHVATA NOTACIONE ASPEKTE I JEZIKE:

ADA PROGRAMSKI JEZIK (IMPLEMENTACIONA NOTACIJA)

UML USE-CASE (Notacija za modeliranje slučajeva korišćenja)

TABELE ODLUČIVANJA I DIJAGRAMI DOKA PODATAKA (NOTACIJA DIZAJNA)

PERT-DIJAGRAMI (NOTACIJA ZA PLANIRANJE PROJEKTA)

(3) METODE:

OBUHVATAJU FORMALNE METODE, TEKUĆU PRAKSU I METODOLOGIJE

DOKAZ KOREKTNOSTI PROGRAMA PREDSTAVLJA FORMALNI METOD VERIFIKACIJE

OBJEKT-ORIJENTISANI DIZAJN PREDSTAVLJA METODOLOGIJU PROJEKTOVANJA

OBJEKTNO PROGRAMIRANJE SE MOŽE SMATRATI IMPLEMENTACIONOM PRAKSOM

(4) ALATI:

OBUHVATAJU POJEDINAČNE SOFTVERSKE ALATE KAO I INTEGRISANE SKUPOVE ALATA, IMPLICITNO I HARDVERSKA SREDSTVA KOJA IM SLUŽE KAO TEHNIČKA PODRŠKA.

ALATI OPŠTE NAMENE (E-MAIL, OBRADA TEKSTA I SL.)

ALATI NAMENJENI DIZAJNU I IMPLEMENTACIJI(KOMPAJLERI, SINTAKSNO-VOĐENI EDITORI I SL.)

ALATI ZA UPRAVLJANJE PROJEKTOM

ČESTO SE JAVLJAJU KAO “RAZVOJNA OKRUŽENJA” (ENVIRONMENT), I OBIČNO OBUHVATAJU :

PREDSTAVLJANJE

Prof. dr Branko Perišić 57

Page 58: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 58/110-------------------------------------------------------------------------------------------------------------------------------ALATE

METODE

OBJEKTE

(5) DEJSTVA:

OBUHVATAJU: MERENJA, ANALIZE I EVALUACIJU SOFTVERSKOG PROIZVODA I SOFTVERSKIH PROCESA, KAO I UTICAJ SOFTVERA NA ORGANIZACIONI SISTEM, MERE I STANDARDE.

OVA OBLAST ZAVREĐUJE POSEBNU PAŽNJU U SKLOPU IZUČAVANJA SOFTVERSKOG INŽENJERSTVA KAO DISCIPLINE, BUDUĆI DA SOFTVERSKI INŽENJERI TREBA DA ZNAJU :

1. ŠTA TREBA DA MERE2. KAKO TO MOGU IZMERITI3. I KAKO MOGU ISKORISTITI REZULTATE MERENJA

U CILJU ANALIZE, EVALUACIJE I POBOLJŠANJA SOFTVERSKOG PROIZVODA I PROCESA NJEGOVE IZRADE.

(6) KOMUNIKACIJA:

SOFTVERSKI INŽENJER MORA POSEDOVATI DOBRU OPŠTU TEHNIKU KOMUNIKACIJA I RAZUMEVANJE ODGOVARAJUĆIH FORMI DOKUMENTACIJE NEOPHODNE ZA ILUSTROVANJE POJEDINAČNIH AKTIVNOSTI U PROCESU PROIZVODNJE SOFTVERA.

(1) PISANA KOMUNIKACIJA

(2) GOVORNA KOMUNIKACIJA

(3) ON-LINE DOKUMENTACIJA (Help)

Prof. dr Branko Perišić 58

Page 59: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 59/110-------------------------------------------------------------------------------------------------------------------------------

POGLED NA Softversko Inženjerstvo SA ASPEKTA PROIZVODA:

AKTIVNOSTI I ASPEKTI SOFTVERSKOG INŽENJERSTVA SE MORAJU POSMATRATI U KONTEKSTU

VRSTE SOFTVERSKOG SISTEMAKOJI PREDSTAVLJA KONAČNI PROIZVOD PROCESA SOFTVERSKOG INŽENJERSTVA.

SA ASPEKTA KONAČNOG PROIZVODA MOŽEMO RAZMATRATI DVE OSNOVNE KATEGORIJE:

(1) KLASE SOFTVERSKIH SISTEMA(SOFTWARE SYSTEM CLASSES)

(2) OPŠTE ZAHTEVE KOJE PROIZVOD TREBA ISPUNITI(PERVASIVE SYSTEM REQUIREMENTS)

CELOKUPAN POGLED NA SE MOŽE SE, PREM GORE IZNETOM, PRETSTAVITI 4-DIMENZIONALNIM MODELOM SA ORTOGONALNIM OSAMA:

AKTIAVNOSTI ASPEKTI KLASE SOFTVERSKIH SISTEMA OPŠTI ZAHTEVI PREMA SOFTVERSKOM

PROIZVODU

ORTOGONALNOST POJEDINIH OSA PREDSTAVLJA GARANCIJU SEMANTIČKE NEZAVISNOSTI POJAVA(ATRIBUTA) KOJI IH KARAKTERIŠU.

Prof. dr Branko Perišić 59

Page 60: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 60/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 60

ODNOSI PREMAOKRUŽENJU

ODNOSI PREMAOKRUŽENJU

KLASE SOFTVERSKIH SISTEMA KLASE SOFTVERSKIH SISTEMA

GENERIČKEOBLASTIPRIMENE

GENERIČKEOBLASTIPRIMENE

BATCHBATCH

INTERAKTIVNIINTERAKTIVNI

REAKTIVNIREAKTIVNI

REAL TIMEREAL TIME

SADRŽANI(EMBEDED)SADRŽANI(EMBEDED)

DISTRIBUIRANIDISTRIBUIRANI

KONKURENTNIKONKURENTNI

MREŽNIMREŽNI

AVIOSAOBRAČAJ

AVIOSAOBRAČAJ

KOMUNIKACIONI

SISTEMI

KOMUNIKACIONI

SISTEMI

OPERATIVNISISTEMI

OPERATIVNISISTEMI

SISTEMIZA RUKOVANJE

BAZAMAPODATAKA

SISTEMIZA RUKOVANJE

BAZAMAPODATAKA

CASECADCAM

ALATI

CASECADCAM

ALATI

INTERNEKARAKTERISTIKE

INTERNEKARAKTERISTIKE

TABLEDRIVENTABLE

DRIVEN

PROCCESSDRIVEN

PROCCESSDRIVEN

KNOWLEDGEBASED

KNOWLEDGEBASED

Page 61: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 61/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 61

OPŠTI ZAHTEVI PREMA SOFTVERSKOM PROIZVODU

OPŠTI ZAHTEVI PREMA SOFTVERSKOM PROIZVODU

DOSTUPNOST(ACCESSABILITY)

DOSTUPNOST(ACCESSABILITY)

PRENOSIVOST(PORTABILITY)PRENOSIVOST(PORTABILITY)

ADAPTIVNOST(ADAPTIBILITY)ADAPTIVNOST

(ADAPTIBILITY)

ZAŠTITA(PROTECTION)

ZAŠTITA(PROTECTION)

RASPOLOŽIVOST(AVAILABILITY)

RASPOLOŽIVOST(AVAILABILITY)

POUZDANOST(RELIABILITY)POUZDANOST(RELIABILITY)

KOMPATIBILNOST(COMPATIBILITY)

KOMPATIBILNOST(COMPATIBILITY)

PONOVNAISKORISTIVOST(REUSABILITY)

PONOVNAISKORISTIVOST(REUSABILITY)

KOREKTNOST(CORRECTNESS)KOREKTNOST

(CORRECTNESS)ROBUSTNOST(ROBUSTNESS)ROBUSTNOST(ROBUSTNESS)

OTPORNOST NAGREŠKE

(FAULT TOLERANCY)

OTPORNOST NAGREŠKE

(FAULT TOLERANCY)

BEZBEDNOST(SAFETY)

BEZBEDNOST(SAFETY)

INTEGRITET(INTEGRITY)

INTEGRITET(INTEGRITY)

SIGURNOST(SECURITY)

SIGURNOST(SECURITY)

OPERATIVNOST(INTEROPERABILITY)

OPERATIVNOST(INTEROPERABILITY)

MOGUĆNOSTTESTIRANJA

(TESTABILITY)

MOGUĆNOSTTESTIRANJA

(TESTABILITY)

MOGUĆNOSTODRŽAVANJA

(MAINTAINABILITY)

MOGUĆNOSTODRŽAVANJA

(MAINTAINABILITY)

PERFORMANSA(PERFORMANCE)PERFORMANSA

(PERFORMANCE)

MOGUĆNOSTKORIŠĆENJA(USABILITY)

MOGUĆNOSTKORIŠĆENJA(USABILITY)

EFIKASNOST(EFFICIENCY)EFIKASNOST(EFFICIENCY)

Page 62: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 62/110-------------------------------------------------------------------------------------------------------------------------------

RAZVOJ SOFTVERA NIJE LINIJSKI PROCES. ON SE MNOGO PRECIZNIJE MOŽE ISKAZATI CIKLIČKIM

MODELOM.

PROCESI U INŽENJERSTVU SU KONAČNI.

PROJEKTOVANJE SOFTVERA, U MNOGIM SLUČAJEVIMA, NIJE KONAČAN PROCES.

CIKLUS RAZVOJA SOFTVERA

Prof. dr Branko Perišić 62

ANALIZAZAHTEVA

ANALIZAZAHTEVA

SPECIFIKACIJADIZAJNA

SPECIFIKACIJADIZAJNA ODRŽAVANJEODRŽAVANJE

IMPLEMENTACIJAIMPLEMENTACIJA

INTERNO TESTIRANJE

I INTEGRACIJA

INTERNO TESTIRANJE

I INTEGRACIJA

RELEASEISPORUKARELEASE

ISPORUKA

BETATEST

BETATEST

Page 63: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 63/110-------------------------------------------------------------------------------------------------------------------------------

ANALIZA ZAHTEVA:

Obezbeđuje ANALIZU i ARTIKULISANJE zahteva krajnjih korisnika. Produkt ove analize predstavlja, u opštem slučaju, SPECIFIKACIJA ZAHTEVA/POTREBA.

Specifikacija zahteva uključuje:

(1) FUNKCIONALNE ZAHTEVE/POTREBE

(2) OGRANIČENJA VEZANA ZA HARDVERSKOOKRUŽENJE (TEHNIČKU PODRŠKU)

(3) CILJNU PERFORMANSU

(4) ODREDNICE KORISNIČKOG SPREŽNOGPODSISTEMA

SPECIFIKACIJA DIZAJNA:

Sastoji se od GRUBE VERZIJE SOFTVERA, koja pokazuje: ŠTA TREBA DA SE IZGRADI i KAKO SE TO MOŽE IZGRADITI.

Obuhvata:

(1) DEKOMPOZICIJU NA MODULE

(2) DEFINICIJU STRUKTURA PODATAKA

(3) DEFINICIJU STRUKTURE SKLADIŠTAPODATAKA

(4) OPISE ZNAČAJNIH POSTUPAKA

Prof. dr Branko Perišić 63

Page 64: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 64/110-------------------------------------------------------------------------------------------------------------------------------

IMPLEMENTACIJA:

Obuhvata:

(1) KODIRANJE, (2) TESTIRANJE i DEBUGIRANJE

POJEDINAČNIH MODULA, definisanih u sklopu SPECIFIKACIJE DIZAJNA. Kontrolisani prolasci kroz kod (CODE WALK-THROUGHS) se generišu u cilju obezbeđenja KVALITETA i POUZDANOSTI implementacije.

INTERNO TESTIRANJE I INTEGRACIJA:

Obuhvata testiranje pojedinačnih modula razvijenih u fazi IMPLEMENTACIJE i INTEGRACIJU pojedinačnih modula u jedinstvenu PROGRAMSKU STRUKTURU.

Integrisana PROGRAMSKA STRUKTURA se zatim testira u cilju verifikacije funkcionisanja CELOKUPNOG REŠENJA. (BOTTOM-UP-IMPLEMENTACIJA)

BETA-TEST RELEASE:

Podrazumeva slanje PRVE VERZIJE softvera stvarnim KRAJNJIM KORISNICIMA, u cilju identifikacije problema vezanih za implementaciju (NEDOSLEDNOSTI, GREŠKE, PERFORMANSA i sl.).

Prof. dr Branko Perišić 64

Page 65: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 65/110-------------------------------------------------------------------------------------------------------------------------------

KONAČNI RELEASE:

Na osnovu rezultata BETA-TESTA, korigovanjem grešaka, uklanjanjem nedoslednosti i poboljšanjem performanse nastaje KONAČNA VERZIJA ZA ISPORUKU.

ODRŽAVANJE:

Obuhvata razrešavanje GREŠAKA i/ili PROBLEMA otkrivenih od strane korisnika u sklopu FINALNOG REŠENJA.Osnovni problem, u ovom domenu, predstavlja RUKOVANJE VERZIJAMA softverskog proizvoda i obezbeđenje EFIKASNOG MEHANIZMA za distribuciju novih verzija.

Prof. dr Branko Perišić 65

Page 66: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 66/110-------------------------------------------------------------------------------------------------------------------------------

RAZLOZI NEUSPEHA SOFTVERSKIH PROIZVODA

FAZA SIMPTOMI

ANALIZA ZAHTEVA nepostojanje PISANE FORME formulisanih zahteva

nekompletna specifikacija zahteva

nepostojanje definisane sprege sakorisnikom

neuključivanje KRAJNJIH korisnika

SPECIFIKACIJA DIZAJA

nepostojanje ili postojanje nedovoljnog broja specifikacionih dokumenata

loše specificirana struktura podataka i struktura skladišta podataka

retko ili nikakvo REVIDIRANJE dizajna

IMPLEMENTACIJA nedostatak ili nedovoljna primenaSTANDARDA U

KODIRANJU retko ili nikakvo revidiranje koda neadekvatno IN-LINE

dokumentovanje koda.

INTERNO TESTIRANJE I INTEGRACIJA

nedovoljno testirenje MODULA nedostatak adekvatnog testa nepostojanje NEZAVISNE

GRUPE ZA POTVRDU KVALITETA.

BETA-TEST nepostojanje nedovoljno trajanje nedovoljan broj učesnika u

testiranju loš izbor UČESNIKA

ODRŽAVANJE previše GREŠAKA korekcija jedne greške unosi nove

Prof. dr Branko Perišić 66

Page 67: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 67/110-------------------------------------------------------------------------------------------------------------------------------

KAPITALNI UZROCI NEUSPEHA

(1) NEDOSTATAK POTPUNE FORMULACIJE ZAHTEVA

(2)NEPRIDRŽAVANJE ILI NEKORIŠTENJE METODOLOGIJE DIZAJNA SOFTVERSKOG PROIZVODA

(3) NEODGOVARAJUĆA DEKOMPOZICIJA NA MODULE

Prof. dr Branko Perišić 67

Page 68: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 68/110-------------------------------------------------------------------------------------------------------------------------------

EVOLUCIJA SOFTVERSKIH ALATA

Prof. dr Branko Perišić 68

OBJEKTORIJENTISANIGENERATORIAPLIKACIJA

OBJEKTORIJENTISANIGENERATORIAPLIKACIJA

GENERATORIIZVORNOG

KODA

GENERATORIIZVORNOG

KODA

SAVREMENICASEALATI

SAVREMENICASEALATI

ANALIZAZAHTEVA &

ALATI ZA DEFINISANJ

ESPECIFIKAC

IJADIZAJNA

GENERATORI

SPRE@NOGPODSISTEM

A

ANALIZAZAHTEVA &

ALATI ZA DEFINISANJ

ESPECIFIKAC

IJADIZAJNA

GENERATORI

SPRE@NOGPODSISTEM

A

SISTEMI ZAKONTROLUIZVORNOG

KODA

SISTEMI ZAKONTROLUIZVORNOG

KODA

SIMBOLI^KIDEBUGER-IBIBLIOTEKE

SIMBOLI^KIDEBUGER-IBIBLIOTEKE

PREVODIOCIINTERPRETERI

KOMANDNAOKRU@ENJA

PREVODIOCIINTERPRETERI

KOMANDNAOKRU@ENJA

ASEMBLERICORE-DUMPANALIZATORI

ASEMBLERICORE-DUMPANALIZATORI

SOFISTICIRANOST

Page 69: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 69/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 69

Page 70: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 70/110-------------------------------------------------------------------------------------------------------------------------------

ANALIZA ZAHTEVA

Prof. dr Branko Perišić 70

PRVI KORAK U PROCESURAZVOJA SOFTVERA

PREDSTAVLJA IZRADASPECIFIKACIJE ZAHTEVA

(REQUIREMENTS ANALYSIS)

PRVI KORAK U PROCESURAZVOJA SOFTVERA

PREDSTAVLJA IZRADASPECIFIKACIJE ZAHTEVA

(REQUIREMENTS ANALYSIS)

KORISNICI

KORISNICI

ANALITI^ARANALITI^AR

SREDSTVATEHNIKE

SPECIFIKACIJA

ZAHTEVA

Page 71: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 71/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 71

ANALIZAZAHTEVA

PREDSTAVLJA PREDMET DOGOVORAPRI ČEMU SE KLJUČNA SVOJSTVA

ODVAJAJU OD MANJE VAŽNIH

ČESTO PODRAZUMEVA MODELIRANJE PONAŠANJA

KRAJNJIH KORISNIKA, U CILJUBOLJEG RAZUMEVANJA POSLOVNE

ULOGE I FUNKCIJA PROGRAMSKOGKOMPLEKSA KOJI JE PREDMET

A N A L I Z E

PROCES JE ITERATIVAN I ZAHTEVA POVREMENE REDEFINICIJE I

RAFINACIJU U HODU!

PROCES JE ISCRPLJUJUĆI I ZAHTEVAMNOGO VREMENA

Page 72: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 72/110-------------------------------------------------------------------------------------------------------------------------------

ZNAČAJNI METODOLOŠKI PRISTUPI

Prof. dr Branko Perišić 72

ORGANIZACIONI PRISTUP

PRISTUP BAZIRAN NA TOKOVIMA DOKUMENATA

PRISTUP BAZIRAN NA TRANSFORMACIJI PODATAKA

FUNKCIONALNI PRISTUP

OBJEKT-ORIJENTISANI PRISTUP

IZRADA PROTOTIPA(RAPID PROTOTYPING)

KOMBINOVANI PRISTUPI

PRISTUP BAZIRAN NA DEFINISANJU A G E N A T A

Page 73: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 73/110-------------------------------------------------------------------------------------------------------------------------------

Predstavljanje i Prikazivanje Znanja o ZAHTEVIMA

POSTOJI ENORMNA KOLIČINARAZLIČITOG ZNANJA PRIDRUŽENOGPROCESU DEFINISANJA ZAHTEVA

Prof. dr Branko Perišić 73

PRIKUPLJANJE

PREDSTAVLJANJE

RAZUMEVANJE

EVOLUCIJA

Page 74: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 74/110-------------------------------------------------------------------------------------------------------------------------------

KONCEPTUALNI MODEL ANALIZE ZAHTEVA

Prof. dr Branko Perišić 74

ZAHTEV

TEMA

POZICIJA ARGUMENT

PRETPOSTAVKA

ODLUKA

OGRANI^ENJA

OBJEKATDIZAJNA

GENERALIZUJE/SPECIJALIZUJE

ZAMENJUJE/PITA SE/

PREDLOŽENA OD

GENERALIZUJE/SPECIJALIZUJE

PREDLO@ENA OD

ODGOVARA

PODR@AVA

NEGIRA

PREDLO@EN OD

BIRA

RAZRE[AVAZAVISI OD

KVALIFIKUJE

VODI KA

ZAVISI OD

MENJA

GENERALIZUJE/SPECIJALIZUJE

IMPLICIRA/ VODI DO/GENERI[E

ZAVISI ODKREIRA/UKLANJA/MENJA

Page 75: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 75/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 75

Page 76: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 76/110-------------------------------------------------------------------------------------------------------------------------------

SPECIFIKACIJA DIZAJNA

Prof. dr Branko Perišić 76

PREDSTAVLJA KORAK U KOME SEANALIZA ZAHTEVA

PREVODI U ARHITEKTURU SISTEMAKOJI JE PREDMET PROJEKTOVANJA

IDENTIFIKACIJAOSNOVNIHMODULA

DEFINISANJEKOMUNIKACIONIH

PUTEVA ZA PRENOS

PODATAKA IZME\UMODULA

SPECIFIKACIJA

FORMATA

DEFINICIJASTRUKTURA PODATAKA

DEFINISANJEUNUTRA[NJE STRUKTURE

POJEDINA^NIH MODULA

Page 77: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 77/110-------------------------------------------------------------------------------------------------------------------------------

Rezultat ovog koraka predstavlja osnov za FAZU IMPLEMENTACIJE

F-29.

Prof. dr Branko Perišić 77

ELEMENTI SPECIFIKACIJEDIZAJNA

RAZLAGANJE FUNKCIONALNESPECIFIKACIJE NA

SKUP MODULA(SEGREGACIJA)

HIJERARHIJSKO ORGANIZOVANJE MODULA

DEFINISANJE TOKOVA PODATAKA IZME\U MODULA

DEFINISANJE STRUKTURESPOLJA[NJIH SKLADI[TA

PODATAKA

DEFINISANJE PRISTUPNIH PUTEVA SPOLJA[NJIM

SKLADI[TIMA PODATAKA(MEHANIZMI PRISTUPA)

DEFINISANJE STRUKTURA PODATAKA KOJE SE

IZMENJUJU ME\U MODULIMA POSREDSTVOM DEFINISANIH

PUTEVA(TOKOVA)

IZRADA KLJU^NIH ALGORITAMA

DEFINISANJE UNUTRA[NJESTRUKTURE SVAKOG

MODULA(SUBROUTINES)

Page 78: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 78/110-------------------------------------------------------------------------------------------------------------------------------

SPECIFIKACIJA DIZAJNA

Prof. dr Branko Perišić 78

SPECIFIKACIJAZAHTEVA

(SPECIFIKACIONIDOKUMENT)

SPECIFIKACIJADIZAJNA(DESIGN

SPECIFICATION)

MODELING-IN_THE_LARGE

IMPLEMENTACIJA(MODELING-IN-THE-

SMALL)

DEKOMPOZICIJAILI

KOMPOZICIJA

Page 79: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 79/110-------------------------------------------------------------------------------------------------------------------------------

ANALIZIRA:

(1) SNAGU VEZA ME\U MODULIMA(Coupling)

(2) FUNKCIONALNU SNAGU MODULA(Cohesion)

(3) RASPODELU KONTROLA UNUTARMODULA(broj PODPROGRAMA )

(4) FAN-IN/FAN-OUT KARAKTERISTIKE

MODULA (opseg kontrola i opseg uticaja)

(5) OSNOVNE STRUKTURE DIZAJNA- TRANSAKCIONO ORIJENTISAN- TRANSFORMACIONO

ORIJENTISAN

Prof. dr Branko Perišić 79

Page 80: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 80/110-------------------------------------------------------------------------------------------------------------------------------

I M P L E M E N T A C I J A(Modelling-in-the-small)

(Programming-in-the-small)

Po~inje onog trenutka kada je razja{njena velika ve~ina neodre|enosti vezanih za DOMEN-APLIKACIJE i

uspostavljeno okru`enje za PROGRAMIRANJE (definisana SPECIFIKACIJA DIZAJNA)

Bitno je postojanje:

(1) OPISA NAMENE

interfejs izme|u ciljnog sistema i korisnika, hardvera i eksternog softvera

identifikacija glavnih funkcija koje ciljni sistem podr`ava

opis klju~nih ograni~enja

(2) OPIS DIZAJNA (High-level Design Descr.)

(3) DETALJNA SPECIFIKACIJA DIZAJNA

Prof. dr Branko Perišić 80

Page 81: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 81/110-------------------------------------------------------------------------------------------------------------------------------

OPIS PROGRAMSKOG KODA

- Naziv modula (mnemonik)- Ime izvornog autora- Datum inicijalne kompilacija- Datum poslednje kompilacija- Istorijat modifikacija

-Datum,autor,namena,identifikator

- Komentar- Opis parametara- Opis funkcija/funkcije modula- Definicija na~ina rada- Na~in opslu`enja IZUZETAKA

(exceptions)- Algoritam- Karakteristike ulaza- Karakteristike izlaza- Globalne promenljive- Opis strukture podataka- Dejstva modula (usputna)- Vremenska ograni~enja- Od koga je REFERENCIRAN

(Calling routines)- Koga POZIVA (Called routines)

Prof. dr Branko Perišić 81

Page 82: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 82/110-------------------------------------------------------------------------------------------------------------------------------

- PROGRAMSKI SEGMENT(In line dokumentovanje)

ELEMENTI VEZANI ZA STIL-PROGRAMIRANJA

(Programming Style Elements)

(A)PROGRAMSKI KOD JE PODLO@AN PROMENAMA. ZBOG TOGA:

Programirati JASNO - ne pamatovati previ{e

Iskazati ono {to mislite DIREKTNO i JEDNOSTAVNO

Koristiti BIBLIOTE^KE FUNKCIJE Izbegavati PRIVREMENE

PROMENLJIVE Podrediti EFIKASNOST JASNO]I Zameniti repetitivne segmente

koda POZIVOM ZAJEDNI^KE FUNKCIJE/PROCEDURE Imena promenljivih ne smeju

izazivati ZABUNU Izbegavati ”KRPLJENJE” koda.

Prof. dr Branko Perišić 82

Page 83: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 83/110-------------------------------------------------------------------------------------------------------------------------------

In-line KOMENTARI moraju odgovarati fakti~kom stanju koda. Izbegavati suvi{ne komentare!

Formatizovati PROGRAMSKI TEKST tako da ga je LAKO ^ITATI

Prof. dr Branko Perišić 83

Page 84: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 84/110-------------------------------------------------------------------------------------------------------------------------------

(B)Programski KOD predstavlja najdetaljniju specifikaciju dizajna te mora posedovati INTELEKTUALNU JASNO]U kvalitetnog dizajna. Zbog toga:

Izbegavati intervencije na kodu radi pove}anja efikasnosti. PRONA]I BOLJI ALGORITAM!

Primarni cilj - KOREKTAN a zatim BRZ!

Primarni cilj - SIGURAN i BEZBEDAN a zatim BRZ!

Izabrati STRUKTURU PODATAKA KOJA PROGRAM ^INI JEDNOSTAVNIJIM.

Koristiti REKURZIVNE PROCEDURE zaREKURZIVNO DEFINISANE STUKTUREPODATAKA.

Prof. dr Branko Perišić 84

Page 85: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 85/110-------------------------------------------------------------------------------------------------------------------------------

Prof. dr Branko Perišić 85

Page 86: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 86/110-------------------------------------------------------------------------------------------------------------------------------

(C)Programski kod predstavlja produkt procesa re{avanja problema i pobolj{ava se ako izbagavamo vi{ak informacija i u~imo na ranijim gre{kama. Zbog toga: Ako je moguće, prvo generišiti rešenje uz

oslonac na LAKO RAZUMLJIV PSEUDO-PROGRAMSKI JEZIK, a zatim ga prevedite u proizvoljan programski jezik.

Ako su logi~ki iskazi te{ko razumljivi neophodno ih je TRANSFORMISATI.

MODULARIZUJTE, koristite PODPROGRAME!

Proverite neke konstrukcije RU^NO, pre generisanja programskog koda.

(D)Neka programska svojstva se PODRAZUMEVAJU, bez potrebe da se POSEBNO SPECIFICIRAJU! Testirati ulazne vrednosti

formalno-logi~ki i u skladu sa ograni~enjima

Ulaz - JEDNOSTAVAN izlaz-SAM SEBI DOVOLJAN

Dozvoliti podrazumevane vrednosti(default)

Prof. dr Branko Perišić 86

Page 87: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 87/110-------------------------------------------------------------------------------------------------------------------------------

Umesto da razmi{ljamo o tome KAKO program radi, posmatramo [TA o~ekujemo da bude TA^NO u sklopu STATUSA PROGRAMA nakon svakog prelaza STANJA. (pre-conditions,post-conditions)

VERIFIKACIJA i VALIDACIJA

VALIDACIJA - Predstavlja proveru stepena (validus - jak,vredan)zadovoljenja o~ekivanja OKRU@ENJA.

Predstvalja SUBJEKTIVNU ODLUKU zasnovanu na znanjima koja proisti~u iz DOMENA primene.

Da li je to pravi/odgovarajući sistem?

VEFIRIKACIJA - Predstavlja proveru korektnosti u (verus - istina) odnosu na kriterijume za

Prof. dr Branko Perišić 87

Page 88: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 88/110-------------------------------------------------------------------------------------------------------------------------------

prihvatanje (acceptance).

Da li je sistem ispravan?

(1)Osim formalizama koji su vezani za domen primene ili sintaksnih testova, ne postoje drugi objektivni kriterijumi za evaluaciju konceptualnih modela.

(2)Da bi model bio formalan on mora imati osobinu jednozna~ne provere da li neko njegovo pro{irenje zadovoljava ili kr{i specificirane uslove.

(3)Korektnost se uvek posmatra u odnosu na neki kriterijum.

(4)Za bilo koji konceptualni model postoji vi{e formalnih modela koji mogu dovesti do `eljenog softverskog re{enja.

(5)Bilo koji formalni model treba jedino da specificira esencijalne karakteristike `eljenog proizvoda.

Prof. dr Branko Perišić 88

Page 89: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 89/110-------------------------------------------------------------------------------------------------------------------------------

(6)Finalni ~in u procesu razvoja softvera, transformacija najdetaljnije specifikacije dizajna (programski kod) u izvr{ni sistem, uvek je AUTOMATIZOVAN.

Prof. dr Branko Perišić 89

VALIDACIJAi

VERIFIKACIJA

PRE POSTOJANJAPROGRAMSKOG

KODA

NAKON ŠTO PROGRAMSKI KOD POSTOJI

Page 90: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 90/110-------------------------------------------------------------------------------------------------------------------------------

Drugi aspekt softverskog inženjerstva vezan je za UPRAVLJANJE PROCESOM i u kombinaciji sa modelom životnog ciklusa softverskog proizvoda i njegovim karakteristikama definiše domen softverskog inženjerstva. Sa stanovišta organizacije firme koja pretenduje da se bavi proizvodnjom softverskih proizvoda neophodno je postojanje organizacionih, operativnih i normativnih odgovora na sve aspekte proizvodnje softvera.

Prof. dr Branko Perišić 90

MANAGEMENT(UPRAVLJANJE

)

ANALIZAI

DIZAJN

Verifikacija&

Validacij

a

gledanjeunapred(forwardlooking)

gledanjeunazad

(backwardlooking)

gledanjeodozgo

(downwardlooking)

Page 91: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 91/110-------------------------------------------------------------------------------------------------------------------------------

Osnovni problemi rukovođenja softverskim projektom leže u sledećem:

(1) SOFTVERSKI PROJEKAT TREBA DA SIMULTANO ZADOVOLJAVA SKUP RAZLIČITIH ČINILACA, PRI ČEMU SVAKI OD NJIH POSEDUJE VLASTITI SKUP ŽELJA i VLASTITI POGLED NA PREDMET ODNOSNO CILJEVE PROJEKTA.

(2) KONFLIKTI SU IZVOR GOTOVO SVIHPOTEŠKOĆA U PROCESU UPRAVLJANJA SOFTVERSKIM PROJEKTOM I TO:

(a) NA STRATEGIJSKOM NIVOU

POSTAVLJANJE CILJEVA USTANOVLJAVANJE KONTROLNIH TAČAKA UTVRĐIVANJE ODGOVORNOSTI

(b) NA TAKTIČKOM NIVOU

RAZREŠENJE OPERATIVNIH PROBLEMA DODELJIVANJE PRIORITETA PRILAGOĐAVANJE PROMENAMA

Prof. dr Branko Perišić 91

Page 92: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 92/110-------------------------------------------------------------------------------------------------------------------------------

NAJUOBIČAJENIJI IZVORI PROBLEMA PRI UPRAVLJANJU SOFTVERSKIM PROJEKTOM OBUHVATAJU:

(1) “VEČNE” PROBLEME

1.1. NEPOTPUNI I DVOSMISLENI ZAHTEVI1.2. NEKOMPLETNE I NEPRECIZNE SPECIFIKACIJE1.3. TEŠKOĆE VEZANE ZA MODELIRANJE SISTEMA1.4. NEODREĐENOSTI VEZANE ZA PROCENU

TROŠKOVA i POTREBNIH RESURSA

(2) PROBLEME NEODGOVARAJUĆEG UPRAVLJANJA

2.1. OPŠTA NEMOGUĆNOST UOČAVANJA2.2. TEŠKOĆE PRI ANALIZI PROGRESA2.3. KOMPLIKOVANE PROCEDURE KONTROLE I

IZMENE U SLUČAJU GREŠAKA ILI PROMENE ZAHTEVA

2.4. NEPOSTOJANJE DOGOVORENIH MERA2.5. POTEŠKOĆE PRI ODRŽAVANJU KONTROLE

(3) PROBLEME VEZNE ZA PROCES ODLUČIVANJA

3.1. NEPOSTOJANJE ZAJEDNIČKE TERMINOLOGIJE3.2. NEODREĐENOSTI U ODNOSU SOFTVER/HARDVER3.3. BRZ RAZVOJ TEHNOLOGIJA3.4. POGODNOST TEHNIČKIH SREDSTAVA

(4) OSTALE TEHNIČKE ASPEKTE

4.1. MERENJE I PROCENA POUZDANOSTI4.2. PROBLEMI VEZANI ZA POVEZIVANJE4.3. PROBLEMI VEZANI ZA INTEGRACIJU

Prof. dr Branko Perišić 92

Page 93: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 93/110-------------------------------------------------------------------------------------------------------------------------------

POGLAVLJE 3.

3. Osnovni pojmovi informacionih sistema

3.1. Značaj i uloga informatike u složenim organizacijama u svetlu primene upravljačkih informacionih sistema

(tehnološki bazirani sistemi za podršku odlučivanju)

INFORMATIČKA FUNKCIJA JE PRATEĆA FUNKCIJA

NJENA POZICIJA NIJE ADEKVATNA ZNAČAJU KOJI IMA

PRISTUP MENADŽMENT FUNKCIJE INFORMACIONOJ FUNKCIJI

PRISTUP INFORMATIČKOG KADRA MENADŽMENT FUNKCIJI I OPERATIVNOJ FUNKCIJ

ZAŠTO NEPOSREDNI KORISNICI UGLAVNOM SMATRAJU DA “RAČUNAR” NE DOPRINOSI UNAPREĐENJU NIVOA OPERATIVNIH FUNKCIJA?

Gde bi informatika trebala biti u sklopu složenog preduzeća?

Prof. dr Branko Perišić 93

Page 94: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 94/110-------------------------------------------------------------------------------------------------------------------------------

Projektovanje informacionih sistema pretstavlja interdisciplinarnu aktivnost koja uključuje nekoliko graničnih disciplina i kao takva otvara čitav niz problema vezanih za terminološke i definicione aspekte.

Način na koji se uvede pojam informacionog sistem u mnogome opredeljuje pristup elaboraciji problematike vezane za njegovo projektovanje budući da implicira korake u identifikaciji njegove unutrašnje strukture a time i formulaciju postupka njegove sinteze.

Pod pojmom SISTEM podrazumevaćemo organizovan skup činilaca, sa jasno definisanim međusobnim vezama, koji deluju radi ispunjenja nekog postavljenog cilja. Bez obzira na inicijalno uspostavljanje, svaki pojedinačni sistem poseduje:

(a) MISIJU (cilj ili skup ciljeva zbog kojih postoji)

(b) ORGANIZACIONU STRUKTURU (skup činilaca i veze među njima koje formiraju topologiju sistema)

(c) FUNKCIONALNU STRUKTURU (aktivnosti koje sprovodi)

(d) INFORMACIONU STRUKTURU (sveukupnost semantičkih pretstava sa kojima i nad kojima obavlja funkcionalne transformacije (c))

(e) UPRAVLJAČKU STRUKTURU (prinudu, unutrašnju ili spoljašnju, koja usklađuje ukupno ponašanje sistema)

Ograničavanje na sisteme koji su formirani “racionalnim delovanjem ljudskog uma” otvara problem uspostavljanja ili otkrivanja osnovne “racionalnosti” inicijalno ugrađene u njegovu formulaciju budući da su sistemi, u vlastitom životnom ciklusu, podložni evolucionim i revolucionarnim promenama.

Formulisanje sistema preko pojma strukture implicira određen stepen uređenosti no, kako je u biti sistema organizovanih od strane čoveka SAM ČOVEK , čije je ponašanje u opštem slučaju spontano nepredvidljivo, to ovakvi sistemi spadaju u klasu nedeterminističkih a samim tim u kategoriju složenih sistema.

Prof. dr Branko Perišić 94

Page 95: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 95/110-------------------------------------------------------------------------------------------------------------------------------

U sklopu konvencionalnog komuniciranja pojam “informacija” se često koristi u kontekstu ocenjivanja neke poruke ili vesti primljenje posretstvom nekog od nosilaca, pri čemu je često prate neodređeni atributi tipa “malo”, “mnogo”, “nedovoljno”, “tačno”, “netačno”, “javno”, “privatno” i sl. Činjenica da u navedenoj formulaciji figuriše nosilac (posrednik) informacije otvara problem komunikacija kao fundamentalne kategorije u sklopu teorije informacija.

Atribut “informatičkog” koji prati savremeno ljudsko društvo, uz sveobuhvatan i brz razvoj sretstava informacionih tehnologija, u mnogome potencira značaj informacija i njihove interpretacije, kao pokretača razvoja ljudskog društva. Paradoks teorije informacija leži u činjenici da OČEKIVANA PORUKA ili ponašanje nosi MALU KOLIČINU INFORMACIJA (budući da je njen uticaj na buduća ponašanja mali) u odnosu na NEOČEKIVANU PORUKU ili ponašanje koje, u opštem slučaju, uzrokuje dramatične promene u budućem ponašanju.

Na osnovu gornjih razmatranja, opšta teorije informacija informaciju (I) pretstavlja kao uređenu četvorku:

I = (O,P,S,K)

pri čemu su:

O - objekat (predmet) informacijeP - prenosnik informacije (posrednik)S - semantička interpretacija (značenje)K- količina informacije (smanjenje stepena neodređenosti)

Ovakvo shvatanje pojma informacija omogućava sveobuhvatan pristup analizi i sintezi nedeterminističkih sistema pri čemu se, za razliku od niza klasičnih pristupa koji akcenat stavljaju na količinu informacije, u domenu modernih informacionih znanja, akcenat stavlja na PRENOSNIKA i SEMANTIČKU INTERPRETACIJU.

Pod pojmom INFORMACIONI SISTEM najćešće se podrazumeva deo razmatranog SISTEMA koji permanentno snabdeva informacijama sve nivoe upravljanja i odlučivanja u sklopu razmatranog organizacionog sistema, pri čemu se prezentacija i interpretacija informacija podržava skupom funkcionalnih transformacija nad informacionim resursima.

Prof. dr Branko Perišić 95

Page 96: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 96/110-------------------------------------------------------------------------------------------------------------------------------

Informacioni sistem je SISTEM i kao takav on poseduje sve elemente sistema. Njegova misija je da SNABDEVA INFORMACIJAMA, on poseduje IZVORE, PRENOSNIKE i INTERPRETATORE (organizaciona struktura i topologiju), metode i postupke za ekstrakciju znanja i interpretaciju pre odlučivanja (funkcionalna struktura), strukturu podataka nad kojom je izgrađen i upravljačku strukturu koja obezbeđuje usklađen rad predmetnog informacionog sistema u funkciji njegove osnovne misije.

Informacioni sistem je svojstvo svakog sistema i kao takav se mora posmatrati van konteksta tehničkih sretstava uz oslonac na koja je izvršena njegova implementacija.

Prof. dr Branko Perišić 96

Page 97: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 97/110-------------------------------------------------------------------------------------------------------------------------------

3.2. Koncept savremene organizacije upravljačkih informacionih sistema

Pod pojmom AUTOMATIZOVANI INFORMACIONI SISTEM podrazumevamo informacioni sistem za čiju implementaciju se koriste automatizovana (nemanuelna) tehnička sretstva. Zavisno od stepena složenosti i inteligencije koju je moguće ugraditi u tehnička sretstva za podršku implementaciji informacionih sistema razlikujemo više evolutivnih faza automatizovanih informacionih sistema.

U današnje vreme su jedino od interesa automatizovani informacioni sistemi oslonjeni na računarske sisteme kao tehnička sretstva za implementaciju. Na osnovu toga možemo zaključiti da savremeni informacioni sistemi spadaju u kategoriju na računarima baziranih sistema (Computer-based systems - CBS), pri čemu se kao referentni model koristi distribuirani model obradnih jedinica dat na Slici 3.1. Ovaj model je u literaturi poznat pod nazivom Posix-distribuirani model.

Slika 3.1. Posix-distribuirani model na računarima baziranih sistema

Prof. dr Branko Perišić 97

OBRADNA JEDINICA #1

KORISNICI

OBJEKTI ZA RUKOVANJE

INFORMACIJAMA

KOMUNIKACIONI OBJEKTI

OBRADNA JEDINICA #n

KORISNICI

OBJEKTI ZA RUKOVANJE

INFORMACIJAMA

KOMUNIKACIONI OBJEKTI

RAZMENAINFORMACIJARAZMENA

INFORMACIJA

Page 98: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 98/110-------------------------------------------------------------------------------------------------------------------------------

Ovakav model proizvoljnog informacionog sistema omogućava izgradnju različitih topologija budući da odslikava slabo spregnuti komunikaciono orijentisani sistem kao asocijaciju autonomnih obradnih jedinica.

Koncept sistema sa otvorenom arhitekturom, inicijalno nastao u domenu komunikacionih sistema, sve više nalazi primenu u različitim domenima ljudske delatnosti. Prirodna ograničenja čoveka da shvati ponašanje složenih sistema opredeljuju pristup oslonjen na “skrivanje” od korisnika, kada god je to moguće, unutrašnje složenost razmatranih sistema, kroz njegovo pretstavljanje korisnicima u formi lako razumljivih apstrakcija.

3.3. Faze evolucije informacionih sistema

Sa stanovišta faza evolucije informacionih sistema razlikujemo:

(1) SISTEME ZA OBRADU PODATAKA(Data processing)

(2) KLASIČNE UPRAVLJAČKE INFORMACIONE SISTEME(Management IS)

(3) INTERAKTIVNE (ON-LINE) UPRAVLJAČKE INFORMACIONE SISTEME (On-line IS)

(4) INFORMACIONE SISTEME ZA PODRŠKU ODLUČIVANJU(Decision Support IS)

(5) INTELIGENTNE INFORMACIONE SISTEME(Inteligent IS)

Prof. dr Branko Perišić 98

Page 99: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 99/110-------------------------------------------------------------------------------------------------------------------------------

Sistemi za obradu podataka pretstavljaju, u današnje vreme, samo istorijsku fazu transformacije informacionih sistema, budući da ih, sa aspekta savremene naučne misli u domenu razvoja informacionih tehnologija, gotovo i nemožemo smatrati informacionim sistemima. Zbog toga se u daljim razmatranjima nećemo vezati za ovu formu informacionih sistema.

Osnovna karakteristika klasičnih upravljačkih informacionih sistema je grupisanje oko “proizvodnje” informacija neophodnih upravljačkom delu složenih sistema kao osnov za planiranje, sprovođenje planova i kontrolu izvršenja planskih zadataka. U sklopu ovih informacionih sistema izvršena je integracija funkcija i obezbeđeno racionalno korišćenje podataka u svim segmentima organizacione strukture objektnog sistema, za čije potrebe su projektovani, ali kao oslonac u procesu upravljanja koriste produkte “istorijskih događanja” (upravljanje po posledici). Ovaj vid informacionih sistema, iako poseduje niz nedostataka sa aspekta savremene teorije upravljanja, pretstavalja u današnje vreme, posebno u našim uslovima, najzastupljeniju formu informacionih sistema.

Interaktivni (on-line) upravljački informacioni sistemi poseduju sve dobre karakteristike klasičnih upravljačkih informacionih sistema ali se, u podršci večini funkcionalnih transformacija, oslanjaju na direktnu interakciju čovek-računar pri čemu se podaci, neophodni za formiranje odgovora na proizvoljan informacioni zahtev, direktno unose, dok se rezultati njihovog procesiranja distribuiraju odmah po obradi i ostaju na raspolaganju ovlašćenim korisnicima u režimu direktnih upita posretstvom radnih stanica računarskog sistema koji služi kao tehnička podrška. Ovaj vid informacionih sistema unosi značajne promene na nivou operativnih funkcija organizacionog sistema kroz obezbeđivanje DISTRIBUCIJE PROCESNE MOĆI na mesta nastajanja podataka i direktnog operativnog korišćenja produkata obrade (informacija). Okosnicu u projektovanju ovakvih sistema obično pretstavlja TEHNOLOGIJA PROCESA RADA sistema koji je predmet automatizacije, pri čemu se od svih korisnika sistema zahteva poznavanje rada i intenzivno korišćenje savremenih sretstava informacionih tehnologija. Sa jedne strane interaktivni upravljački informacioni sistemi pretstavljaju otvoren izazov danas još uvek značajno zastupljenom načinu rada, dok ,sa druge strane, od neposrednih korisnika SVIH PROFILA zahtevaju daleko viši stepen operativnog poznavanja i korišćenja savremenih sretstava informacionih tehnologija. Ovaj drugi aspekt otvara značajne psihološke i organizacione probleme kao izvore rizika u procesu implementacije ove forme upravljačkih informacionih sistema. Stepen “informatičke kulture” organizacionog sistema, koji je predmet automatizacije, DIKTIRA uslove primene a vrlo često, ako je nedovoljno visok, pretstavlja

Prof. dr Branko Perišić 99

Page 100: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 100/110-------------------------------------------------------------------------------------------------------------------------------

značajan ograničavajući faktor implementaciji interaktivnih upravljačkih informacionih sistema. Pored toga ova forma informacionih sistema nedovoljno razmatra potrebe viših nivoa upravljanja u sklopu proizvoljnog organizacionog sistema, kao i neophodnost postojanja raznih formi AGREGIRANIH INFORMACIJA bez kojih se, na višim nivoima upravljanja, nemože zamisliti proces donošenja odluka.

Informacioni sistemi za podršku procesu odlučivanja pretstavljaju savremenu formu informacionih sistema razvijenu kao logično unapređenje koncepta interaktivnih upravljačkih informacionih sistema. Ogromna masa analitičkih podataka, i iz njih obradom izvedenih informacija, koji su prisutni u sklopu savremenih informacionih sistema, nije pogodna za BRZO DONOŠENJE ODLUKA i vođenje “politike” sistema u skladu sa njegovom osnovnom misijom, ako nije udružena sa funkcijama AGREGACIJE, SEMANTIČKE INTERPRETACIJE i automatizovane podrške generisanju različitih scenarija (varijanti) mogućeg ponašanja upravljanog sistema. Razvoj savremenih sretstava informacionih tehnologija omogućio je projektovanje sistema za podršku odlučivanju baziranih na EKSPERTSKIM ZNANJIMA i sistemima veštačke inteligencije, čija je osnovna namena NE DA ZAMENE EKSPERTA već da ga oslobode zamornih i dugotrajnih procedura i postupaka vezanih za obradu velike količine informacija i da mu SLUŽE kao podloga za donošenje kvalitativno boljih odluka u uslovima brzih promena u okruženju, odnosno prisutnih neodređenosti ili nepotpune definisanosti ponašanja sistema. Razmatranja vezana za tehnološke karakteristike sretstava informacionih tehnologija, metode i tehnike koje ih prate i sl., izlaze iz okvira teme ove knjige, no bitno je naglasiti da savremene metode projektovanja informacionih sistema upravo potenciraju oslonac na takve vidove rada. Sa druge strane brz razvoj komunikacionih sretstava omogućava GLOBALNO POVEZIVANJA udaljenih računarskih sistema, čime se enormno šire mogućnosti pristupa informacionim resursima, bez obzira na njihovu geografsku raspoređenost. Savremeno informatičko društvo U CENTAR SVOG RAZMATRANJA STAVLJA ZNANJE, kao esenciju semantičke analize potencijalno enormne količine raznorodnih informacija. Sistemi bazirani na ZNANJU, načinima pretstavljanja znanja i semantičkoj interpretaciji situacija u kojima se ta znanja mogu koristiti u procesu rešavanja proizvoljnih problema, pretstavljaju novu platformu za razvoj tzv. INTELIGENTNIH INFORMACIONIH SISTEMA.

Prof. dr Branko Perišić 100

Page 101: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 101/110-------------------------------------------------------------------------------------------------------------------------------

Jedna od osnovnih karakteristika inteligentnih informacionih sistema jeste da oni pretstavljaju objedinjavanje brojnih tehnologija koje su u ranijim fazama korišćene izolovano jedna od druge ili nisu uopšte korišćene. Sa aspekta “alata” neophodnih za implementaciju inteligentnih informacionih sistema možemo uočiti sledeće grupe:

(1) ALATI ZA OTKRIVANJE ZNANJA(Knowledge discovery tools)

(2) ALATI ZA OČUVANJE INTEGRITETA I KONTROLU KVALITETA (Integrity and quality-control tools)

(3) ALATI ZA RUKOVANJE HIPERMEDIJOM (MULTIMEDIJOM)

(4) ALATI ZA PODRŠKI PREZENTACIJI I PRIKAZIVANJU SEMANTIČKIH FORMI ZNANJA

(5) ALATI ZA PODRŠKU DONOŠENJU ODLUKA I ANALIZI SCENARIJA

(6) ALATI ZA PODRŠKU FORMATIZACIJI PODATAKA(preformatizacija i sl.)

(7) ALATI ZA PROJEKTOVANJE INTELIGENTNIH SISTEMA

Prof. dr Branko Perišić 101

Page 102: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 102/110-------------------------------------------------------------------------------------------------------------------------------

Alati za otkrivanje znanja obuhvataju alate za analizu podataka, mašinsko učenje i statističke analize, a postavljaju potpuno nove granice u domenu semantičkih analiza kroz podršku ekstrakciji ZNANJA često skrivenog iza PODATAKA odnosno INFORMACIJA, kao i skrivenih veza koje mogu postojati između pojedinačnih primeraka strukture podataka nad kojom je izgrađen razmatrani informacioni sistem.

Alati za očuvanje integriteta i kontrolu kvaliteta u sklopu složenih informacionih sistema pretstavljaju esencijalne alate budući da se, povečenjem globalno raspoložive količine informacija i uvođenjem savremenih informacionih sistema, organizacioni sistem u potpunosti oslanja na informacionu infrastrukturu koja ga podržava, pa samim tim postaje izuzetno “ranjiv” upravo preko te infrastrukture. S obzirom da se niti u jednom realnom sistemu verovatnoća otkaza nemože svesti na nulu kao i što se, u bilo kom realnom sistemu čije je ishodište ČOVEK, ne mogu eliminisati greške (bez obzira na motive i uslove pod kojima one nastaju) jasno je da egzistencija pouzdanih alata koji mogu obezbediti konzistentnost informacionog sistema i kontrolu kvaliteta pripadnika njegove infrastrukture ESENCIJALNA.

Hipermedija/multimedija pretstavlja savremeno sretstvo integrisanja više raznorodnih nosilaca informacije (slika, zvuk, tekst, slobodno pojmovno povezane tekstualne celine, asocijativne veze među objektima razmatranja i sl.) i formi njenog pretstavljanja, koja omogućava izgradnju individualnih “pogleda” različitih korisnika ili grupa korisnika na isti skup baznih informacija. Ovi alati se, u današnje vreme, ne mogu odvojiti od kategorije (4), alata za prezentaciju i prikazivanje različitih semantičkih formi znanja i/ili informacija, i/ili podataka.

Alati iz kategorije (5) omogućavaju podršku odlučivanju uz prezentaciju varijanti, uključivanje stepena neodređenosti (fuzzy) i prezentaciju objektivnih okolnosti pod kojima su razmatrane varijante odluke predložene.

Alati iz kategorije (6) pretstavljaju skup alata čija je osnovna namena podrška konverzijama različitih formata podataka/informacija/znanja, prisutnih u savremenim informacionim sretstvima i podrška postojanju više različitih informacionih platformi koje kooperiraju. Savremena informatička misao smatra neracionalnim “uništavanje” postojećih formi informacionih sistema i počinjanje procesa projektovanja IZNOVA, budući da je jedan od bitnih preduslova kontrolisanog i uspešnog razvoja informacionih sistema namenjenih podršci složenim organizacionim sistemima, OČUVANJE DOSADAŠNIJH INVESTICIJA iskazanih kroz sistem vrednosti činilaca informacionog sistema. Sa aspekta projektanata informacionih sistema uvek je najbolje krenuti iz

Prof. dr Branko Perišić 102

Page 103: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 103/110-------------------------------------------------------------------------------------------------------------------------------

početka i ne opterećivati se onim što su generacije projektanata pre toga radile i uradile. Sa aspketa onih koji su zaduženi za obezbeđenje materijalnih uslova za razvoj i implementaciju informacionih sistema, troškovi imaju značajan ako ne i preovladavajući uticaj. Zbog toga je neophodno da metodologija projektovanja informacionih sistema uključi u razmatranje aspekte koegzistencije različitih formi informacionog sistema i različitih platformi na kojima su te forme implementirane. Tu leži značaj alata iz kategorije (6), naime oni omogućavaju TRANSPARENTNOST različitih formi i platformi u sklopu različitih razvojnih faza informacionih sistema.

Izgradnja složenih informacionih sistema jeste KOLEKTIVNI PODUHVAT, složeni projekat za koji postoje različite metodologije, pri čemu niti jedna nije najbolja, ali je svaka od njih bolja od nemetodološkog i voluntarističkog pristupa.

WEB tehnologije! Gde i zašto?

Data-warehouse tehnologije! Gde i zašto?

Prof. dr Branko Perišić 103

Page 104: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 104/110-------------------------------------------------------------------------------------------------------------------------------

3.4. Metodološki aspekti projektovanja informacionih sistema

Projektovanje i implementacija upravljačkih informacionih sistema pretstavlja, kako u metodološkom tako i u tehničkom smislu, interdisciplinarnu delatnost koja se, u opštem slučaju, nikada ne završava. To je posebno očigledno za "uspešne" projekte koji su doživeli

nekoliko implementacionih faza, dovedeni u funkciju u sklopu jednog ili više segmenata organizacionog sistema za čije namene su projektovani i preživeli nekoliko tehnoloških transformacija .

Uspeh implementacije na računarima baziranih sistema meri se gotovo isključivo merom prenosivosti na različite platforme.

Dinamičan razvoj sretstava i metoda informacionih tehnologija otvara mogućnosti primene različitih platformi u različitim fazama implementacije podsistema upravljačkog informacionog sistema .

Sa stanovišta složenih organizacionih sistema taj izazov međutim retko biva prihvaćen zbog uverenja da jedino homogeni sistemi obezbeđuju uslove za kontinuirani razvoj upravljačkog informacionog sistema.

Dug period projektovanja, realizacije i uvođenja u eksploataciju na računarima baziranih sistema u uslovima složenih organizacija u potpunosti devalvira značaj homogenosti platformi budući da se sretstva informacionih tehnologija razvijaju neuporedivo brže nego što se projektantske ideje opredmećuju u praksi.

Dilema koju projektanti informacionog sistema i upravljačke strukture organizacionog sistema imaju u bilo kojoj fazi implementacije je kako obezbediti očuvanje "investicije" a očuvati usaglašenost pretstojećih faza sa aktuelnim stanjem razvoja sretstava informacionih tehnologija i metoda njihove primene.

Motiv očuvanja investicije uzrokuje određenu dozu "konzervativizma", najčešće karakterističnu za upravljačke strukture i neposredne korisnike funkcija informacionog sistema.

Želja za promenom uglavnom motiviše i rukovodi projektante informacionog sistema, što obično rađa konflikt i uzrokuje

Prof. dr Branko Perišić 104

Page 105: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 105/110-------------------------------------------------------------------------------------------------------------------------------

definisanje skupa ograničenja pod kojim je neophodno započeti i/ili realizovati svaku od narednih faza implementacije.

Profesionalna etika računarskih specijalista ne dopušta formulisanje rešenja koja nisu u skladu sa savremenim trendovima ili ne garantuju dugovečnost i fleksibilnost rešenja koja se u aktuelnom trenutku nude.

Profesionalna etika i odgovornost upravljačkih struktura preduzeća ne dopušta rizik degradiranja funkcionalnosti ili čak ugrožavanja dostignutog stepena razvoja, za račun održavanja koraka sa savremenim trendovima u domenu informacionih tehnologija.

Iskustva pokazuju da je težnja ka novim sretstvima i metodama primarni interes projektanata a ne krajnjih korisnika na operativnim ili upravljačkim funkcijama u sklopu razmatranog organizacionog sistema.

Zbog toga je u većini situacija izuzetno teško obrazložiti potrebu za migracijom funkcionalno stabilnog segmenta informacionog sistema na tehnološki ili metodološki novije platforme.

Model životnog ciklusa upravljačkog informacionog sistema se ne može poistovetiti sa modelom životnog ciklusa softverskog proizvoda budući da je softver, iako izizetno značajan segment stvaranja "virtualne organizacije", ipak samo jedan od elemenata upravljačkog informacionog sistema.

Upravljački informacioni sistemi, sa projektno definisanim ciljem, doživljavaju transformacije u skladu sa promenama u organizacionoj, funkcionalnoj i tehnološkoj sferi, pa je u razmatranja, u svakoj fazi realizacije, neophodno uključiti pojam migracije, kao sretstva za evoluciju implementacije upravljačkog informacionog sistema ka njegovom projektovanom modelu .

Prof. dr Branko Perišić 105

Page 106: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 106/110-------------------------------------------------------------------------------------------------------------------------------

Model životnog ciklusa upravljačkog informacionog sistema, baziran na stalnim migracijama (CMLCM - Constant Migration Life-Cycle Model), podrazumeva eliminaciju dva bitna rizika u razvoju upravljačkih informacionih sistema složenih organizacija:

a. rizik gubitka funkcionalnosti pri migracijib. rizik zastarevanja koncepata ako se

migracija ne obavi

Budući da kao podlogu ima evolutivni a ne revolucionarni pristup navedeni model predstavlja podlogu za reinžinjerstvo postojećih sistema i njihovo transformisanje u nove, bez gubitka funkcionalnosti.

Osnovne postavke na kojima se CMLCM zasniva su:

(1) podrška heterogenim sistemima (raznorodne platforme bez ikakvih ograničenja)

(2) podrška koegzistenciji različitih alata i tehnika u različitim fazama izgradnje upravljačkog informacionog sistema

(3) očuvanje funkcionalnosti pri migraciji

Prof. dr Branko Perišić 106

Page 107: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 107/110-------------------------------------------------------------------------------------------------------------------------------

Prethodni stadijum obuhvata raniju funkcionalnost implementiranu u sklopu upravljačkog informacionog sistema u skladu sa metodama i tehnikama izabranim za taj stadijum implemetnacije.

Put ka sledećem stadijumu u razvoju podrazumeva infiltriranje migracionog nivoa čiji je osnovni zadatak kreiranje "virtualne organizacije" i obezbeđenje korisničke odnosno funkcionalne transparentnosti više različitih platformi nad kojima je izgrađen.

Migracioni nivo obezbeđuje lagan prelazak na novi stadijum uz očuvanje svih dobrih karakteristika prethodne faze razvoja i eliminaciju onih koje su pretstavljale balast ili posledicu pogrešnih koraka u prethodnoj fazi.

Nova saznanja i nove funkcionalnosti se, u skladu sa savremenim trendovima u domenu informacionih tehnologija, implementiraju u sistem na migracionom nivou, što obezbeđuje stalnu usklađenost sa savremenim dostignućima u oblasti informacionih tehnologija.

Novi stadijum karakteriše postojanje "hiper-sistema" čija je unutrašnja složenost za krajne korisnike transparentna.

Osnovni teret u primeni CMLCM metodološkog pristupa prebačen je na projektante sistema čime se pred njih postavlja daleko teži zadatak nego u slučaju revolucionarnih akcija.

Prof. dr Branko Perišić

Stadijum (teku}i)

Stadijumi+1 (slede}i)

Stadijumi-1 (prethodni)

Data org.Si-1

Data org.Si

Data org.Si+1

Data (Mi )migration

Slika 1. Osnovni CMLCM

107

Page 108: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 108/110-------------------------------------------------------------------------------------------------------------------------------

CMLCM je namenjen vrhunskim profesionalcima od kojih se zahteva poznavanje više platformi, metoda i tehnika i njihova kreativna primena u konkretnim uslovima sistema koji se migrira.

Prof. dr Branko Perišić 108

Page 109: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 109/110-------------------------------------------------------------------------------------------------------------------------------

Intranet koncept

Primenom CMLCM metodološkog pristupa i rezultata istraživanja u domenu metodologije projektovanja informacionih sistema, formulisana je tronivovska struktura standardne aplikacije (Slika 3.).

Slika 3. Model Intranet-aplikacije

a) Prezentacioni nivo aplikacije

Standardizacija prezentacionog nivoa svih softverskih proizvoda, koji čine softversku stranu upravljačkog informacionog sistema, ima za osnovni cilj razdvajanje prezentacionog aspekta od informatičke (softverske/ informacione i hardverske) infrastrukture koja leži u pozadini implementirane funkcije.

Time se omogućava upotreba standardnih Web-čitača, kao elemenata prezentacionog podsistema aplikacije, čime se unutrašnja organizacija čini transparentnom sa aspekta korisnika bilo kog nivoa ili profila.

Zbog nerezidentne prirode prezentacionog nivoa aplikacije, gubi se potrebe za instalacijama klijentskih programa a održava klijent-server platforma. Svaka promena u sklopu "skrivenih elemenata" aplikacije, bez obzira da li predstavlja potpuno novu ili izmenjenu funkcionalnost, postaje trenutno korisnički dostupna samom svojom pojavom na WEB serveru i/ili APLIKATIVNOM serveru.

Standardna priroda HTTP protokola i usluga na kojoj je bazira prezentacioni nivo aplikacije omogućava proširenje aplikativnih usluga i van granica Intranet-a tj. ka Ekstranet-u odnosno Internet-u, zavisno od prirode servisa i prava pristupa korisnika.

Prof. dr Branko Perišić 109

Prezentacioni

nivo

Programska

Struktura

Informacioni resursi

Page 110: informacioni sistemi knjiga

Osnovi Informacionih sistema i Softverskog inenjerstva 110/110-------------------------------------------------------------------------------------------------------------------------------

b) Programska struktura

Formulisana transparentnost na prezentacionom nivou uslovljava usložnjavanje strukture programskog segmenta aplikacije. Na ovom nivou je moguće izolovati dva osnovna podnivoa:

b.1. Prilagodni nivo aplikacije, sa osnovnim zadatkom adaptacije na karakteristike WEB-čitača i interpretacije zahteva

b.2. Uslužni nivo aplikacije, koji implementira zahteve i služi kao sprega sa informacionom infrastrukturom (niži nivo). Uz oslonac na ovaj podnivo obezbeđuje se navigacija u sklopu informacione infrastrukture u skladu sa interpretiranim zahtevom sa gornjeg podnivoa.

c) Informacioni resursi

Unutrašnji nivo aplikacije, koji implementira mehanizme pristupa informacionim resursima, obezbeđuje izolovanje informacione infrastrukture (enkapsulacija) od nadređenog nivoa aplikacije.

Oslonac na standardnu strukturu aplikacije omogućava da se, umesto kreiranja kompletnog paralelnog upravljačkog informacionog sistema za internu upotrebu, sa bilo koje tačke lokalne računarske mreže bilo kojim Web browser-om, pristupiti bilo kom informacionom resursu, u skladu sa implementiranom politikom zaštite.

Iskoristi blagodeti Interneta, da se jednostavno i relativno jeftino pristupiti informacijama, dokumentima i bazama podataka, konekcijama sa udaljenih kancelarija, predstavlja tehnički izazov za projektante upravljačkih informacionih sistema.

Prof. dr Branko Perišić 110