Скачать презентацию Software Engineering Design Modeling Class Diagram and Скачать презентацию Software Engineering Design Modeling Class Diagram and

79636e1c1ff31a1e52096bfc3e8e3b17.ppt

  • Количество слайдов: 115

Software Engineering Design & Modeling Class Diagram and Object Diagram Software Engineering Design & Modeling Class Diagram and Object Diagram

Chapter Outline n Aim: n n To explore how we do basic modelling of Chapter Outline n Aim: n n To explore how we do basic modelling of things and concepts from the real-world Chapter outline: n n Objects Classes n n n attributes, operations and responsibilities Relationships Common Mechanisms Class diagram Object diagram Case Study 2

Introduction n Modelling a system involves identifying the things that are important to your Introduction n Modelling a system involves identifying the things that are important to your particular view. These things form the vocabulary of the system you are modelling. This chapter explores how we do basic modelling of things and concepts from the real-world n n using Class Diagrams Before learning how to model using Class Diagram, we must first understand the basic building blocks of Class Diagram 3

Objects and Classes Objects and Classes

Objects An object is simply a real-world thing or concept n Three essential aspects Objects An object is simply a real-world thing or concept n Three essential aspects of objects are: n n An object has an identity n Can have a name or can be anonymous n An object has state n the names of the various properties that describe the object (attributes) and also the value of those attributes n An object has behaviour n represented by functions (or methods) that use or change the values of the object’s attributes 5

n Example: Suppose you want to take out RM 100 from a Maybank ATM n Example: Suppose you want to take out RM 100 from a Maybank ATM machine. The relevant objects that you could identify from this process are: Object Value Maybank ATM Card PIN 423155 Checking Account ID Limit 404729 -112 RM 1000. 00 RM 50 n Attribute serial. Number 2456110879 -00 An object is an instance of a class 6

Classes n n Classes are the most important building block of any object-oriented system Classes n n Classes are the most important building block of any object-oriented system Classes are used to: n n n capture the vocabulary of the system you are developing represent software things, hardware things, and even things that are purely conceptual Well-structured classes have crisp boundaries and form a part of a balanced distribution of responsibilities across the system 7

Definition n A class is a description of a set of objects that share Definition n A class is a description of a set of objects that share the same attributes, operations, relationships and semantics n n In other words, a class is a collection of objects that have the same characteristics. In UML, a class is presented as a rectangle Class. Name attributes operations 8

n When drawing a class element on a class diagram, you must use the n When drawing a class element on a class diagram, you must use the top compartment, but the bottom two compartments are optional. Account account. Number balance interest. Rate Account deposit(amount: Real) withdraw(amount: Real) get. Balanced() : Real Account account. Number : Integer Balance : Real interest. Rate : Real 9

Name n Every class must have a name to distinguish it from other classes Name n Every class must have a name to distinguish it from other classes can be a simple name, i. e. Student, Door, etc n can be a path name n n the class name prefixed by the name of the package in which that class lives, i. e. Business. Record: : Customer, java: : awt: : Rectangle etc n A class may be drawn showing only its name Customer 10

Attribute n An attribute is a named property of a class that describes a Attribute n An attribute is a named property of a class that describes a range of values that instances of the property may hold n n n represents some property of the thing you are modelling that is shared by all objects of that class At any given moment, an object of a class will have specific values for every one of it’s class attributes A class may have a number of attributes or no attributes at all 11

n n Attributes may be drawn showing only their names (a) Or, we can n n Attributes may be drawn showing only their names (a) Or, we can further specify an attribute by stating its type and possibly a default initial value (b) Customer name address phone birthdate (a) Wall height : Float width : Float thickness : Float is. Load. Bearing : Boolean = false (b) 12

Operation n An operation is the implementation of a service that can be requested Operation n An operation is the implementation of a service that can be requested from any object of the class to affect behaviour n n Often, invoking an operation on an object changes the object’s data or state A class may have a number of operations or no operations at all 13

n n Operations may be drawn showing only their names (a) We can further n n Operations may be drawn showing only their names (a) We can further specify an operation stating its signature (b) n including the name, type and default value of all parameters and (in case of functions) a return type Customer add() remove() edit() (a) Temperature. Sensor reset() set. Alarm(t : Temperature) value() : Temperature (b) 14

n Organizing attributes and operations n When drawing a class, we don’t have to n Organizing attributes and operations n When drawing a class, we don’t have to show every attribute and every operation at once We can choose to show only some or none at all n An empty compartment doesn’t necessarily mean stereotype there are no attributes or operations n n n We can explicitly specify that there are more attributes or properties than shown by ending each list with an ellipse (“. . . ”) To better organize long lists of attributes and operations, we can also prefix each group with a descriptive category by using stereotype Customer <> new() <> add(p: Cust. Record) remove (p : Cust. Record). . . 15

