Презентация на тему: " Object-Oriented Programme 1 SSD3: Object-Oriented Programming and Design." — Транскрипт:
Object-Oriented Programme 1 SSD3: Object-Oriented Programming and Design
Object-Oriented Programme Review of Java Basics 1.2 Java Application 1.3 Designing Classes 1.3 Unit 1. Class Design
Object-Oriented Programme Designing Classes Contents UML Class Diagrams Relationships Between Classes Common Class Structures UML with Eclipse Modeling Classes Modeling the Library System Assessments Practical Quiz 3 Practical Quiz 4 Multiple-Choice Quiz 2 Exercise 2
Object-Oriented Programme UML Class Diagrams 1.3 Introduction Class Notation
Object-Oriented Programme 5 Introduction The Unified Modeling Language (UML, ) is a graphical language for modeling the static and dynamical aspects of a system. unifies the best engineering practices for modeling systems defines different graphical diagrams that provide multiple perspectives of a system under development UML is a unification of the methodologies developed by Grady Booch, James Rumbaugh, and Ivar Jacobsen. The Object Management Group (OMG), a not-for-profit organization that Promotes the use of object-oriented technology, has responsibility for the further development of the UML standard.
Object-Oriented Programme 10 UML UML Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams State Diagrams State Diagrams Scenario Diagrams Scenario Diagrams Use Case Diagrams Use Case Diagrams State Diagrams State Diagrams UML
Object-Oriented Programme 19 Class Notation Class Notation A class represented by a rectangle with three compartments. The first compartment contains the name of the class ; the second compartment describes the attributes of the class; third compartment describes the methods of the class.
Object-Oriented Programme 20 Sample class Employee Representation Abbreviated representation Shortest form Essential representation
Object-Oriented Programme Relationships Between Classes 1.3 Associations One-way and Two-way Associations Multiplicity Aggregation Specialization/Generalization /
Object-Oriented Programme 22 Associations Associations An association represents the relationship between two or more classes. A binary association is a relationship between two classes. An object of a class requires an object of another class to do its work. In UML, a binary association is represented by a solid line that connects the two classes. In a classroom, a professor instructs students. In a bank system, clients hold bank accounts.
Object-Oriented Programme 23 One-Way and Two-Way Associations An association can be a one-way or two-way relationship. A one-way association indicates the direction in which one can navigate from an object of one class to an object of another class. A two-way association indicates bi-directional navigation between objects of two classes. difference one-way association : the first class has a reference( ) to an object of the second class, but the second class does not have a reference to an object of the first class. two-way association : each class contains a reference to an object of the other class.
Object-Oriented Programme 24 UML samples UML indicates a one-way association with an arrow at the end of the association line. The attribute in the first class that contains a reference to an object of the second class is also written at the end of the line. One-way association between classes Car and Engine indicates that an engine is part of a car
Object-Oriented Programme 25 samples the relationship between the classes Country, Government, and Capital the class Country has a reference to an object of class Government the class Country a reference to an object of class Capital
Object-Oriented Programme 26 A class can contain more than one association with another class Two associations between classes Flight and Pilot, one association with the attribute pilot and another with the attribute coPilot.
Object-Oriented Programme 27 Multiplicity Multiplicity Multiplicity indicates the number of instances of a class that may be associated with a single instance of another class. one car has four tires and one engine one client holds one or more bank accounts. The multiplicity can be specified with a single integer a range n..m, where n is the lower limit and m is the upper limit. * used to denote no upper limit. The following are the most common multiplicities: 0..1 Zero or one instance 0..* or * Zero or more instances 1 Exactly one instance 1..* One or more instances
Object-Oriented Programme 28 One-to-one Association In a one-to-one association, exactly one instance of each class is related with exactly one instance of the other class.
Object-Oriented Programme 29 One-to-many Association In a one-to-many association between classes A and B, one instance of class A may be related with many instances of class B, but one instance of class B is related with exactly one instance of class A.
Object-Oriented Programme 30 Many-to-many Association In a many-to-many association between classes A and B, one instance of class A may be related with many instances of class B one instance of class B may be related with many instances of class A.
Object-Oriented Programme 31 Aggregation Aggregation Aggregation Each instance of class A is composed by instances of class B. An instance of class B is part of an instance of class A. The instance of class A is called the aggregate( ) The instance of class B is called the component( ).
Object-Oriented Programme 32 Aggregation in UML
Object-Oriented Programme 33 Specialization/Generalization / ( / ) Specialization/Generalization represents the is-a relationship. …… a whale is-a mammal a client is-a person. If specialization/generalization allows class A to be defined as specialization of another class B. Class A is called the specialization class Whale, client class B the generalization class. Mammal, person
Object-Oriented Programme 34 Specialization/Generalization Specialization/generalization represented in UML by adding a triangle next to the generalization class:
Object-Oriented Programme 35 specialization/generalization relationship If there is a specialization/generalization relationship between classes A and B,so if A is-a B, then all instances of class A are also instances of class B. java / / An important consequence of this relationship is class A inherits all the features of class B. All the attributes and methods of class B are also attributes and methods of class A.
Object-Oriented Programme 36 specialization/generalization relationship The following class diagram represents the relationships Client is-a Person and Employee is-a Person:
Object-Oriented Programme 37 Sample note They are specialization/generalization relationships the attributes of class Person are also attributes of classes Client and Employee. Each instance of class Client contains the attributes name, age, address, accounts (new attributes ); Each instance of class Employee contains the attributes name, age, address, salary (new attributes ), departments (new attributes )
Object-Oriented Programme 38 Example of a system of multimedia files includes images, audio, and text files. The classes are defined as follows:
Object-Oriented Programme Common Class Structures 1.3 Introduction Collections Self-Containing Classes Relationship Loops
Object-Oriented Programme 40 Introduction Although the definition of classes and their relationships depends on the particular application, some class structures are common to many designs. These class structures, which can be thought of as basic building blocks, can be composed to design complex systems.
Object-Oriented Programme 41 Collections Collections A collection models a one-to-many relationship. Collections store many instances of one class. -
Object-Oriented Programme 42 sample The diagram uses a collection to represent the relationship "one client holds one or more bank accounts" defines methods to handle the collection of BankAccount instances. Each BankAccount instance in the collection has an index indicating its location in the collection.
Object-Oriented Programme 43 Self-Containing Classes Self-Containing Classes A class can have an association with itself. the class contains attributes with references to objects of the same class.
Object-Oriented Programme 44 example Class Person in a genealogical tree ( )system. The relationships "each person has one mother" and "each person has one father" are indicated with the attributes mother and father. The attributes mother and father are references to objects of class Person.
Object-Oriented Programme 45 Another example The relationship "each employee has one boss." The diagram indicates that the boss of an employee is another employee.
Object-Oriented Programme 46 Relationship Loops Relationship Loops Self-containment can be found in relationships that include two or more classes.
Object-Oriented Programme 47 example A file system. A file system has folders, and folders contain files or more folders, or both. We can define a class Folder, which contains a collection of FolderItem objects:
Object-Oriented Programme UML with Eclipse 1.3 Introduction Create Project Create Folder Create New Class Diagram Create Class BankAccount Create Class Person Create Class Client Create Specialization/Generalization Relationship Create Association Relationship Export Image Note: We can also use JUDE Download from :
Object-Oriented Programme Modeling Classes 1.3 Process of Modeling Classes Identifying Classes Identifying Relationships Identifying Attributes Identifying Methods Modeling Using UML
Object-Oriented Programme 50 Process of Modeling Classes Object-oriented design is the process of building an object model for a system to be developed. OOD An object model specifies the classes attributes Methods relationships with other classes. How to building an object model from a system specification( ) ?
Object-Oriented Programme 51 The steps to create an object model 1. Identify classes of objects from the system specification. 2. Identify relationships between classes. 3. Identify attributes of each class. 4. Identify methods of each class. 5. Model system using UML. UML
Object-Oriented Programme 52 Identifying Classes Identifying Classes identify classes is to analyze the textual description in the system specification. In textual analysis, the nouns and the noun phrases often indicate objects and their classes. / Singular nouns ( book, library catalog, and client ) and plural nouns ( users, books, and accounts ) indicate classes. Proper nouns ( the ACME Bank ) nouns of direct reference ( the person that owned the account ) indicate objects.
Object-Oriented Programme 53 The steps for identifying the classes List all nouns in the specification. 2. Prune the list: ( ) Convert plural nouns to their singular form. In an object model, class names are singular. Eliminate nouns that represent objects. Replace them with generic nouns. use client instead of John Smith. java Eliminate nouns that are class attributes. If cannot identify the attributes of the noun, it is possible a class attribute. 3. Group the synonyms and then choose the best name for the class from the group. "user" and "client" are synonyms. In a bank system, the best name is "client" because the system may have two types of users: the clients and the bank's employees.
Object-Oriented Programme 54 The steps for identifying the classes Select the classes that are relevant to the system. Look for more relevant classes. Search the application domain for: Physical things. person, book, and computer. Roles played by persons or organizations.employer and supplier. Objects that represents an occurrence or event. system crash, flight, and mouse click. Objects that represent a relationship between other objects in the model. purchase (related to buyer, seller, and merchandise) and marriage (related to man and woman). People who carry out some function. "student" and "clerk." Places. library, classroom, and bank. Collections of objects, people, resources, or facilities. catalog and group. Concepts or ideas that are intangible. money and bank account.
Object-Oriented Programme 55 The steps for Identifying Relationships Create an n x n table where n is the number of classes. Label the rows and columns with the class names.
Object-Oriented Programme 56 The steps for Identifying Relationships identify the specialization/generalization relationships for each cell in the row A and column B, ask the following questions: Is an instance of class A an instance of class B? Is an instance of class B an instance of class A? Analyze the answer, If the answer both yes the class names might be synonyms. the first is yes class A is a specialization of class B. ( ) Mark the cell in the row A and column B with an S. the second is yes, then class A is a generalization of class B. ( ) Mark the cell in the row A and column B with a G.
Object-Oriented Programme 57 The steps for Identifying Relationships Identify the association relationships, evaluate each cell in the row A and column B: If no association between class A and class B mark the cell with an X. If one or more associations between class A and class B, insert the association attributes. study," buy," "ownedAccounts," and "clients."
Object-Oriented Programme 58 The table told us ….. Shows the relationships "a client is a person that has one or more accounts." Indicates that Class Client is a specialization of class Person Class Client has an association relationship with class Account.
Object-Oriented Programme 59 Identifying Attributes Identifying Attributes Look for adjectives and possessive phrases "the X of Y" and "Y's X" in the system specification. "number of the account" and "client's name. Use knowledge of the application domain to define the set of attributes needed for the system being developed.
Object-Oriented Programme 60 Identifying Methods Identifying Methods To identify behaviors, look for verbs. "the client deposits money into the account indicates that class Account should define a method deposit. Use knowledge of the application domain to define the set of methods needed for the system being developed.
Object-Oriented Programme 61 Identifying Methods ( ) Create and initialize new instances. Set and get values of attributes. Load to and save from persistent storage. Destroy instances. Perform calculations using an objects values. Output or display a result. If there are any collections held by the object, include the methods needed to add, remove, and access elements of these collections.
Object-Oriented Programme 62 Modeling Using UML Use class notation to represent classes Include attributes and methods. Use link notation to describe association and specialization/generalization relationships between classes. For associations, specify the multiplicity and the name of the attribute associated with the relationship.
Object-Oriented Programme Modeling the Library System 1.3 Specification of the Library System Identifying Classes Identifying Relationships Identifying Attributes Identifying Methods Modeling Using UML
Object-Oriented Programme 64 Specification of the Library System Specification of the Library System The library system tracks the items checked out by borrowers. The system contains a catalog of the items owned by the library. There are two kinds of catalog items: books and recordings. All catalog items are identified by a unique code. (If the library owns several copies of the same book or recording, each copy has a unique code.) The information for each item includes title, year, and availability. An item is available if it is not checked out.
Object-Oriented Programme 65 Specification of the Library System In addition: The information for a book includes the author and number of pages. The information for a recording includes the performer and format (CD or tape). The system contains a database of the borrowers. Each borrower has a unique identification code in addition to a name. The system maintains a list, for each borrower, of the catalog items checked out.
Object-Oriented Programme 66 Specification of the Library System In the library system, the user should be able to: Display the catalog by listing the code, title, and availability of each item. Display a catalog item. Display the borrowers by listing the identification code and name of each borrower. Display the catalog items checked out by a borrower. Check out a catalog item by adding the item to borrower's list of borrowed items. Check in a catalog item by removing the item from borrower's list of borrowed items.
Object-Oriented Programme 67 Identifying Classes First, we list the nouns in the system specification: library systembookCD itemsrecordingtape borrowerscopydatabase systeminformationborrower catalogitemidentification code librarytitlename kindsyearlist catalog itemsavailabilityuser booksauthor(borrower) code audio itemsnumber of pageslist of borrowed items (item) codeperformer copiesformat
Object-Oriented Programme 68 Identifying Classes Then, we prune the list by eliminating the following nouns: (item) code, title, year, availability These nouns are attributes of a catalog item. author, number of pages These nouns are attributes of a book. performer, format These nouns are attributes of an audio item. CD, tape These nouns are values for the attribute format. name, identification code, (borrower) code These nouns are attributes of a borrower. user This noun is an element outside the library system. information This noun is a generic term for the class attributes. kinds This noun is not relevant to the system.
Object-Oriented Programme 69 Identifying Classes Next, we group the synonyms and then choose the best name for the class from each group: CatalogItem items, catalog items, copies, copy, item LibrarySystem library system, system, library Borrower borrowers, borrower Book books, book Recording recordings, recording BorrowedItems list, list of borrowed items
Object-Oriented Programme 70 Finally, we have …… classes that are relevant to the system LibrarySystem Catalog CatalogItem Book Recording Borrower BorrowedItems BorrowerDatabase
Object-Oriented Programme 71 Identifying Relationships table identifies the association and specialization/generalization relationships:
Object-Oriented Programme 72 Identifying Attributes The following is the list of attributes for each class: ClassAttributes LibrarySystemcatalog, borrowerDB Catalogitems CatalogItemcode, title, year, available Bookauthor, numberOfPages Recordingperformer, format Borrowername, id, borrowedItems BorrowedItemsitems BorrowerDatabaseborrowers
Object-Oriented Programme 73 Identifying Methods The following is the list of methods for each class: ClassMethods LibrarySystemdisplayCatalog()displayCatalogItem(), displayBorrowerDatabase(), displayBorrower(),checkIn(),checkOut() CatalogaddItem(item:CatalogItem) getItem(index:int):CatalogItem getNumberOfItems():Int getItem(code:String):CatalogItem CatalogItemgetCode():String getTitle():String getYear():int isAvailable():boolean setAvailable(value:boolean)
Object-Oriented Programme 74 Identifying Methods The following is the list of methods for each class: ClassMethods BookgetAuthor():String getNumberOfPages():int RecordinggetPerformer():String getFormat():String BorrowergetId():String getName():String getBorrowedItems():BorrowedItems
Object-Oriented Programme 75 Identifying Methods The following is the list of methods for each class: ClassMethods BorrowedItemsaddItem(item:CatalogItem) removeItem(item:CatalogItem) getItem(index:int):CatalogItem getItem(code:String):CatalogItem getNumberOfItems():int BorrowerDatabaseaddBorrower(borrower:Borrower) getBorrower(index:int):Borrower getNumberOfBorrowers():int getBorrower(id:String):Borrower
Object-Oriented Programme 76 Modeling Using UML The following is a class diagram for the library system: