formalna definicija #1

[lnxfsf]

formalna definicija 1 (prvi) pokusaj :)

[lnxfsf]

FORMAL DEFINITION

GONNA IMPLEMENT

• user stories
• konceptualna mapa

[sa Gaphor]

• Sistemski dijagram sekvenci
• Dijagrami sekvenci objekata
• Modelovanje domena
• Asocijacije koncepata

NOT IMPLEMENTED

• Dijagram klasa
• Izvlačenje parcijalnog modela domena
• Traceability Matrica

Ostalo

• Šta je aktor, koncept, Use Case ?
• Takeaway
• Pitanja
  
  
  

---

---

---

Rešavanje

---

Grupica 1

user stories

---

---

---

---

User stories

user-stories - is a brief description of a piece of system functionality as viewed by a user.

User stories are written in a free-form, with no mandatory syntax, but generally they are fitting the form:
user-role + capability + business-value

• estimated effort size - definisi, koliko bi ti vremena trebalo neku funkcionalnost da izradis (ovo sto si izvukao, funkcije vidljive.. ) (otprilike sketch)

• identifier - za to koristi, bilo sta, neku oznaku koja ti se sviđa, npr: XAE

• User story - objasnjava, sta taj korisnik (aktor) oce da postigne, ne, nije bitno, da li on klikće, na, dugme, bitno je samo, šta taj korisnik zeli da postigne (znaci, otprilike ovde ce biti kraće, ono, da kuca u tastaturu i to ubija vanzemaljce, da imam high scores ) i primeni cak i user stories te koje neces izraditi, sto je van vremenski, bitno je samo da imas, ono, sta bi sve moglo da bude..

---

Konceptualna mapa

to je kada prikazuje sva STANJA koje koncepti mogu da imaju.

koncepti, to je valjda, nesto, ono, 'koncept', 'abstraktno', ye, verovatno...

Konceptualna mapa u softverskom inženjeringu predstavlja grafički prikaz koncepta, ideja, i odnosa između njih koji su bitni za određeni softverski projekt ili sistem. Ova mapa služi kao alat za vizuelizaciju i organizovanje različitih aspekata softverskog sistema, kao što su funkcionalnosti, arhitektura, korisničko iskustvo, i slično.
Konceptualne mape se često koriste u procesu razvoja softvera kako bi se jasno prikazali ciljevi projekta, potrebe korisnika, funkcionalni zahtevi, i drugi aspekti koji su ključni za uspešan razvoj softverskog proizvoda. One omogućavaju programerima, dizajnerima, menadžerima i drugim članovima tima da lako komuniciraju i dele ideje, kao i da se fokusiraju na ključne aspekte projekta i njihove međusobne odnose

---

Ček šta radimo uopšte:

Analiza zahtjeva determiniše kakve će biti interakcije korisnika sa budućim sistemom (eksterno ponašanje)
Modelovanje domena determiniše kako elementi sistema interaguju (interno ponašanje) kako bi produkovali eksterno ponašanje

---

---

---

GAPHOR

za ovo dalje ti treba u gaphor softwer da izradis..

---

Sistemski dijagram sekvenci

OVO JE: za interakcije aktera umjesto interakcija objekata softvera.

U ovoj fazi razvoja, ne smije se ići sa dekompozicijom sistema. Svrha sistemskog dijagrama sekvenci je (kao i kod slučajeva korišćenja), da se reprezentuje koje informacije moraju preći granice sistema i kojim redosljedom. Sistem se mora pojaviti u vidu jednog box-a, dok svi ostali entiteti moraju biti akteri.

Sistem se mora pojaviti u vidu jednog box-a, dok svi ostali entiteti moraju biti akteri.

znaci, user, otkljucava vrata, i onda, ga sistem (black box ! ), pita za sifru, kada je ok, onda sistem, dalje salje eksternim akterima (koji su dodatak sistemu), da upravljaju stanjima koje sistem zeli da postigne..

---

Dijagrami sekvenci objekata

Dijagrami sekvenci objekata reprezentuju interacije objekata unutar sistema

znaci, ona slika koju si koristio u sistemski dijagram sekvenci, i sada lupom uveličan taj 'Sistem', black box, se sada opisuje

ovo je sve spada uz ovo (msm uz komentar: 'lol, pa normalno, to se podrazumeva, lol'), samo isprati sto trazi teoretski.. i kako u gaphor il gde vec da se definise ovo dijagrami, definisemo jedan princip i keep consistent ...

Dijagrami interakcije

---

Modelovanje domena

Modelovanje domena determiniše kako elementi sistema interaguju (interno ponašanje) kako bi produkovali eksterno ponašanje

Modelovanje domena radimo na osnovu izvora:
– Znanje o tome kako budući sistem treba da se ponaša (na osnovu analize zahtjeva, na primjer, use case-ova)
– Proučavanje radnog domena (ili, domena problema)
– Baza znanja o softverskim dizajnima

U domenskoj analizi (modelovanje domena), mi sistem vidimo kao “providnu kutiju”

Izgrađivanje modela domena osnovu Use Case-ova

Model domena se opisuje na način sličan konceptualnim mapama