Responsibilities n It is often desirable to define explicit responsibilities for a class n Responsibilities n It is often desirable to define explicit responsibilities for a class n A responsibility is a contract or an obligation that one class has with regard to other classes n Ex: - A Customer class is responsible for adding a new customer’s record into the database, for deleting customer’s record from the database and for updating the customer’s record 16

n Graphically, responsibilities can be drawn in a separate compartment at the bottom of n Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon Customer Responsibilities -- add new customer’s record -- delete unwanted customer’s record -- update customer’s record with new data 17

Visibility There is a notation of visibility for attributes and operations. n UML identifies Visibility There is a notation of visibility for attributes and operations. n UML identifies four types of visibility: n Public n Protected n Private n Package n 18

class Bank. Account{ private: void update. Balance (Dollars new. Balance); public: char* owner; Dollars class Bank. Account{ private: void update. Balance (Dollars new. Balance); public: char* owner; Dollars balance; void deposit (Dollars amount); void withdrawal (Dollars amount); }; 19

A simple example n On-line Bookstore Review n n a web application that can A simple example n On-line Bookstore Review n n a web application that can be accessed by the store’s registered customer, whereby each customer can review one or more books sold in the book store The process: n n n Each registered customer has an account that is used to verify his/her ID and password Each registered customer, upon account verification, can review one or more books based on its title. Problem: Come up with a set of classes that can be found in the above problem 20

n Things that are found in the problem: n The process: n Each registered n Things that are found in the problem: n The process: n Each registered CUSTOMER has an ACCOUNT that is used to verify his/her ID and password n Each registered CUSTOMER, upon ACCOUNT verification, can REVIEW one or more BOOKS based on its title. n Therefore, the things identified are: n Account n Customer n Book n Review 21

n Each of these things can form individual classes with responsibilities n Account n n Each of these things can form individual classes with responsibilities n Account n n n Customer n n Used to keep information about the customer, such as customer’s name, ID, address etc Book n n Used to keep the customer’s ID and password for verifying that the customer is a registered customer Also keeps additional information, i. e. e-mail address Used to keep the relevant information on the book that is crucial to customer’s review, i. e. book title, author, rating Review n n Used to assign ratings to book reviewed (with 1 being the lowest and 5 the highest) Used to compute the average rating for each book that has been reviewed 22

n Translate the responsibilities for each class into attributes and operations needed to perform n Translate the responsibilities for each class into attributes and operations needed to perform those responsibilities (relevant to the given problem) n Account n n n Customer n n Attributes: Cust. Name, Cust. Address, Cust. ID etc Operations: NONE Can choose not to show the attributes when modelling the class as they are not relevant to the given problem Book n n n Attributes: email. Address, ID, password Operations: verify. Password() Attributes: title, author, rating Operations : NONE Review n n Attributes: NONE Operations: assign. Ratings(rating : Int), compute. Avg. Rating() : double 23

n Model the classes: Account email. Address ID password verify. Password() Book title : n Model the classes: Account email. Address ID password verify. Password() Book title : String author: String rating: Float Review Customer assign. Rating(rating : Int) compute. Avg. Rating() : Double 24

Summary n Attributes, operations and responsibilities are the most common features needed to convey Summary n Attributes, operations and responsibilities are the most common features needed to convey the most important semantics of our classes n n We may need to extend our classes by specifying other features : will be covered in later chapters Classes rarely stand alone n n When we build models, we will focus on groups of classes that interact with one another (relationships) In the UML, these group of classes form collaborations and are usually visualized in class diagrams 25

Relationships Relationships

Relationships n When we build abstractions, we will discover that very few classes stand Relationships n When we build abstractions, we will discover that very few classes stand alone n n Therefore, when we model a system, we must n n n most of them collaborate with others in a number of ways identify the things that form the vocabulary of our system (classes) model how these things stand in relation to one another In UML, the ways that things can connect to one another, either logically or physically, are modelled as relationships 27

n In object-oriented modelling, there are three kinds of relationships that are most important n In object-oriented modelling, there are three kinds of relationships that are most important n Dependencies n represents ‘using’ relationship among classes n Generalizations/Inheritance n connects generalized classes to more specialized ones in what is known as subclass/super-class or child/parent relationship (inheritance) n Associations n represents structural relationships among instances/objects n Each of these relationships provides a different way of combining our abstractions (classes) 28

n The UML provides a graphical representation for each of these kinds of relationships n The UML provides a graphical representation for each of these kinds of relationships allows us to visualize relationships n emphasize the most important parts of a relationship: its name, the things it connects, and its properties n 29

Definition A relationship is a connection among things n Graphically, it is rendered as Definition A relationship is a connection among things n Graphically, it is rendered as a path, with different kinds of lines used to distinguish the kinds of relationships n 3 main types: n Dependency One-sided relationship n Generalization/Inheritance n Association Two-sided relationship n 30

Dependency A dependency is a using relationship that states that a change in specification Dependency A dependency is a using relationship that states that a change in specification of one thing (independent thing) may affect another thing that uses it (dependent thing), but not necessarily the reverse n It is rendered as a dashed directed line n dependent independent 31

n Dependencies are used in the context of classes to show that one class n Dependencies are used in the context of classes to show that one class uses another class as an argument in the signature of an operation n if the used class changes, the operation of the other class may be affected The most common kind of dependency relationship is the connection between a class that only uses another class as a parameter to an operation v To model dependency n n Create a dependency pointing from the class with the operation to the class used as a parameter in the operation 32

n Example: - A system that manages the assignment of students and instructors to n Example: - A system that manages the assignment of students and instructors to courses in a university Course. Schedule add(c : Course) remove(c : Course) Course There’s a dependency from Course. Schedule to Course, as Course is used in both the add() and remove() operations of Course. Schedule 33

Generalization/Inheritance n n A generalization is a relationship between a general thing (superclass or Generalization/Inheritance n n A generalization is a relationship between a general thing (superclass or parent) and a more specific kind of that thing (subclass or child) Generalization means that objects of the child may be used anywhere the parent may appear, but not the reverse n n the child is substitutable for the parent It supports polymorphism n An operation of the child that has the same name/ signature as an operation in a parent overrides the operation of the parent 34

n Graphically, a generalization is rendered as a solid directed line with a large n Graphically, a generalization is rendered as a solid directed line with a large open arrowhead, pointing to the parent Parent. Class Child. Class attributes operations 35

n A class may have zero, one or more parent n n n A n A class may have zero, one or more parent n n n A class that has no parent and one or more children is called a root or base class A class that has no children is called a leaf class A class that has exactly one parent is said to use single inheritance A class that has more that one parent is said to use multiple inheritance A given class cannot be its own parent We will often use generalizations among classes and interfaces to show inheritance relationships. n can also create generalizations with packages 36

v To model inheritance relationship n n n Given a set of classes, look v To model inheritance relationship n n n Given a set of classes, look for responsibilities, attributes and operations that are common to two or more classes Elevate those common responsibilities, attributes and operations to a more general class. If necessary, create a new class to which you can assign these elements Specify that the more-specific classes inherit from the more-general class by placing a generalization relationship that is drawn from each specialized class to its moregeneral parent 37

n Example: - The Rectangle, Circle and Polygon classes inherits from the attributes and n Example: - The Rectangle, Circle and Polygon classes inherits from the attributes and operations of the Shape class Shape origin move() resize() display() Rectangle corner : Point Circle radius : Float Polygon points : List display() Square 38

n Abstract Classes and Operations n n A class that provides common behavior across n Abstract Classes and Operations n n A class that provides common behavior across a set of subclasses, but is not itself designed to have instances that work. A class that contains the common features of components of several classes, but cannot it be instantiated by itself. It represents an abstract concept for which there is no actual concrete expression. For instance, "mammal" is an abstract class - there is no such real, concrete thing as a generic mammal. Instead, there are only instances of mammal, such as human being and monkey, which are types of mammals, and share common characteristics, such as having warm blood and body hair in at least part of the lifecycle. 39

n n Abstract operation: an operation that lacks an implementation, i. e, it has n n Abstract operation: an operation that lacks an implementation, i. e, it has a specification but no method. This indicates that the Bank. Account class is an abstract class and the withdrawal method is an abstract operation. In other words, the Bank. Account class provides the abstract operation signature of withdrawal and the two child classes of Checking. Account and Saving. Account each implement their own version of that operation. 40

Association n An association is a structural relationship that specifies that objects of one Association n An association is a structural relationship that specifies that objects of one thing are connected to objects of another n n we can navigate from an object of one class to an object of the other class, and vice versa Types of association: n Unary association n Binary association n n where both ends of an association circle back to the same class Two classes are related, but only one class knows that the relationship exists. connects exactly two classes N-ary association n connects more than two classes 41

n Graphically, an association is shown as a solid line connecting the same or n Graphically, an association is shown as a solid line connecting the same or different classes 42

n n There are two adornments that apply to associations: Role n n n n n There are two adornments that apply to associations: Role n n n When a class participates in an association, it has a specific role that it plays in the relationship A role is just the face that the class at the near end of the association presents to the class at the other end of the association An explicit name can be given to the role a class plays in an association Role 43

n Multiplicity n It is important to state how many objects may be connected n Multiplicity n It is important to state how many objects may be connected across an instance of an association n This “how many” is called multiplicity of an association’s role n It is written as an expression that evaluates to a range of values or an explicit value n Multiplicity can be written as multiplicity of n n n – one or more (1. . *) – exact numbers, i. e 3 exactly one (1) zero or one (0. . 1) many (*) multiplicity Person 1. . * employee * employer Company 44

n Unary Association n Binary Association 45 n Unary Association n Binary Association 45

n Aggregation n is a “whole-part” relationship within which one or more smaller class n Aggregation n is a “whole-part” relationship within which one or more smaller class are “part” of a larger “whole” n represents a “has-a” relationship, whereby an object of the whole class has objects of the part whole Company 1 aggregation part * Department 46

n Composition There are times when the part class’s lifecycle is not independent from n Composition There are times when the part class’s lifecycle is not independent from that of the whole class. n Example n n The relationship of a company to its departments. Both Company and Departments are modeled as classes, and a department cannot exist before a company exists. 47

n Association Classes n n Sometimes in an association between two classes, the association n Association Classes n n Sometimes in an association between two classes, the association itself might have properties In the UML, you’ll model this as an association class, which is a modeling element that has both association and class properties n n n It is used to model an association that has characteristics of its won outside the classes it connects It comes in handy when you have many-to-many relationship that you would like to break into a set of one-to-many relationships Warning: You cannot attach an association class to more than one association 48

n UML represents an association class with a regular class box and a dashed n UML represents an association class with a regular class box and a dashed line that connects the association class to the association between the other two classes. Company * 1. . * employer employee Person association class Job description date. Hired salary 49

n Example: There’s a many-to-many relationship between Author and Book, whereby an Author may n Example: There’s a many-to-many relationship between Author and Book, whereby an Author may have written more than one book and a Book may have more than one Author. The presence of the Book. And. Author association class allows us to pair one Author with one Book: the role attribute allows us to state whether the Author was the primary, or supporting author, or editor or etc * 1. . * Book Author title: String Book. And. Author role: String 50

v To model structural relationship (association): n For each pair of classes, specify an v To model structural relationship (association): n For each pair of classes, specify an association between the two IF: n n n there’s a need to navigate from objects of one to objects of another (data-driven view of associations) objects of one class need to interact with objects of the other class other than as parameters to an operation (behaviour-driven view of associations) For each associations, specify a multiplicity If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, use an aggregation If there’s a many-to-many relationship between two classes, use association class (if possible) 51

Modelling Relationships n When modelling relationships in the UML n n Use dependencies only Modelling Relationships n When modelling relationships in the UML n n Use dependencies only when the relationship is not structural Use generalization only when the relationship is an “is-a-kindof” or inheritance relationship n n n Beware of introducing cyclical generalization relationships Keep generalization relationships generally balanced where the level of inheritance should not be too deep Use associations only when there are structural relationships among objects 52

A simple example n On-line Bookstore Review n n a web application that can A simple example n On-line Bookstore Review n n a web application that can be accessed by the store’s registered customer, whereby each customer can review one or more books sold in the book store The process given: n n Each registered CUSTOMER has an ACCOUNT that is used to verify his/her ID and password Each PASSWORD entered must be more than 8 characters and consists of a combination of text and numbers Each registered CUSTOMER, upon ACCOUNT verification, can REVIEW one or more BOOKs based on its title A REVIEW can either be a customer’s review and editor’s review 53

n Things that are found in the problem: n n n Account Password Customer n Things that are found in the problem: n n n Account Password Customer Book Review n n can be divided into Customer. Review and Editorial. Review Each of these things can form individual classes with responsibilities n Account n n n Used to keep the customer’s ID and password for verifying that the customer is a registered customer Also keeps additional information, i. e. e-mail address The password is of the type PASSWORD 54

n Password n n Customer n n Divided into sub-classes: Customer. Review and Editorial. n Password n n Customer n n Divided into sub-classes: Customer. Review and Editorial. Review Customer. Review n n n Used to keep the relevant information on the book that is crucial to customer’s review, i. e. book title, author, rating Review n n Used to keep information about the customer, such as customer’s name, ID, address etc Book n n Used to check that the password entered is valid (more than 8 characters and consists of combination of text and numbers) Used to assign ratings to book reviewed (with 1 being the lowest and 5 the highest) by customer Used to compute the average rating for each book that has been reviewed by customer Editorial. Review n Used to store editor’s review 55

n Translate the responsibilities for each class into attributes and operations needed to perform n Translate the responsibilities for each class into attributes and operations needed to perform those responsibilities (relevant to the given problem) n Account n n n Password n n n Attributes: passwd(string) Operations: check. Password() Customer n n Attributes: email. Address(string), ID(string), passwd(Password) Operations: verify. Password(p: Password) Attributes: Cust. Name, Cust. Address, Cust. ID etc Operations: NONE Can choose not to show the attributes when modeling the class as they are not relevant to the given problem (put NONE for both) Book n n Attributes: title, author, rating Operations : NONE 56

n Review n n n Customer. Review n n n Attributes: NONE Operations: NONE n Review n n n Customer. Review n n n Attributes: NONE Operations: NONE Attributes: NONE Operations: assign. Ratings(rating : Int), compute. Avg. Rating() : double Editorial. Review n n Attributes: NONE Operations: NONE 57

n The relationship between classes: n Dependency n The operation verify. Password in Account n The relationship between classes: n Dependency n The operation verify. Password in Account class has as parameter a Password class n Therefore, Account depends on Password n Generalization n Review can be divided into customer’s review and editor’s review n Therefore, Customer. Review and Editorial. Review is the subclass of Review 58

n Association n A customer can open 1 account and an account can be n Association n A customer can open 1 account and an account can be opened by 1 customer n A customer writes a review and a review can be written by a customer n 1 customer can write 1 or many reviews, but 1 review can only come form 1 customer n A book can have many reviews but a review is for one book 59

n Modelling the classes and relationships: - Editorial. Review Book title : String for n Modelling the classes and relationships: - Editorial. Review Book title : String for has 1 writes Customer opened 1 1 by 1 opens * Review is written by Customer. Review 1. . * assign. Rating(rating : Int) compute. Avg. Rating() : Double Account email. Address : string ID : string passwd : Password verify. Password(p : Password) Password pass : String check. Password() 60

Summary n Plain, unadorned dependencies, generalizations and associations with names, multiplicities and roles are Summary n Plain, unadorned dependencies, generalizations and associations with names, multiplicities and roles are the most common features needed in creating abstractions (classes) n n n For most of the models that we will build, the basic form of these three relationships will be all that is needed to convey the most important semantics of a relationship Dependencies, generalizations and associations are all static things defined at the level of classes In UML, these relationships are usually in class diagrams 61

Common Mechanisms Common Mechanisms

Common Mechanism n n Before we go into Class Diagrams, let’s first look at Common Mechanism n n Before we go into Class Diagrams, let’s first look at some common mechanisms that can be found/used in UML Class diagrams The UML is made simpler by the presence of 4 common mechanisms that apply throughout the language n n Specifications Adornments ü. Common divisions Extensibility mechanisms ü. 63

Adornments n Notes are the most important kind of adornment that stands alone n Adornments n Notes are the most important kind of adornment that stands alone n A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of elements n n A note that renders a comment has no semantic impact n n Notes are use to attach information to a model Its contents do not alter the meaning of the model to which it is attached A note may contain any combination of text of graphics 64

n Graphically, a note is rendered as a rectangle with a dog-eared corner, together n Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment Publish this component in the project repository after the next design view simple text See http: //www. gamelan. com for an example of this applet embedded URL See encrypt. doc for details about this algorithm link to document 65

Extensibility mechanisms permit us to extend the UML in controlled ways n They include: Extensibility mechanisms permit us to extend the UML in controlled ways n They include: n Stereotypes n Tagged values n Constraints n Interfaces n 66

n Stereotype n Extends the vocabulary of the UML n n by allowing the n Stereotype n Extends the vocabulary of the UML n n by allowing the creation of new kinds of building blocks that are derived from existing ones but are specific to our problem In its simplest form, it is rendered as a name closed by guillemots, <>, and placed above the name of another element Icons can also be used with stereotype <> <> <> <> <> <> <> <> <> Model. Element Underflow named stereotype with icon 67

n Tagged value n Extends the properties of a UML building block n n n Tagged value n Extends the properties of a UML building block n n n by allowing the creation of new information in that element’s specification A tagged value is not the same as an attribute; it can be thought as a metadata because its value applies to the element itself and not its instances In its simplest form, a tagged value is rendered as a string enclosed by brackets and placed below the name of another element n The string includes a name (the tag), a separator ( = ) and a value (of the tag) Event. Queue {version = 3. 2 author = egb} tagged value add() 68

n Constraint n Extends the semantics of the UML building block n n n n Constraint n Extends the semantics of the UML building block n n n by allowing the addition of new rules or the modification of existing ones It specifies the condition that must be held true for the model to be well-formed In its simplest form, it is rendered as a string enclosed by brackets and placed near the associated element Event. Queue {version = 3. 2 author = egb} add() remove() flush() tagged value {ordered} constraints 69

simple constraint Portfolio Corporation {secure} Bank. Account {or} constraint across multiple elements Person gender simple constraint Portfolio Corporation {secure} Bank. Account {or} constraint across multiple elements Person gender : {female, male} 0. . 1 wife 0. . 1 husband { self. wife. gender = female and self. husband. gender = male } formal constraint using OCL 70

n Interfaces n n n Interfaces is a kind of classifier that represents a n Interfaces n n n Interfaces is a kind of classifier that represents a declaration of a set of coherent public features and obligations. It is a specialized type of class that cannot be instantiated Since interfaces are declarations, they are not instantiable. A class and an interface differ: a class can have an actual instance of its type, whereas an interface must have at least one class to implement. An interface is a set of operation signatures. In C++, interfaces are implemented as abstract classes with only pure virtual members. in Java, they're implemented directly. 71

n Required and Provided Interfaces The nature of the relationship between the interface and n Required and Provided Interfaces The nature of the relationship between the interface and other classes was indicated by the type of dependency used to connect the class and interface. n If the dependency from class to interface had a <> stereotype, then the class provides the interface. n If the dependency is not otherwise stereotyped, then the class requires the interface to be present. n 72

Notations Provided interface Required interface 73 Notations Provided interface Required interface 73

Summary n When you adorn a model with notes Use notes only for those Summary n When you adorn a model with notes Use notes only for those requirements, observations, reviews and explanations that you can’t express simply or meaningfully using existing features of the UML n Use notes as a kind of electronic sticky note, to keep track of your work in progress n 74

n When you use a model with stereotypes, tagged values or constraints n Standardize n When you use a model with stereotypes, tagged values or constraints n Standardize on a small set of stereotypes, tagged values and constraints to use on your project n avoid individual developers to create lots of new extensions Choose short, meaningful names for your stereotypes and tagged values n Where precision can be relaxed, use free-form text for specifying constraints n 75

Class Diagrams Class Diagrams

Class Diagrams n n The most common diagram found in modelling object-oriented system Shows Class Diagrams n n The most common diagram found in modelling object-oriented system Shows a set of classes, interfaces, and collaborations, and their relationships Class diagrams are the foundation for a couple of related diagram: component diagram and deployment diagram They are important for : n n visualizing, specifying, and documenting structural models Constructing executable systems through forward and reverse engineering 77

Definition n n A class diagram is a diagram that shows a set of Definition n n A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships It commonly contains: n n n Classes Interfaces Collaborations Dependency, generalization, and association relationships Class diagram may also contain: n n Notes and constraints (common mechanisms) Packages or subsystems (used to group elements of the model into larger chunks) 78

Common Uses n Class diagrams are used to model the static design view of Common Uses n Class diagrams are used to model the static design view of a system n n supports the functional requirements of the system When we model the static design view of a system, we will use class diagrams in 3 ways: n To model the vocabulary of the system n n n involves making a decision about which abstractions are a part of the system under consideration and which falls outside its boundaries Class diagrams are used to specify these abstractions and their responsibilities Have been discussed previously 79

n To model simple collaborations n A collaboration is a society of classes, interfaces, n To model simple collaborations n A collaboration is a society of classes, interfaces, and other elements that work together to provide some cooperative behaviour that is bigger than the sum of all the elements n Class diagrams are used to visualize and specify this set of classes and their relationships n To model logical database schema n Class diagrams can also be used to model schemas for databases used to store persistent information 80

Summary n When we create class diagrams in UML, remember that every class diagram Summary n When we create class diagrams in UML, remember that every class diagram is just a graphical representation of the static design view of a system n n n No single class diagram need to capture everything about a system’s design view Collectively, all the class diagrams of a system represent the system’s complete static design view Individually, each represents just one aspect 81

n A well-structured class diagram is focused on communicating one aspect of a system’s n A well-structured class diagram is focused on communicating one aspect of a system’s static design view n contains all the elements that are essential to understanding that aspect n provides detail consistent with its level of abstraction, with only those adornments that are essential to understanding n is not so minimalist that it misinforms the reader about important semantics n 82

Example Littlesand, Pebblesea and Mudport are three charming resorts on the South Coast which Example Littlesand, Pebblesea and Mudport are three charming resorts on the South Coast which are very popular with tourists, since they score well on beach rating and hours of sunshine for the area. All three resorts have a large number of places to stay, ranging from one-room guest house to the exclusive Palace Hotel at Pebblesea. The local tourist board wants to set up a central system to deal with room bookings in the area. Draw a class diagram to represent this information. Where appropriate, your diagram should include association, aggregation, inheritance and multiplicity. List sample attributes and operations ONLY for the class Resort. 83

n Steps in drawing the Class Diagram: n Find the abstractions/classes Littlesand, Pebblesea and n Steps in drawing the Class Diagram: n Find the abstractions/classes Littlesand, Pebblesea and Mudport are three charming resorts on the South Coast which are very popular with tourists, since they score well on beach rating and hours of sunshine for the area. All three resorts have a large number of places to stay, ranging from one-room guest house to the exclusive Palace Hotel at Pebblesea. The local tourist board wants to set up a central system to deal with room bookings in the area. The classes are: RESORT, PLACE TO STAY, HOTEL, GUEST HOUSE, ROOM, BOOKING & TOURIST 84

n Can ignore each classes responsibilities as the question only wants the attributes and n Can ignore each classes responsibilities as the question only wants the attributes and operations for the Resort class. (follow the PROBLEM DOMAIN) n Resort Class n n Used to store information on the resort such as name, description, beach rating, hours of sunshine etc Used to perform operations such as updating the beach rating and updating the hour of sunshine etc Attributes: name (string) description (string) beach rating (double) hour of sunshine (double) Operations: update beach rating (r : double) update hours of sunshine (h : double) 85

n Find the relationships between the classes: n “All three Resorts have a large n Find the relationships between the classes: n “All three Resorts have a large number of places to stay” n Places to stay is ‘a part of’ Resorts, with Resort being the ‘whole’ : AGGREGATION n A resort can have 1 or many places to stay n “All three resorts have a large number of places to stay, ranging from one-room guest house to the exclusive Palace Hotel at Pebblesea” n Places to stay consists of guest houses and hotels, with Places to stay being the parent and the other two, the child : GENERALIZATION 86

n “The local tourist board wants to set up a central system to deal n “The local tourist board wants to set up a central system to deal with room bookings in the area” ASSOCIATION: n A place to stay has one of many rooms n A room can be have many bookings or none n A booking is for one or more rooms n A booking can be done by one or many tourists n A tourist can book one or many rooms 87

n The class diagram : Resort 1. . * Place_to_Stay 1 1. . * n The class diagram : Resort 1. . * Place_to_Stay 1 1. . * Room 1. . * 0. . * Booking 1. . * Hotel Guest_House 1. . * Tourist 88

n The attributes and operations for the Resort class Resort name : String description n The attributes and operations for the Resort class Resort name : String description : String beach_rating : Double hours_of_sunshine: Double update_beach_rating (r : Double) update_hours_of_sunshine (h : Double) 89

n Note: Using forward engineering, the Resort class can now be mapped into a n Note: Using forward engineering, the Resort class can now be mapped into a C++ code. class Resort { private: char name[20], descrp[100]; double rating, sun_hours; public: void update. Beach. Rating(double r) { rating = r; } void update. Hours. Sunshine(double h) {sun_hours = h; } }; 90

Object diagrams Object diagrams

Object Diagrams Object diagrams model the instances of things contained in class diagrams n Object Diagrams Object diagrams model the instances of things contained in class diagrams n An object diagram shows a set of objects and their relationships at a point in time n You use object diagrams to model the static design view or static process view of a system. n n involves modelling a snapshot of the system at a moment in time and rendering a set of objects, their state, and their relationships 92

n The UML notation for an object takes the same form as that for n The UML notation for an object takes the same form as that for a class, except for 3 differences: n Within the top compartment of the class box, the name of the class to which the object belongs to appears after a colon : n n n The object may have a name that appears before the colon, or it may be anonymous (no name before the colon) The contents of the top compartment are underlined for an object. Each attribute defined for the given class has a specific value for each object that belong to that class. Object : Class attribute 1 = value attribute 2 = value named object : Class attribute 1 = value attribute 2 = value anonymous object 93

n Object diagrams commonly contain n n objects links may contain notes and constraints n Object diagrams commonly contain n n objects links may contain notes and constraints may also contain packages or subsystems, both of which are used to group elements of your model into larger chunks You use object diagrams to model the static design view or static process view of a system just as you do with class diagrams, but from the perspective of real or prototypical instances n Supports the functional requirements of a system 94

Example: From the class diagram given below, you can get several instances of it. Example: From the class diagram given below, you can get several instances of it. Book Author name : String wrote title : String rating: Double published by Publisher name : String 95

: Author name : “Margeret Mitchell” wrote : Book title : “Gone With the : Author name : “Margeret Mitchell” wrote : Book title : “Gone With the Wind” rating: 4. 5 published by AW: Publisher name : “Hawthorne” Object diagram 96

: Author name : “Tim Burton” wrote : Book title : “Burton on Burton” : Author name : “Tim Burton” wrote : Book title : “Burton on Burton” rating: 4 published by AW: Publisher name : “Barnes” Object diagram 97

Case Study: On-Line Bookstore (cont…) Case Study: On-Line Bookstore (cont…)

n n On-line Bookstore is a web application that can be accessed by the n n On-line Bookstore is a web application that can be accessed by the store’s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account. Problem: Draw the class diagram for the above system 99

n Identify the abstractions/classes On-line Bookstore is a web application that can be accessed n Identify the abstractions/classes On-line Bookstore is a web application that can be accessed by the store’s registered CUSTOMER, whereby each customer can order BOOKs, REVIEW one or more books sold in the book store, and sell USED BOOKs to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their ACCOUNT. 100

n Identify the responsibility for each classes. From the responsibilities, determine their attributes and/or n Identify the responsibility for each classes. From the responsibilities, determine their attributes and/or operations. n CUSTOMER n n n ACCOUNT n n n Keep information on books Attributes: book. Id, title, publisher, rating, ISBN, price, etc USED BOOK n n Keep the user. Id and password for each customer Attributes: user. Id and password Operations: check. Password() BOOK n n Keep information on customer Attributes: user. Id, name, address, e-mail, account. No, etc Keep information specific to used books Inherits from BOOK Attributes: user. Id (of the seller), quality, etc REVIEW n n n Keeps information on the reviewing process Attributes: user. Id, book. Id, review Operations: calculate. Average. Rating() 101

n From the classes that were found, determine their relationships. n Generalisation n n n From the classes that were found, determine their relationships. n Generalisation n n A USED BOOK inherits all the attributes from a BOOK Association n One-to-many relationships n n n A CUSTOMER can have many ACCOUNT, but an ACCOUNT can only be owned one CUSTOMER A CUSTOMER can sell many USED BOOKs, but a USED BOOK can only be sold by one CUSTOMER. A CUSTOMER can have many REVIEWs, but a REVIEW is made by only one CUSTOMER A BOOK can have many REVIEWS, but a REVIEW is only for one BOOK Many-to-many relationships: n A CUSTOMER can order many BOOKS, and a BOOK can be ordered by many customers 102

n We can break the many-to-many relationships using association class A CUSTOMER can order n We can break the many-to-many relationships using association class A CUSTOMER can order many BOOKS, and a BOOK can be ordered by many customers n ORDER (can also call it Shopping Cart) n n n Keeps information on the order made by a customer Attributes: order. Id, user. Id, book. Id, quantity, status Relationship: n n A CUSTOMER can make many ORDERs but an ORDER is made by only one CUSTOMER An ORDER can contain many BOOKs 103

n Before we draw the class diagram, review the use cases (from chapter 1), n Before we draw the class diagram, review the use cases (from chapter 1), and make sure that each class identified has a ‘home’ n n n Use Case REGISTER LOG-IN ORDER BOOKS CHECK OUT REVIEW BOOKS SELL USED BOOKS Class Account class, Customer class Account class Book class, Customer class Order class Review class, Customer class Used book, Customer 104

Book book. Id: String title: String … ordered 1. . * Review book. Id: Book book. Id: String title: String … ordered 1. . * Review book. Id: String review: String … calc. Avg. Rating() 1. . * make Customer user. Id: String name: String e-mail: String … Used. Book user. Id: String quality: String … sell 1. . * Account for has user. Id: String password: String 1. . * 1 check. Password() has 1. . * order Order order. Id: String book. Id: String user. Id: String quantity: Integer status: String 1 for sold 1 1 made by 105

n For this Case Study, the class diagram drawn will be used to model n For this Case Study, the class diagram drawn will be used to model the database schema, n whereby each classes in the class diagram will be mapped into tables during the implementation phase of the software development life-cycle 106

Exercise A car consists of different structural components such as the engine, body, suspension, Exercise A car consists of different structural components such as the engine, body, suspension, and gearbox. Draw a conceptual class diagram from above statement. 107

Conceptual/Structural Model of The Class Diagram 108 Conceptual/Structural Model of The Class Diagram 108

Exercise 1 A Sales Order System As a system designer, you are required to Exercise 1 A Sales Order System As a system designer, you are required to produce a design of Sales Order System to your Project Manager. The system allows a customer to make an order where the system will automatically generate an order id, date of order and date of delivery for customer used. There are three methods of payment; cash, credit card or check. These three methods have the same attribute (amount), but they have their own individual behaviors and attributes. 109

Conceptual/Structural Model of The Class Diagram 110 Conceptual/Structural Model of The Class Diagram 110

Exercise 2 Here is another excerpt from an interview transcript with one of the Exercise 2 Here is another excerpt from an interview transcript with one of the directors who are setting up Car. Match. Remember, Mick Perez(MP) is the systems analyst and Janet Hoffner (JH) is the director. Identify any classes and associations mentioned in the transcript. MP: Can we look at the way car sharing is actually organised now. I’d like to find out a bit more about the ideas you work with. JH: Sure. I guess at the heart of everything there is the car sharer. That’s a person who has registered with us so that they can share journeys with other registered car sharers. MP: Tell me more about how you keep details of the journey that someone wants to share. JH: Well, a car sharer can actually register several journeys with us. They do not have to limit themselves to just one journey to share. MP: I guess they would have to want to share at least one journey to be classed as a car sharer though? JH: That’s right. Remember that they can register as many journeys as they want. When we find other car sharers that want to share a similar journey we match up the sharers and formalise things with a sharing agreement. MP: …. 111

Exercise 3 Consider another extract from the transcript of the interview between Mick Perez Exercise 3 Consider another extract from the transcript of the interview between Mick Perez and Janet Hoffner. From this extract, identify any attributes and operations that can be added to the class model. MP: What kind of information do you hold about the journeys that car sharers will register with you? JH: Well, I’m sure that you realize it will primarily be ‘where from’ and ‘where to’. We need to know where each journey will start from and where it will end. We will also want to know travel times for each direction of the journey. That is to say, the desired departure and arrival times for both the outward and return journeys. MP: What kind of things do you need to know about the start and destination of each journey? Will that information need to be used to match up possible shared journeys? JH: Good point. Yes, I guess that however we hold the start and destination address, we’ll need to be able to use that information to automate the matching of car sharers. The home address of a person might also be used in some journey matching. MP: …………. 112

113 113

Exercise 4 In order to improve the operational efficiency of a point-of-sale product, the Exercise 4 In order to improve the operational efficiency of a point-of-sale product, the chief executive officer is interested in computerizing the company’s business process. The followings are the business requirements: 1. The system will allow the administrator to run inventory reports by loading inventory data from disk. 2. The administrator can update the inventory by loading and saving the inventory data to and from a disk. 3. A sales clerk records walk-in sales. 4. A telephone operator is a special type of sales clerk who handles phone orders. 5. Any kind of sale must update the inventory. 6. A sale may need to verify a credit card if the purchase is a credit card purchase. 7. A sale may need to verify a check if the purchase is a check purchase. Draw a use case diagram and document the diagram based on the requirements given. 114

The Use Case Diagram 115 The Use Case Diagram 115