Object oriented Object oriented Object oriented Object oriented approach and UML approach and UML approach and UML approach and UML Goals The goals of this chapter are to � introduce the object oriented approach to software systems development � introduce UML notation � use cases � sequence diagrams � class diagrams � statecharts diagrams 1
Summary � The object oriented approach has been the more influential, both in research and practice, in software system development in the past 10 years. � UML is the dominant notation based on the object oriented approach. � This chapter presents the OO approach and part of the UML notation. Outline Outline Outline Outline Object Oriented Approach and UML Object Oriented Approach and UML Object Oriented Approach and UML Object Oriented Approach and UML Approaches to modularity Approaches to modularity Approaches to modularity Approaches to modularity Procedural approach Procedural approach Procedural approach Procedural approach OO approach OO approach OO approach OO approach UML UML UML UML Object and Class diagram Object and Class diagram Object and Class diagram Object and Class diagram Use cases Use cases Use cases Use cases Dynamic models Dynamic models Dynamic models Dynamic models Physical models Physical models Physical models Physical models 2
Approaches to modularity Product Principles � P2, Divide and conquer � modularity � (high) cohesion and (low) coupling � information hiding 3
Approaches � Given the P2 principle, how to implement it? � Procedural approach � Object oriented approach Procedural � Procedural approach � module = procedure/function � support for analysis, design: Structured Analysis, Structured Design � support for coding: C, Pascal, Fortran, .. 4
Object oriented � Object oriented approach � module = class � support for analysis, design: UML � support for coding: C++, Java, Smalltalk, C# Procedural approach � module1 = procedure � module2 = data � relation1 = call procedure – w/without parameter passing, forth and back � relation2 = rd/wr data � coupling – call relation: low – rd relation: higher – wr relation: highest 5
Vector - less disciplined int vector[20]; void sort(int [] v, int size) { // sort }; void foo(){ vector[5] = 44;} int main(){ for (i=0; i<20; i++) { vector[i ]=0; }; sort(vector, 20); Rd wr can happen anywhere vector[4] = 33; } Modules and relationships main vector, 20 int vector[20] vector, 20 init() sort() = function = data = call = read/write = declare = parameter passing 6
Modules and relationships global scope int vector[20] main vector, 20 foo() sort() = function = data = call = read/write = declare = parameter passing Vector - more disciplined void init (int [] v, int size) { for (i=0; i<size; i++) { v[i ]=0; }}; void sort(int [] v, int size) { // sort }; int main(){ Rd/wr only in functions int vector[20]; that receive vector init(vector, 20); sort(vector, 20); } 7
Problems � With global declaration, rd/wr relation can happen between data and any other function, without explicit declaration (parameter passing) � if it can happen, it will happen � especially during maintenance/evolution � coupling increases � root problem is no explicit link between (structured) data and procedures working on it � init(), sort() and vector[20] are not linked � they should, as they work in symbiosis – parameter passing should be avoided – while rd/wr relationship should be confined within sort() init() – concept of object 8
OO approach - Class class vector{ private: int v[20]; public: vector(){ // same as init } sort(){ // same as sort } } OO approach - object int main() { vector v1, v2; // v1.sort(); } 9
OO approach � module1 = procedure � module2 = data � module3/4 = object / class � relation1 = message passing – similar to procedure call with parameter passing � relation2 = rd/wr data � coupling – call relation: low – rd relation: higher – wr relation: highest class vector init object v1 int v[20] Is instance of sort – class describes structured data and procedures that can rd/wr them – object v1 is instance of (is described by) class – no rd/wr outside class 10
Modules and relationships main v1 v1 v1 init() sort() NO = function = data = call = read/write = declare = parameter passing More OO main v1 init(), sort() car1 = message pass = declare 11
Results – In oo world objects exchange messages – coupling between objects is lower – message passing vs. procedure call – objects hide r/w relationship – less relationships among objects – objects are higher level of abstraction – more complex systems can be built Message passing vs. procedure call � Message passing � Procedure call � Control mechanism � Control mechanism � same � same � Data exchange � Data exchange � reference to object � object is passed is passed � receiver can rd/wr � receiver can send object messages, cannot rd/wr object 12
Message passing vs. procedure call � Message passing � Procedure call void foo(vector v){ void foo(int vector[]){ v.sort(); // v.[14] = 7; // NO vector[14] = 7; // } } int main(){ int main(){ vector v1; int v1[20]; vector v2; foo(v1); foo(v1); foo(v2); } } Interface � set of messages an object can answer to v1 instance of Vector init() sort() print() 13
P2 revised � objects / classes are better modularization elements � by construction message passing has (much) lower coupling than procedure call and rd/wr � designer has to decide ‘right’ classes to implement information hiding OO and process UML Java, C++, .. 14
UML UML � Unified Modeling Language � standardized by OMG, Object Management Group � Resources � www.cetus-links.org � Fowler, UML Distilled, 3 rd edition, Addison Wesley 15
Modeling dimensions vs. UML diagrams � Structure, entities, concepts � Class diagram � Package diagram, component diagram � Functions (What the system can do) � Use case diagram � Time, dynamics, temporal constraints � Sequence (collaboration) diagram � Statechart diagram � Activity diagram Class / object models 16
Object � Model of entity (physical or inside software system) � ex.: student, exam, stack, window � characterized by � identity � attributes (or data or properties) � operations it can perform (behaviour) � messages it can receive � graphic representation: rectangle student 1 student 2 name = Mario name = Giovanni surname = Rossi surname = Verdi id = 1234 id = 1237 doExam() doExam() followCourse() followCourse() 17
Class � Descriptor of objects with similar properties Student name surname id doExam() followCourse() Class - cont. � attribute – the name of an attribute is the same for all objects and can be described in the class – the value of an attribute may be different on each object and cannot described in the class � operation – is the same for all objects and can be described in the class – will be applied to different object (possibly with different results) 18
Class and object � object is instance of a class Student: student 1 Student name = Mario surname = Rossi name id = 1234 surname id print() print() Student: student 2 name = Giovanni surname = Verdi id = 1237 Class Student print() objetcs (instances) of class Student Class and object: Java class Student{ String name; String surname; long int id; void print(){ System.out.println(“Info of student:” + “ ” + name + surname + id); } } 19
class Exam { int grade; Student s; void print(){ System.out.println(“Grade: ” + grade); } } main(){ Student student1; Student student2; student1 = new Student(“Mario”, “Rossi”, 1234); student2 = new Student(“Giuseppe”, “Verdi”, 1237); student1.print(); student2.print(); } 20
Object diagram � Models objects of interest in a specific case Student: student 3 Exam: exam1 Student: student 1 Exam: exam2 Student: student 2 – Remark: above is a reduced notation for object/class – Remark: links are key part of diagram, see next slides Class diagram � Models classes of interest in a specific case Exam Student – Remark: relationships are key part of this diagram, see next slides 21
Link � Model of association between objects passes-1 Student: student 3 Exam: exam1 Student: student 1 passes-2 Exam: exam2 Student: student 2 Relationship � Descriptor of links with similar properties Course 1, 1 0,* 1, 1 passes 0,* Exam Student 22
Relationships Class Exam Class Student Relationship between classes NO NO Link between objects Multiplicity � Constraint on max / min number of links that can exit from an object 23
Multiplicity n Exactly n * Zero or more m..n between m and n (m,n included) m..* from m up 0..1 Zero or one (optional) Relationships ExamSession Date day * Is planned on the 4 4 4 4 1 month year Print() print Multiplicity addStudent() subscribes to Name Student of relationship Course name subjectname surname lecturer 3..10 attends 4 4 4 4 * id attender attendee print print Roles 24
Properties 25
Bidirectional Associations Notes and Comments 26
Recommend
More recommend