Možemo zamisliti da sada, na osnovu use case scenarija i sistemskih dijagrama sekvenci, dodijeliti odgovornosti
Tako npr, KeyChecker provjerava da li je validan ključ. KeyStorage je “radnik” koji memoriše ili vodi evidenciju o validnim ključevima, itd

Instrukcije:

• Pri izgradnji modela domena, pametno je krenuti od granice, odnosno, periferije sistema.

• Počinjemo, dakle, dodjeljivati koncepte koji će pokriti interakcije između sistema i spoljašnjeg svijeta.

• Granični objekti prikupljaju informacije od aktera i transformišu ih u formu koju razumiju interni objekti.
  Granični objekti mogu transformisati informacije i u suprotnom smjeru (informacije iz internih objekata se prevode u format pogodan za aktere)

• Controller je “radnik” koji uzima narudžbe “klijenata” a zatim orkestrira rad drugih “radnika” u sistemu.

Identifikovanje koncepata

ako se nešto treba završiti, mora biti spomenuto eksplicitno i nekome (objektu) mora biti dodijeljena odgovornost.
Kompleksne odgovornosti mogu biti pridružene većem broju radnika, i obrnuto, moguće je da jedan radnik ima više odgovornosti.

• Ekstrakcija (izdvajanje) odgovornosti - znaci, svaki objekat, OPIŠEŠ, sta je njegova odgovornost !

not implemented

• Izvlačenje parcijalnog modela domena

Asocijacije koncepata

Asocijacije opisuju ko treba da radi zajedno i zašto, a ne kako će raditi zajedno.
Asocijacije su linije koje povezuju koncepte. Svaka linija nosi naziv asocijacije, a opciono može sadržati i pravac čitanja (u vidu strelice).

Treba imati na umu da je mnogo bitnije identifikovati koncepte, nego asocijacije (i atribute).

Navedene strelice ne označavaju pozive funkcija, one samo anticipiraju kolaboraciju između povezanih koncepata (slično kao kada osobe sarađuju – tada sjede u istim kancelarijama).

podskup ovoga:

Atributi koncepata

Model domena može sadržati atribute, kao što je prikazano na prethodnoj slici.

Primjeri atributa su: deviceStatuses (sa validnim vrijednostima “activated” i “stopped”), koji čuvaju trenutno stanje fizičkog uređaja kojeg kontroliše HouseholdDeviceOperator.

Pri (ovoj) analizi, fokus bi trebalo da bude na tome šta treba da se radi, a treba izbjegavati pitanje kako se stvari rade

Naravno, to nije uvijek moguće uraditi.

---

---

---

Not Implemented

Dijagram klasa

ovo je podskup "Dijagrami sekvenci objekata", za "Dijagrami interakcije" , da klase koje si definisao, opises njihove funkcije ?

Broj operacija u klasama korelira sa veličinom odgovornosti koju posmatrana klasa ima.

Šta znače te UML dijagrami oznake

+    public
#    protected (atributi se vide samo u klasi i u izvedenim klasama)
-    private (atributi se vide samo unutar klase)

---

Izvlačenje parcijalnog modela domena

kod Identifikovanje koncepata, nisam uradio opet, Izvlačenje parcijalnog modela domena, isto nesto sa nekim dijagramima

---

Dijagrama aktivnosti

Detaljna specifikacija use case modela se grafički predstavlja dijagramom aktivnosti

Dijagram aktivnosti detaljnije opisuje slučajeve korišćenja, njihove detaljne aktivnosti, scenarije, moguća ponašanja, interakcije itd.

Dijagram aktivnosti treba da ukaže na to šta sistem treba da uradi, a ne kako to sistem radi

– Kada i kako use case počinje i završava se?
– Kakvu interakciju ima use case sa akterima?
– Koji podaci su potrebni use case-u?
– Normalni niz aktivnosti u samom slučaju korišćenja
– Prikaz bilo kojih alternativnih ili izuzetnih tokova

---

Traceability Matrica

---

Šta je aktor, koncept, Use Case ?

Actors - akteri – Agenti mimo sistema, koji interaguju sa sistemom

Koncepti / Objekti – Agenti koji rade unutar sistema i omogućavaju njegovo funkcionisanje

Use Cases – slučajevi korišćenja

– Scenariji korišćenja sistema (ne razmatra se šta se dešava u sistemu)
– Predstavlja elementarne operacije sistema, dijalog između korisnika i sistema
– Definiše koje informacije tada moraju preći granicu sistema

Još o **UseCases**:

A set of use cases describes the elemental tasks a system is to perform and the relation between these tasks and the outside world. Each use case description represents a dialog between the user and the system, with the aim of helping the user achieve a business goal. In each dialog, the user initiates actions and the system responds with reactions.
The use cases specify what information must pass the boundary of the system in the course of a dialog (without considering what happens inside the system).

Znaci, ovo je related sa User Stories !

Moze i sa dijagramom Use Cases, da imas aktere, koji rade sto je opisano sada za ovaj UseCases...

---

---

---

Takeaway

--> RRD – responsibility driven design je popularni micro-level pristup.

