Trước khi phát triển một hệ thống phần mềm, nhà phát triển cần phải hiểu cấu trúc vật lý của nó. Các cấu trúc vật lý của một hệ thống phần mềm bao gồm các lớp học, các đối tượng, giao diện, và các mối quan hệ của họ với nhau. Bạn có thể miêu tả cấu trúc vật lý bằng cách sử dụng mô hình tĩnh, trong đó bao gồm các sơ đồ lớp và sơ đồ đối tượng. Chương này giải thích các khái niệm cơ bản của mô hình tĩnh. Ngoài ra, nó giải thích làm thế...
Before developing a software system, a developer needs to understand its physical structure The physical structure of a software system consists of classes, objects, interfaces, and their relationships with each other You can depict the physical structure by using static modeling, which includes class diagrams and object diagrams This chapter explains the basic concepts of static modeling In addition, it explains how to create class diagrams and object diagrams Objectives In this chapter, you will learn to: Apply the basic concepts of static modeling Create class and object diagrams Chapter Understanding Static Modeling Applying the Basic Concepts of Static Modeling BlueSeas group, a leading retail chain store, plans to extend special discounts and offers to their premium customers The existing customer information database needs to be modified to group the customers based on their unique buying behavior Before developing a customer information system for BlueSeas group, you need to identify the use cases and model the static structure of the software system In static modeling, you identify classes, interfaces, collaborations, and their relationships to create class diagrams You also create object diagrams to represent the values of attributes for a specific instance of a class and the relationships among objects Identifying Classes and Objects You can derive classes and objects from the use cases of the software system This approach enables you to realize the function of use cases in the design phase It also enables you to focus on the requirements identified in the analysis phase For example, the following use cases define the functions of the customer information system for the BlueSeas group: Save Customer Information: Stores the information about customers, such as name, address, and contact number Save Product Details: Stores the information about the product Save Purchase Details: Stores the information about the purchase Calculate Purchase Amount: Calculates the total cost of products purchased by a customer Select Discount: Selects the discount to be offered based on the total cost of products purchased by the customer Calculate Payable Amount: Deducts the discount from the total cost to obtain the amount payable by the customer Generate Bill: Generates a receipt for the amount payable by the customer Accept Payment: Provides an interface on multiple counters to accept payment from customers Based on these use cases, you can identify the following classes: Customer: Maintains customer information Product: Maintains the information about the product PurchaseDetail: Maintains the information about the purchase and calculates the total amount of purchase Discount: Selects the discount to be offered to a customer Bill: Calculates the payable amount and, then, generates a bill for the customer ÔNIIT Understanding Static Modeling 5.3 PaymentCounter: Defines the operations to calculate the payable amount and generate the bill to collect payment from the customer The Customer class maintains the addresses of customers that can be stored in various fields, such as city, state, and zip code Therefore, you can segregate the Address class as a subclass of the Customer class Another common method that organizations deploy to identify classes and objects is to determine all the responsibilities of the software system Consider the example of the customer information system of BlueSeas group In this example, you will notice that the responsibilities of the customer information system map to the classes identified from use cases The responsibilities of the customer information system are to: Maintain customer information, such as name, address, and contact number Maintain the information about the products Maintain the information about the purchase made by customers Calculate the total amount of purchase made by customers Select the discount based on the total amount of purchase for each customer Calculate the amount payable by customers Prepare bills for customers Collect payment from customers on multiple counters You can also select all the nouns and noun phrases from the statements of the SRS document to identify classes However, you discard the nouns and noun phrases that are not appropriate and modify the remaining to obtain a list of classes for the system For example, consider the following statement that the SRS document of the customer information system contains: A customer purchases products The purchase details are stored to calculate the discount offered to the customer In the preceding statement, the noun words are underlined These words can be the names of the classes for the software system Note It is advisable to apply all the three approaches to identify objects and classes in parallel This ensures that each approach complements the other in identifying the complete list of classes for the software system 5.4 Understanding Static Modeling ÔNIIT Creating Class and Object Diagrams Static Modeling technique is used to depict the static constituents of a software system Class diagrams and Object diagrams are the Static Structure Models that are required to represent the static constituents of a software system Class diagrams are used to represent the classes, attributes and the relationship between these classes whereas Object diagrams are used to represent the instance of these static constituents Introducing Class Diagrams UML provides a class notation to represent classes in class diagrams The class notation has three compartments: The first compartment depicts the name of the class The second compartment depicts the attributes of the class The third compartment depicts the operations of the class The following figure depicts the notation of a class Customer Name of the class custName:String custPhnum:Int Attributes of the class purchaseItem() requestBill() enterCustDetail() Operations of the class Class Notation ÔNIIT Understanding Static Modeling 5.5 The preceding class notation depicts the attributes of a class as a string You can also depict the attributes of a class as an association For example, you can represent the properties of the Customer class, as shown in the following figure Association Notation The preceding figure depicts a property as a solid line between two classes, source class being the class name and target class being the data type class The name of the property is stated at the target end of the association Note Attributes are the properties or structural features of a class Operations are the actions or functions that a class performs You can use class notations to: Analyze the requirements of the system At the analysis level, the class notation depicts only the attributes and operations Implement the requirements of the system at the implementation phase At the implementation level, the class notation depicts attributes, operations, and their visibility Visibility specifies whether or not the objects of a class can access the attributes and operations of another class The primary reason to depict visibility at the implementation phase is that a detailed class notation enables you to identify the necessary information required to implement a code UML provides the following four visibilities for the attributes and operations of a class: +: Indicates that the attribute or operation is visible to other classes In other words, the attribute or operation is public -: Indicates that the attribute or operation is not visible to other classes In other words, the attribute or operation is private 5.6 Understanding Static Modeling ÔNIIT #: Indicates that the attribute or operation in the base class is visible to derived classes In other words, the attribute or operation is protected ~: Indicates that the attribute or operation is visible to the classes, which are within the same package The following figure shows the visibility of attributes and operations of the Customer class Class Notation in the Implementation Phase Note The attributes and operations of a class are called encapsulated if their visibility is private Just a minute: Which of the following visibilities provided by UML indicates that the attribute/ operation in the base class are protected? + # ~ Answer: # ÔNIIT Understanding Static Modeling 5.7 Syntax for Attributes The attributes of a class follow certain syntax in the class diagrams The syntax to depict the attributes in a class diagram is: visibility name: type multiplicity = default {property–string} The preceding syntax contains the following fields: visibility: Specifies whether the attribute of the class is private, public, protected, or package name: Indicates the name of the attribute This is a mandatory field type: Specifies the data type of the attribute multiplicity: Indicates the number of values that can be stored in an attribute default: Indicates the default value of the attributes of objects property-string: Specifies property values that apply to the attribute, such as {ReadOnly} and {Ordered} This is an optional field The following figure shows the example of the purchaseDate attribute of the Product class - purchaseDate: Date [1] = "01-01-2000" {readOnly} Visibility Name Type Default Property-String Multiplicity An Example of an Attribute Syntax for Operations The syntax to represent the operations of a class in the class diagrams is: visibility name (parameter-list): return-type (property-string) The preceding syntax contains the following fields: visibility: Specifies whether the operation of the class is private, public, protected, or package This is an optional field name: Indicates the name of the operation parameter-list: Indicates the list of parameters for the operation return-type: Represents the data type of the value returned by the operation This field can take the null value when the operation does not return any value 5.8 Understanding Static Modeling ÔNIIT property-string: Indicates the type of operation This is an optional field An operation can be of the following types: z abstract: Indicates an abstract operation that is defined in an abstract superclass but implemented by subclasses z query: Indicates a query-like operation that returns a related set of structured data The parameters of an operation are denoted using the following syntax: direction name: type = default value In the preceding syntax, the field, direction, specifies the type of parameter A parameter can be of the following types: in: Indicates an input parameter, the value of which does not change at run time out: Indicates a return parameter, the value of which may change at run time inout: Indicates an input parameter, the value of which may change at run time The parameter type is assumed to be in if no direction is specified in the parameter declaration The field, default value, represents the default value of the parameter and is optional An example of a parameter declaration is as follows: prodID: Int = 01 In the preceding example, the prodID parameter is an input parameter, the value of which does not change at run time The data type of prodID is Int and the default value is 01 An example of an operation declaration in the class diagram is as follows: +generatePurchaseList(prodID: Int): String ÔNIIT Understanding Static Modeling 5.9 The following figure shows a class notation with the syntax to depict attributes, operations, and parameters Data Type Property String Default Value Multiplicity Name of Attribute PurchaseDetails Visibility -purchaseDate: Date [1…*] = "01-01-2000" {ReadOnly} -productID:Int[1…*] -custID:Int[1] -quantity:Int[1…*]=0 Visibility +caluculateTotalAmt():Float +generatePurchaseList(prodID:Int): String Data Type Name of Operation Name of Parameter Return Type An Example of a Class Introducing Object Diagrams You use class diagrams to represent static elements of the software system To represent the instances of these static elements, you use object diagrams In other words, object diagrams represent the properties of a particular instance of a class You use an object diagram as a rectangular box with two compartments: The first compartment represents the name of the object and the class The second compartment represents the attributes and values of the object For example, the CustObj object represents the values of attributes of the Customer class for a specific instance, as shown in the following figure Object Diagram 5.10 Understanding Static Modeling ÔNIIT Note that the operations of the objects are not included in the representation of the object diagrams This is because the operations of objects are the same as the operations of a class Representing Relationships in Class and Object Diagrams In UML, relationships model the way in which the elements of a software system connect to each other, either logically or physically The various types of relationships among classes and objects are: Association Dependency Generalization Realization Association Association represents the static relationship shared among the objects of two classes By default, association is bi-directional For example, a customer purchases a product and a product sold always has a customer associated with it Therefore, the objects of the Customer class have an association relationship with the objects of the Product class, as shown in the following figure Customer Is Sold To Purchases Address Association Relationship An association among classes can also be unidirectional You use an arrow to denote a unidirectional association For example, the objects of the Customer class have a unidirectional association with the objects of the Address class, as shown in the following figure Customer Has Address Unidirectional Association Relationship An association relationship has an attribute called multiplicity Multiplicity represents the number of objects of a class that are connected to an object of another class ÔNIIT Understanding Static Modeling 5.11 For example, a customer can purchase many products, but a product can be sold to only one customer Therefore, an object of the Customer class is associated with many objects of the Product class, as shown in the following figure Customer Is Sold To Purchases * Address Multiplicity Relationship The four types of multiplicity relationships that can exist among the objects of classes are: Exactly one (1): Specifies that only one object of a class is related to the object/s of another class One or zero (0 1): Specifies that zero or one object of a class is related to the object/s of another class Many (0 *): Specifies that zero or many objects of a class are related to the object/s of another class One or more (1 *): Specifies that one or many objects of a class are related to the object/s of another class Note The bi-directional association relationship has two role names, whereas, the unidirectional association relationship has only one role name Also, note that a line is used to represent a bi-directional relationship, whereas, an arrow is used to represent a unidirectional relationship Association relationship is of two types: Aggregation: Represents an association between two classes such that class A is a part of class B and class A can exist independently For example, the Bill class is a part of the Customer class and the Bill class can exist independently For this reason, the Customer class has an aggregation relationship with the Bill class, as shown in the following figure Bill Belongs to Customer Aggregation Relationship 5.12 Understanding Static Modeling ÔNIIT Composition: Represents an association between two classes such that class A contains class B and also controls the lifetime of class B Controlling the lifetime of class B by class A means that the existence of class B depends on class A For example, the Address class has a composition relationship with the Customer class, as shown in the following figure Composition Relationship Dependency Dependency represents the semantic relationship between two classes such that a change in the attributes and operations of one class affects the attributes and operations of the other class For example, a change in the discount value affects the bill of a customer Therefore, the Bill class depends on the Discount class, as shown in the following figure Discount Bill Dependency Relationship Generalization Generalization represents how super classes are related to sub classes Super classes are called base classes and sub classes are known as derived classes ÔNIIT Understanding Static Modeling 5.13 For example, you can classify the customers of the retail store into two categories, premium and regular customers The PremiumCustomer and RegularCustomer classes inherit the attributes from the Customer class For this reason, the Customer class shares a generalization relationship with the PremiumCustomer and RegularCustomer classes, as shown in the following figure Generalization Relationship Realization Realization represents the semantic relationship among the components of a class diagram, where one component specifies a contract and the other component implements the contract You define a contract as a set of functions For example, there may be various payment counters in the store to pay the bill In this scenario, the payment counter acts as an interface that realizes the Bill class to generate a bill for a customer The PaymentCounter interface and Bill class share a realization relationship, as shown in the following figure Realization Relationship Note The denotes that PaymentCounter is an interface You will learn more about interfaces in the next chapter 5.14 Understanding Static Modeling ÔNIIT Just a minute: Which of the following represents the semantic relationship between two classes such that a change in the attributes and operations of one class affects the attributes and operations of the other class? Generalization Dependency Realization Aggregation Answer: ÔNIIT Dependency Understanding Static Modeling 5.15 Depicting a Class Diagram for the Customer Information System The following class diagram depicts the relationship among classes for the customer information system of BlueSeas group Class Diagram Depicting the Relationships among Classes The Customer class contains customer information, such as the name, address and ID of customers Therefore, the Address class is a part of the Customer class The store offers 5.16 Understanding Static Modeling ÔNIIT discounts to its regular and premium customers For this reason, the Customer class shares a generalization relationship with the RegularCustomer and PremiumCustomer classes A customer can purchase several products Therefore, the Customer class is associated to the Product class and the multiplicity relationship is depicted as one to many The PurchaseDetail class contains the information about of the purchase made by the customer In addition, this class calculates the total cost of purchase for the customer The Discount class is dependent upon the PurchaseDetail class for the value of the purchase made by the customer The Discount class selects a discount value based on the total cost of purchase The Bill class calculates the payable amount for the customer by deducting the discount from the total cost of purchase Therefore, the Bill class depends on the PurchaseDetail and Discount classes The Bill class also generates a bill for the customer Therefore, the Bill and Customer classes share an aggregation relationship The PaymentCounter interface realizes the functions of the Bill class to provide an interface on multiple counters For this reason, the calculatePayableAmt() and generateBill() operations are declared in the PaymentCounter inerface and implemented in the Bill class ÔNIIT Understanding Static Modeling 5.17 Practice Questions Consider the following syntax for an attribute: visibility name: type multiplicity = default{property-string} In the preceding syntax, multiplicity refers to: a Values of the attributes of objects b Number of values that can be stored in an attribute c The additional property of an attribute d The data type of the attribute Which of the following represents the static relationship among the objects of two classes? a Association b Dependency c Generalization d Realization Which of the following represents an association between two classes such that class X contains class Y and also controls the lifetime of class Y? a Aggregation b Composition c Bi-directional d Unidirectional Which of the following multiplicity relationships specifies that zero or many objects of a class are related to the objects of another class? a Exactly one (1) b One or zero (0 1) c Many (0 *) d One or more (1 *) Which of the following visibilities provided by UML indicates that the attribute or operation is visible to the classes within the same package? a + b – c # d ~ 5.18 Understanding Static Modeling ÔNIIT Summary In this chapter, you learned that: Static modeling involves identifying the static elements and their relationships to depict the static structure of the software system The class and object diagrams are created to model the static structure of a software system The class diagram notation represents the name, attributes, and operations of a class The instances of the class diagram elements and their relationships need to be identified in order to create object diagrams Instances refer to the objects of the software system The object diagram notation represents the name and attributes of the object It also includes the name of the class and the values of the attributes for a specific instance The various types of relationships shared by objects and classes are: z Association z Dependency z Generalization z Realization ÔNIIT Understanding Static Modeling 5.19 Exercises Exercise You need to create a class diagram for an employee information system For this, you need to identify various classes The Employee and Address classes can be two of them The Employee class consists of empcode, name, address, and birthDate as attributes The Address class contains houseNumber, streetNumber, city, and zipcode as attributes Identify the relationship between the Employee and Address classes 5.20 Understanding Static Modeling ÔNIIT