Integrisanje svih komponenti, verifikacija, validacija, instalacija, obuka
Resultati testiranja, funkcionalan sistem
Održavanje Popravljanje bagova, modifikacije, adaptacija Verzije sistema
Logički model sistema
Logički model sistema opisuje šta je sistem ili šta sistem mora da radi – ne kako će sistem biti implementiran.
Model može sadržati: Modele podataka (npr. dijagram klasa) Modele procesa (npr. sekvencijalni dijagram) Modele interakcije korisnika (npr. dijagrami slučajeva upotrebe)
Opisi su realizovani korišćenjem jezika za modelovanje Formalnog (ili delimično formalnog) Razumljivog (vizuelnog ili tekstualnog)
4
Pristupi modelovanju
Pristupi modelovanju se razlikuju jedan od drugog na osnovu viđenja sveta (sistema)
5
Strukturni modeli Modeli ponašanjaFokusirani na opisivanju strukture sistema – elementi koji su fiksni i ostaju nepromenjeni tokom vremena
Fokusirani na dinamici sistema: kako se sistem menja tokom vremena
Primer iz arhitekture: Model strukturne arhitekture
6
Planovi za gradski centar Filadelfije(1953)
Primer iz arhitekture: Modelovanje ponašanja
7
Modeli ponašanja Filadelfijskog saobraćaja (1953)
Sadržaj
Uvod
Klase, atributi i operacije
Relacije
Generalizacija
Uputstvo za efikasno modelovanje klasa
8
Objektno-orjentisani pristup
Objekti su abstrakcija entiteta iz realnog sveta ili sistema
9
Realni domen Domen modela
vozilo
automobil
autobus
solja
modeluje
modeluje
modeluje
Presenter
Presentation Notes
Druga vrsta podataka sa kojima operiše Java program su objekti. Objekti predstavljaju osnovni koncept objektno-orijentisane paradigme u modelovanju sistema. Svaki objekat realnog sistema koga posmatramo predstavljamo odgovarajućim objektom koji je sastavni deo modela sistema. Objekte koji imaju zajedničke osobine (ne moraju imati iste vrednosti tih osobina) možemo da opišemo klasom. U tom smislu, objekat je jedna instanca (primerak) svoje klase. Klasa, dakle, predstavlja model objekta, koji obuhvata atribute i metode.
buy()display()
serialNumbernameprice
Produt
Klase
Klasa je šablon za stvarne instance u memoriji
10
Ime klase
Atributi
Operacije
Presenter
Presentation Notes
Klasa je opis skupa objekata koji dele iste atribute, operacije, relacije i semantiku. Svaka klasa mora imati ime da bi se razlikovala od drugih. Kada ime stoji samo, naziva se jednostavno ime; kada je naveden I paket u kome se klasa nalaz u obliku prefiksa, tada se zove ime sa putanjom. Ime klase mora biti jedinstveno u okviru paketa kome klasa pripada.
Atributi - Signatura
[vidljivost] ime [višestrukost] [: tip] [=početna-vrednost] [{osobina-string}]
An attribute is a named property of a class that describes a range of values that instances of the property may hold. A class may have any number of attributes or no attributes at all. An attribute represents some property of the thing you are modeling that is shared by all objects of that class. For example, every wall has a height, width, and thickness; you might model your customers in such a way that each has a name, address, phone number, and date of birth. An attribute is therefore an abstraction of the kind of data or state an object of the class might encompass. At a given moment, an object of a class will have specific values for every one of its class's attributes. Graphically, attributes are listed in a compartment just below the class name. Attributes may be drawn showing only their names, as shown in Figure 4-3.
Atributi - Primeri
+ isLightOn : boolean = false
- numOfPeople : int
mySport
+ passengers : Customer[0..10]
- id : long {readOnly}
12
Operacije - Signatura
[vidljivost] ime [(lista-parametara)] [: tip-povratne-vrednosti] [{osobina-string}]
Operacija može imati nula ili više parametara od kojihsvaka ima sintaksu: [direction] name : type [=default-value] Direction može biti: in (input paremtar – pozivalac ga ne može
modifikovati), out (output parametar - nema ulazne vrednosti. finalna vrednost je dostupna pozivaocu), inout (ulazni parametar koji se može modifikovati)
Svojstvo: {leaf} – konkretna operacija {abstract} – ne može se pozivati direktno … 13
Presenter
Presentation Notes
An operation is the implementation of a service that can be requested from any object of the class to affect behavior. In other words, an operation is an abstraction of something you can do to an object and that is shared by all objects of that class. A class may have any number of operations or no operations at all. For example, in a windowing library such as the one found in Java's awt package, all objects of the class Rectangle can be moved, resized, or queried for their properties. Often (but not always), invoking an operation on an object changes the object's data or state. Graphically, operations are listed in a compartment just below the class attributes. Operations may be drawn showing only their names, as in Figure 4-5.
public (+) – spoljašnji objekti mogu pristupiti članu
private (-) – samo unutrašnje metode mogu pristupiti članu
protected (#) – samo interne metode, ili metode specijalizovanih objekata mogu pristupiti članu
15
+ buy()+ display()- swap(x:int,y: int)
- serialNumber- name# price
Produt Treba težiti da se očuva najmanja moguća vidljivost
Presenter
Presentation Notes
Visibility One of the most important details you can specify for a classifier's attributes and operations is its visibility. The visibility of a feature specifies whether it can be used by other classifiers. In the UML, you can specify any of three levels of visibility. A classifier can see another classifier if it is in scope and if there is an explicit or implicit relationship to the target; relationships are discussed in Chapters 5 and 10; descendants come from generalization relationships, as discussed in Chapter 5; friendship allows a classifier to expose its private parts, as discussed in Chapter 10. 1. public Any outside classifier with visibility to the given classifier can use the feature; specified by prepending the symbol + 2. protected Any descendant of the classifier can use the feature; specified by prepending the symbol # 3. private Only the classifier itself can use the feature; specified by prepending the symbol - Figure 9-3 shows a mix of public, protected, and private figures for the class Toolbar.
name = “IMac 1C”price = 1456 $serialNumber = 184934
Apple IMac : Product
name = “Vaio Portable”price = 2999 $serialNumber = 113234
Sony Vaio : Product
In runtime
Dijagram klasa Objektni dijagram
Presenter
Presentation Notes
COMMENT: Should be placed after the basic class diagram slides Object diagrams are relevant to a specific moment in the runtime of the system Therefore, object diagrams capture the state of instances – the value of their attributes Methods are not included in the object diagram Object diagrams are used to: Model examples of system runtime Define acceptable or unacceptable states (important for system testing) Define situations of bounded
Sadržaj
Uvod
Klase, atributi i operacije
Relacije
Generalizacija
Uputstvo za efikasno modelovanje klasa
18
19
Relacije
Relacija je šablon za konekciju između dve instance.
Relacije su organizovane u hijerarhiju: Zavisnost: ukazuje na relacije između
klasa u vreme izvršenje Asocijacije: postojane relacije Kompozicija: celina-deo veze
20
Dependency
Association
Composition Aggregation
Presenter
Presentation Notes
A relationship is a connection among things. In object-oriented modeling, the three most important relationships are dependencies, generalizations, and associations. Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the kinds of relationships. Dependency A dependency is a using relationship that states that a change in specification of one thing (for example, class Event) may affect another thing that uses it (for example, class Window), but not necessarily the reverse. Graphically, a dependency is rendered as a dashed directed line, directed to the thing being depended on. Use dependencies when you want to show one thing using another. Notes are discussed in Chapter 6; packages are discussed in Chapter 12. Most often, you will use dependencies in the context of classes to show that one class uses another class as an argument in the signature of an operation; see Figure 5-2. This is very much a using relationship—if the used class changes, the operation of the other class may be affected, as well, because the used class may now present a different interface or behavior. In the UML you can also create dependencies among many other things, especially notes and packages. Different kinds of dependencies are discussed in Chapter 10; stereotypes are discussed in Chapter 6. Note A dependency can have a name, although names are rarely needed unless you have a model with many dependencies and you need to refer to or distinguish among dependencies. More commonly, you'll use stereotypes to distinguish different flavors of dependencies. 1 .asocijacija�mogucnost jedne instance objekta da pozove member funkciju druge instance.�E sad to moze na vise nacina. Preko lokalnih varijabli, preko parametara,�preko clanova klase.��2. agregacija�isto sto i asocijacija plus sto referirane instance ne mogu oformiti ciklicnu zavisnost.�Znaci nema dvosmerne zavisnosti.��3. kompozicija�isto sto i agregacija plus sto je klasa koja drzi reference odgovorna�za njihov zivotni vek.�
buy()display()
serialNumbernameprice
Produt
checkout()addProduct(Product p)clearAll()
orderIDdate
Order
includes
* *
Asocijacije
Objekti na obe strane asocijacije mogu pronaći jedan drugog
Relacija je konzistentna vremenu (osim ako je uklonjenja)
21
Ime + smer čitanja
VišestrukostUkazuje na kardinalnost• –1:1 podrazumevano•3 – tačno 3 objekta•* (or n) - neograničeno•1..* - 1 do beskonačno•3..9 – 3 do 9
Presenter
Presentation Notes
Association Associations and dependencies (but not generalization relationships) may be reflective. An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Given an association connecting two classes, you can navigate from an object of one class to an object of the other class, and vice versa. It's quite legal to have both ends of an association circle back to the same class. This means that, given an object of the class, you can link to other objects of the same class. An association that connects exactly two classes is called a binary association. Although it's not as common, you can have associations that connect more than two classes; these are called n-ary associations. Graphically, an association is rendered as a solid line connecting the same or different classes. Use associations when you want to show structural relationships. Beyond this basic form, there are four adornments that apply to associations. Don't confuse name direction with association navigation, as discussed in Chapter 10. Name An association can have a name, and you use that name to describe the nature of the relationship. So that there is no ambiguity about its meaning, you can give a direction to the name by providing a direction triangle that points in the direction you intend to read the name, as shown in Figure 5-4. Note Although an association may have a name, you typically don't need to include one if you explicitly provide role names for the association, or if you have a model with many associations and you need to refer to or distinguish among associations. This is especially true when you have more than one association connecting the same classes. �Roles are related to the semantics of interfaces, as discussed in Chapter 11. Role When a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the near end of the association presents to the class at the other end of the association. You can explicitly name the role a class plays in an association. In Figure 5-5, a Person playing the role of employee is associated with a Company playing the role of employer. Note The same class can play the same or different roles in other associations. �An instance of an association is called a link, as discussed in Chapter 15. Multiplicity An association represents a structural relationship among objects. In many modeling situations, it's important for you to state how many objects may be connected across an instance of an association. This "how many" is called the multiplicity of an association's role, and is written as an expression that evaluates to a range of values or an explicit value as in Figure 5-6. When you state a multiplicity at one end of an association, you are specifying that, for each object of the class at the opposite end, there must be that many objects at the near end. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can even state an exact number (for example, 3). Note You can specify more complex multiplicities by using a list, such as 0..1, 3..4, 6..*, which would mean "any number of objects other than 2 or 5." �Aggregation has a number of important variations, as discussed in Chapter 10. Aggregation A plain association between two classes represents a structural relationship between peers, meaning that both classes are conceptually at the same level, no one more important than the other. Sometimes, you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole has objects of the part. Aggregation is really just a special kind of association and is specified by adorning a plain association with an open diamond at the whole end, as shown in Figure 5-7.
Navigacija
Ukoliko je asocijacija usmerena, poruke se mogu prosleđivati samo u tom smeru.
Ukoliko asocijacija nema smerove, onda je definisana kao dvosmerna asocijacija, a poruke se mogu prosleđivati u oba smera.
Podrazumevano je da su sve relacije usmerene, osim ako zahtevi ne diktiraju dvosmerne relacije.
22
Folder File
Zbog čega je usmerena? Na primer, ako želimo da znamo fajlove svakog foldera. Ipak, nemamo zahtev da znamo folder svakog fajla.
Imena uloga
Imena mogu biti dodata na svaki kraj asocijacije
Obezbeđuje bolje razumevanje značenja asocijacije
Posebno je značajna u samo-asociranim klasama.
23
Person
Manager
Worker
Manages
Companyemployee employer
*
1..0
..*1 0..1
Ograničenja
Ograničenja su jednostavna svojstva asocijacija, klasa i mnogih drugih elemenata u UML-u
Definiše ograničenja koja implementatori moraju da zadovolje
24
Windowlengthwidth
{0.8 ≤length/width≤1.5}
Ograničenja atributa
Ograničenja
25
Project
Task
Outsource
{xor}
Employeesalary
boss
{salary < boss.salary}*
Samo jedna od asocijacija može postojati za datu instancu (značenje “or”)
Committee*
**
memberOf
chairOf{subset}
*
0..1
Ograničenja
Ograničenja se mogu primeniti na skoro svaki element u UML dijagramima, korišćenjem: Prirodnog jezika Matematičke notacije OCL (Object Constraint Language)
Iskazi: nepromenljive: interest > 3% Preduslovi: pre izršenja pozajmica(), prodaja > 5,000$ Posledice: nakon izvršenja pozajmica(), periodOtplate= 1 or 10
26
Presenter
Presentation Notes
There are four types of constraints: An invariant is a constraint that states a condition that must always be met by all instances of the class, type, or interface. An invariant is described using an expression that evaluates to true if the invariant is met. Invariants must be true all the time. A precondition to an operation is a restriction that must be true at the moment that the operation is going to be executed. The obligations are specified by postconditions. A postcondition to an operation is a restriction that must be true at the moment that the operation has just ended its execution. A guard is a constraint that must be true before a state transition fires.
Zavisnost
Obeležena isprekidanom linijom
Najopštija relacija između klasa
Ukazuje da objekat utiče na drugi objekat
27
AccountingSystem kreiraReceipt objekat
AccountingSystem
Reciept
<<creates>>
Order
SecurityControl
<<modifies>>
Zavisnost
Zavisnost je najapstraktniji tip relacija.
Svojstva: Zavisnost je uvek usmerena (ako određena klasa zavisi od
druge, to ne znači da važi i obrnuto). Zavisnost nema kardinalnost.
Ako instance dve klase šalju poruke jedna drugoj, ali nisu međusobno povezane, onda je zavisnost odgovarajuća relacija.
Tipovi: «call» «create»
28
Agregacija
“Celina-deo” relacija između klasa.
Sastavljanje klase iz drugih klasa. Kombinovana sa “many” – spajanje klase od nekoliko instanci te
klase
29
AuthorfileNamePermission
Word Processing Document
Picture
name
Folder
*
*
*
Kompozicija
Kompozicija je jača forma agregacije
Sadržani objekti žive i umiru unutar kontejnera
Kontejner kreira i uništava sadržane objekte
30
close()move()
WindowOperating
System
Slider Header Panel
0..2 1
Kompozicija vs. Agregacija
Agregacija Kompozicija
Objekat-deo može biti deljen između više objekata-celina
Objekat-deo je uvek deo jednog objekta-celine
Objekti-delovi mogu postojati nezavisno (i.e., kardinalnostmože biti 0..*)
Objekti-delovi postoje samo kao deo objekta-celine. Kada je objekat-celina uništen, i objekti-delovi su uništeni.
Objekat-celina nije potpuno odgovoran za objekat-deo
Objekat-celina je odgovoran i kreira ili uništava objekte-delove
0..4category document
*Window Frame
*
Sadržaj
Uvod
Klase, atributi i operacije
Relacije
Generalizacija
Uputstvo za efikasno modelovanje klasa
32
Generalizacija – definicije
Super klasa (Osnovna klasa) Obezbeđuje zajedničke funkcionalnosti i članove
Podklasa (Izvedena klasa) Nasleđuje sve atribute i operacije super klase Može dodati nove operacije i atribute.
Može proširiti ili promeniti ponašanje super klase navođenjem svoje definicije iste metode (polimorfizam).
33
Super Class
…
Uvod | Klase | Relacije | Generalizacija | Uputstva
Subclass
Presenter
Presentation Notes
Note: remove the overriding bullet
Generalizacija – prednosti
Modularnost: Eliminiše detalje Nalazi zajedničke karakteristike između klasa Definiše hijerarhije
Višestruka upotreba: Omogućava specijalizovanje stanja i ponašanja
34
Višestruko nasleđivanje
Polimorfizam
paint()repaint()
x : inty : int
GraphicComponent
press()
caption : String
Button
paint()
picture : File
Image
clickImage()
ImageButton
Uputstva za generalizaciju
Pažljivo posmatrajte slična svojstva između objekata, jer ponekad ona nisu tako očigledna
35
Šta je problem ovde?
id : longname : Stringdesc : StringSalary : FloatworkYears : int
Worker
getCategory() : Category
id : longname : Stringdesc : Stringavailability : int
Product
name : Stringimportance : int
Category
id : longname : Stringdesc : Stringdate : Date
Order
getCategory() : Category
id : longname : Stringdesc : Stringsubject : Subject
Document
updateName(...)updateDesc(...)
User Interface
** |includes
*
*Done by }
*
**
*
Uputstva za generalizaciju
36
ID i name su zajednički za sve klase
Asocijacija je isto kao i svaki drugi atribut
id : longname : Stringdesc : String
Resource
Salary : FloatworkYears : int
Worker
availability : int
Product
getCategory() : Category
CategorizedResource
name : Stringimportance : int
Category
subject : Stringdate : Date
Document
date : Date
Order
updateName(...)updateDesc(...)
User Interface
** includes }
* *Done by }
**
Abstraktne klase
Klasa koja nema direktne instance
37
Content
<<abstract>>
Article Picture
News Article
MagazineArticle
has picture
1*..
1*..
Obeležava se italic imenima
Ili stereotipom “abstract”
Interface
Interfejsi
Interfejs sakriva unutrašnje ponašanje klase i njena obeležja.
To je zapravo skup pravila koja svaka klasa koja ga implementira, mora poštovati.
38
ImplementationOperation 1
Operation 2
Data
Operation 1 Impl’
Operation 2 impl’
External Object
Operation 1Operation 1Operation 1 Declaration
Operation 2 Declaration
Presenter
Presentation Notes
Interface contain only the signature of the object’s elements, while the interface implementation is done by a different object Reduces propagation of side effects when changes occur For instance, what if we want to change the algorithm of operation 2? What if we want to change the data structure from hash table to B-tree? What if we want to provide several implementations to an interface?
Terminologija
Relacija “realizuje”:
39
method1()method2()
«interface»ISomething
Class1
Class2
Notacija interfejsa
40
Realizacija: Objekat garantuje da će izvršiti pravila definisana u interfejsu
create()move()delete()display()
uniqueID : IDwidth : intheight : int
«interface»ICommonObject Client
Application
Equation PowerPoint Document Excel Document
Presenter
Presentation Notes
More examples: Firefox extensions, Facebook applications.
Sadržaj
Uvod
Klase, atributi i operacije
Relacije
Generalizacija
Uputstvo za efikasno modelovanje klasa
41
Kako modelovati?
42
Odozdo-gore proces Odozgo-dole proces
Započinje stavljanjem svih klasa na papir, a zatim se vrši njihovo kombinovanje
Započinje od sistema kao celine, a zatim se vrši njegovo deljenje na klase
Catalogue Customer
Order
Shipping details
Purchase Process
Charging process Product spec
Search engine results
Category
Credit data
Product Configuration
Odozgo-dole metodologija
43
Analiza opsega
Identifikovanje glavnih klasa
Identifikovanje svojstava
Identifikovanje metoda
Prerada i normalizacija klasa
Generalizovanje klasa
Analiza
Orderid, state...
changeState()ship()
Catalogue Credit card validator
Catalogue Order Customer
Orderid
Statestarted, ended
Orderid
Business Order
: Orderid = 18734
: Customername = “cohen”
CRC kartice
CRC kartice: Class, Responsibility, Collaboration
44
45
Normalizacija
Presenter
Presentation Notes
In normalization, we take individuality and hammer it to conform to regular standards.
Normalne forme u UML klasama
Ne-normalizovan model može imati sledeće probleme: Podaci su međusobno povezani Teško je pojedinačno upravljati elementima podataka
Normalizacija: Skup dizajnerskih strategija Obezbeđuje slabo povezan dizajn
Poreklo: relacione baze podataka Ali u dijagramu klase nemamo primarne ključeve
46Ne-normalizovan
model
Presenter
Presentation Notes
Problems: The number of categories is unlimited. This is a problem, as we want to control each category individually. Also, imagine what would happen if we would have a category ID? 3. Class Normalization In the data world there is a common process called data normalization by which you organize data in such a way as to reduce and even eliminate data redundancy, effectively increasing the cohesiveness of data entities. Can the techniques of data normalization be applied to object schemas? Yes, but this isn’t an ideal approach because data normalization only deals data and not behavior. We need to consider both when normalizing our object schema. We need to rethink our approach. Class normalization is a process by which you reorganize the structure of your object schema in such a way as to increase the cohesion of classes while minimizing the coupling between them. Fundamentally class normalization is a technique for improving the quality of your object schemas. The exact same thing can be said of the application of common design pattern, such as those defined by the “Gang of Four (GoF)” in Design Patterns (Gamma et. al. 1995). Design patterns are known solutions to common problems, examples of which include the Strategy pattern for implementing a collection of related algorithms and the Singleton pattern for implementing a class that only has one instance. The application of common design patterns will often result in a highly normalized object schema, although the overzealous application of design patterns can result in you overbuilding your software unnecessarily. As Agile Modeling (AM) suggests, you should follow the practice Apply Patterns Gently and ease into a design pattern over time. Another common approach to improving object schemas is refactoring (Fowler 1999). Refactoring is a disciplined way to restructure code by applying small changes to your code to improve its design. Refactoring enables you to evolve your design slowly over time. Class normalization and refactoring fit together quite well – as you’re normalizing your classes you will effectively be applying many known refactorings to your object schema. A fundamental difference between class normalization and refactoring is that class normalization is typically performed to your models whereas refactorings are applied to your source code.
Prva normalna forma
Klasa je u 1NF kada je određeno ponašanje (kolekcija sličnih atributa) zahtevano od određenog atributa, smešteno u sopstvenu klasu
47
Presenter
Presentation Notes
1. First Object Normal Form (1ONF) A class is in first object normal form (1ONF) when specific behavior required by an attribute that is actually a collection of similar attributes is encapsulated within its own class. An object schema is in 1ONF when all of its classes are in 1ONF. Consider the class Student in Figure 1. You can see that it implements the behavior for adding and dropping students to and from seminars. The attribute seminars is a collection of seminar information, perhaps implemented as an array of arrays, that is used to track what seminars a student is assigned to. The operation addSeminar() enrolls the student into another seminar whereas dropSeminar() removes them from one. The operation printSchedule() produces a list of all the seminars the student is enrolled in so that the student can have a printed schedule. The operations setProfessor() and setCourseName() make the appropriate changes to data within the seminars collection. This design is clearly not very cohesive – this single class is implementing functionality that is appropriate to several concepts. Figure 2 depicts the object schema in 1ONF. Seminar was introduced, having both the data and the functionality required to keep track of when and where a seminar is taught, as well as who teaches it and what course it is. It also implements the functionality needed to add students to the seminar and drop students from the seminar. By encapsulating this behavior in Seminar we have increased the cohesion of our design – Student now does student kinds of things and Seminar does seminar types of things. In the schema of Figure 1 Student did both. It should be clear that 1ONF is simply the object equivalent of data’s first normal form (1NF) – with 1NF you remove repeating groups of data from a data entity and with 1ONF you remove repeating groups of behavior from a class.
Druga normalna forma
Klasa je u 2NF kada je u 1NF i kada je zajedničko ponašanje koje koristi više od jedne instance klase predstavljeno u sopstvenoj klasi
48
Presenter
Presentation Notes
2. Second Object Normal Form (2ONF) A class is in second object normal form (2ONF) when it is in 1ONF and when “shared” behavior that is needed by more than one instance of the class is encapsulated within its own class(es). An object schema is in 2ONF when all of its classes are in 2ONF. Consider Seminar in Figure 2. It implements the behavior of maintaining both information about the course that is being taught in the seminar and about the professor teaching that course. Although this approach would work, it unfortunately doesn’t work very well. When the name of a course changes you’d have to change the course name for every seminar of that course. That’s a lot of work. Figure 3 depicts the object schema in 2ONF. To improve the design of Seminar we have introduced two new classes, Course and Professor which encapsulate the appropriate behavior needed to implement course objects and professor objects. As before, notice how it has been easy to introduce new functionality to our application. Course now has methods to list the seminars that it is being taught in (needed for scheduling purposes) and to create new seminars because popular courses often need to have additional seminars added at the last moment to meet student demand. The Professor class now has the ability to produce a teaching schedule so that the real-world person has the information needed to manage his or her time.
Treća normalna forma
Sva svojstva moraju zavisiti samo od srži klase
49
Presenter
Presentation Notes
3. Third Object Normal Form (3ONF) Although putting the object schema in 2ONF is definitely a step in the right direction we can still improve the design further. A class is in third object normal form (3ONF) when it is in 2ONF and when it encapsulates only one set of cohesive behaviors. An object schema is in 3ONF when all of its classes are in 3ONF. In Figure 3 the Student class encapsulates the behavior for both students and addresses. The first step would be to refactor Student into two classes, Student and Address. This would make our design more cohesive and more flexible because there is a very good chance that students aren’t the only things that have addresses. However, this isn’t enough because the Address class still needs to be normalized. There is behavior that is associated only with zip codes, formatting and validation to be specific. For example, based on the zip code it should be possible to determine whether or not the city and state of an address are valid. This realization leads to the class diagram presented in Figure 4 which implements addresses as four distinct classes: Address, ZipCode, City, and State. The advantage of this approach is twofold – first of all the zip code functionality is implemented in one place, increasing the cohesiveness of our model. Second, by making zip codes, cities, and states their own separate classes we can now easily group addresses based on various criteria for reporting purposes, increasing the flexibility of our application. The main drawback is that to build a single address we have to build it from four distinct objects, increasing the code that we have to write, test, and maintain. We’re still not done, because the Seminar class of Figure 3 implements “date range” behavior – it has a start date and an end date, and it calculates the difference between the two dates. Because this sort of behavior forms a cohesive whole, and because it is more than likely needed in other places, it makes sense to introduce the class DateRange of Figure 4.
Uputstvo za kreiranje klasa
Identifikovanje klasa Vrlo slično identifikovanju repozitorijuma u dijagramima toka
podataka. Identifikujte elemente podataka i modelujte ih. Razmišljajte o klasama koje upravljaju procesima. Ako su
operacije previše komplikovane, možemo ih modelovati odvojeno.
Razmišljajte o učesnicima. Da li su sve njihove potrebe pokrivene postojećim operacijama.
50
Osnovne pretpostavke
Pristup klasama Korisnici mogu izvršiti bilo koju javnu (public) operaciju klase. Public metode treba koristiti samo kada je to potrebno.
51
Pronalaženje objekata
Objekti se mogu naći, pretraživati ili locirati bez ikakve agregatne klase.
52
Ovo je dovoljno da biLoan Service pristupio svim instancama klaseBook
Uputstva – Modelovanje učesnika
Najčešća greška je modelovanje učesnika kao klasa
Treba zapamtiti - Učesnici interaguju sa sistemom direktno i nije ih potrebno
apriori predstavljati. Ponekad, sistem čuva podatke o korisnicima, ali to ne znači da
izvršavaju sve svoje akcije kroz ovu klasu.
53
Zadatak: Napraviti dijagram klasa za dati Use case dijagram