Tri su tipa odgovornosti:
tip 1: knowing, tip 2: doing i tip 3: communicating

znaci, ovako objekte pravi..

---

--> mi koristimo Induktivni pristup (od dole na gore, botto-up), gdje se principi dizajna i dizajn pattern-i lokalno primjenjuju na nivou softverskih objekata (micro-level dizajn).

---

--> objekti da sto vise budu definisani kao:

Princip eksperta koji radi - checker je za checking keys i to je to. nista drugo se ne meša, controller je za upravljanje, svim uredjajima (orchestrating)

---

--> PREPORUKA: msm da je "Dijagrami sekvenci objekata" , je najbolje uraditi jednom ugrubo PRE izrade, nesto, otprilike, kako bi nesto realizovao.
to se ubaci ovde u discussion, da ima track..

i zatim, se pocne programirati po tome, otprilike, definitivno ce biti izmjene, u tom dijagramu, rekao bih, da dijagram treba da prati samu izradu koda.
da kada izradis neki kod, funkciju i slicno, i commit-ujes, nesto sto je sredjeno otprilike, onda azuriras ovaj "Dijagrami sekvenci objekata", da reflect-uje changes u samome kodu.

U Discussion, referenciraj pull request (commit), i koji je njemu izmenjen njegov "Dijagrami sekvenci objekata".

Tako, se moze keep track ovih "Dijagrami sekvenci objekata", kojih ce biti najvise izmena, zbog samog programiranja..

---

---

---

Pitanja ?

Pitaj profu, da li treba ovo (dijagram klasa) uraditi ? nesto nije pominjano ?
da necemo raditi ove odgovor

---

• ^{vidi prezentacije, za dijagrame i slicne slike, za izradu.. po tome ides.}

[lnxfsf]

ovo koristi kao referencu, kako da ides redosledno..

[lnxfsf]

Pitanje

Npr. nije mi jasno, da li ja moram da napravim i Use Case dijagram, kao i tabelu za UseCase, i jos User Stories ? Msm, konfuzno je, kao da se ponavljam vise puta istu stvar da radim..
Da li ja, ako meni odgovara da Use Case predstavim preko tabele , da cio Use Case, samo koristim tabele; da ne moram ponovo i praviti dodatne dijagrame itd..



Da li je dovoljno, za pocetak (pa se tokom izrade, ako mi je potrebno, nadopunjujem), da imam samo Use Case, Dijagram sekvenci objekata, i Sistemski dijagram sekvenci .

Da li ovo 'osnovno' treba sve da se implementira, kao 'teorijski' dio ?
user stories
konceptualna mapa
Sistemski dijagram sekvenci
Dijagrami sekvenci objekata
Modelovanje domena
Asocijacije koncepata

Ne znam da li ovo treba uopšte ?
Dijagram klasa
Izvlačenje parcijalnog modela domena

Traceability Matrica



a "Use Case", da li to treba i dijagram, i kao tabela, i kao user stories ?

---

Odgovor profesora

User Stories i UseCase su alternativa jedno drugom, dok je UseCase dijagram koncizna reprezentacija UseCase-a. Preporučujem dakle dijagram da crtate, a tabelarnu predstavu koristite onda kada se dijagramom ne mogu prikazati dovoljno detaljno svi elementi. U suštini, tabelu koristite za ono što je nakomplikovanije, kako biste to razjasnili i sebi i drugima. Takođe, napravite i jednu tabelu sa popisom UseCase-ova, kako biste bolje pratili šta sve imate.
Pošto postoji više UseCase-ova za svaki softver, nećete moći da pokrijete sve dijagramima, pa koristite dostupne alate u skladu sa potrebama.

Dakle, za UseCase-ove ne mora sve da se iskoristi, već radite u skladu sa potrebama.

Da li ovo 'osnovno' treba sve da se implementira, kao 'teorijski' dio ?
user stories
konceptualna mapa
Sistemski dijagram sekvenci
Dijagrami sekvenci objekata
Modelovanje domena
Asocijacije koncepata

Da, ti dijagrami koje ste naveli su za početak, a ključno je da u nekom trenutku dođete do dijagrama sekvenci sa objektima.

---

Komentar

Ne znam da li ovo treba uopšte ?
Dijagram klasa
Izvlačenje parcijalnog modela domena


Traceability Matrica

Smatraću ovo kao neobavezno, ali to ne znači, da ne treba da pokušaš da implementiraš, ako ima smisla....

I kao što već navedeno ovde negde, prvo kodiraj, pa onda vidi šta si uradio... Naravno, usled rešavanja problema, kreiraš Issues, Discussions, i slicno, da keep track. Da se ne bi petljali previše oko teorije, a sami kod je prostiji nego što bi to napravili u teoriji.. ( mindset: nzm šta će mi trebati, dok to ne vidim u kodu, da li mi to uopšte i treba, zašto da se raspisujem u dijagramima i ispravljam milion dijagrama, kada je implementacija u kodu, prostija, nego milion reči i dijagrama.. meni su dijagrami u textu, sve što se napiše, hiljadu puta lakse.. ( Issues, ovi Discussions, i sl.. ) )