Object analysis CLASSIFICATION 1 OO ANALYSIS Develop use

Object analysis CLASSIFICATION 1

OO ANALYSIS Develop use cases , activity diagrams Identify actors prototyping Develop interaction diagrams Id classes, relationships, & methods Refine and iterate OO ANALYSIS 2

analysis 1. IDENTIFY THE ACTORS 2. DEVELOP A SIMPLE PROCESS MODEL design 6. REFINE & COMPLETE STATIC UML CLASS DIAGRAM (OBJECT MODEL) • advantage: familarise with the system 1. refine attributes, 2. Design methods & protocols. Use activity diagram 3. Refine associations, 4. refine class hierarchy & inheritance 5. Iterate & refine 3. DEVELOP THE USE CASE DIAGRAM • what will the user be doing with the system? • captures goal of the users & responsibility of system to users • provides comprehensive documentation of the system 4. INTERACTION DIAGRAM 1. Develop sequence diagram 2. Develop collaborations diagram 3. Iterate & refine 5. CLASSIFICATION 1. Identify classes 2. -”- relationships 3. -”- attributes 4. -”- methods 5. Iterate & refine 7. DESIGN THE ACCESS LAYER 1. Create & mirror business classes 2. Define relationships among access classes 3. Simplify class & structure a. Eliminate redundant classes b. Eliminate redundant methods 4. Iterate & refine 8. Design VIEW ACCESS LAYER CLASSES 3

Classification • Object-Oriented analysis is a process by which we can identify classes that play a role in achieving system goals and requirements • Classification guides us in making decisions about modularization. – we may choose to place certain class and objects together in the same module or in different modules, depending upon the sameness in the declarations – Classification also plays a role in allocating processes to procedures depending upon packing, performance, or reliability concerns 4

Classification • A class – is a specification of structure, behavior and description of an object. – are important because they create conceptual building blocks for designing systems. Object oriented approach: • In object oriented programming, the conceptual building blocks guide the designer in defining structure. • In addition object type provides an index for system process. – That is an object should be manipulated via the operations as associated with its type. • Without object types then operation can not be defined properly. 5

• Notations 6

Classes notations 7

Classes notations 8

Classes notations 9

Classes notations – In the context of the Work. Desk, you'd have a – job. Id that would identify a particular Returned. Item. In that sense, job. Id is an – attribute of the association. It's not a feature of Returned. Item because items really have – no knowledge of things like repairs or jobs. Then, given an object of Work. Desk and given a – particular value for job. Id, you can navigate to zero or one objects of Returned. Item. 10

Classes notation : 11

Classes notations 12

CLASS RESPONSIBILITY: IDENTIFYING ATTRIBUTES AND METHODS 13

Class Responsibility: Identifying Attributes and Methods • Is an iterative process • Responsibilities – identify problems that need to be solved – Expressed by a handful of short verb phrases each containing an active verb • Attributes – Attributes are things that an object must remember – Ex: colour, cost • What information about an object must be remembered? • Methods • What services must an object provide? 14

Class Responsibility: Identifying Attributes and Methods • Guidelines for defining attributes – Attributes correspond to nouns followed by prepositional phases – Ex: COST OF soup – Attributes may also correspond to adjectives or adverbs – state only enough attributes to define the Object State. – Attributes are less likely to be fully described in the problem statement. • draw on your knowledge of the application domain and the real world to find them. – Omit derived attributes. • For e. g. do not use age, as age can be derived from date_of_birth • Derived attributes should be expressed as a method. – Do not add excessive attributes. • add more attributes during subsequent iterations. – add only those attributes necessary to the design at hand. 15

Class Attributes • Class Attributes – Represent named properties of a UML class – UML class can have many attributes of different names – Attribute name is generally a short noun or a noun phrase written in lower. Case-first text – Attribute declaration may include visibility, type and initial value: • +attribute. Name : type = initial-value Shape +origin: int #width : int -height : int =10 16

Class Operations – Represent named services provided by a UML class – UML class can have many operations of different names – Operation name is generally a short verb or a verb phrase written in lower. Case-first text – Operation may include visibility, parameters, and return • type: +op. Name(param 1 : type = initial_value) : return-type Shape +move() : void #resize() : boolean -display(always : boolean = true) : boolean 17

Class Visibility • Class Visibility – Three levels of class, attribute and operation visibility: • private (-), available only to the current class • protected (#), available to the current and inherited classes • public (+), available to the current and other classes Shape +origin: int #width : int -height : int = 0 +move(): void #resize() : boolean -display(always : boolean = true) : boolean 18

Class Objects – Each class represents a set of objects that share the same attributes, operations, relationships, and semantics – For each of the class attributes, objects can have specific attribute values – For each of the class operations, objects may have different implementations s 1: Shape +origin: string #width : int -height : int =10 19

Identifying Object Relationships, Attributes & Methods 20

Introduction • Three types of relationship among objects are: – Association: • How are objects associated? This information will guide us in designing classes. – Super-Sub structure / generalization hierarchy): • How are objects organized into super classes and subclasses? • This information provides us the direction of inheritance. – Aggregation and a-part-of structure: • What is the composition of complex classes? • This information guides us in defining mechanisms that properly manage object-within-object 21

I. Association Relationships • IDENTIFYING ASSOCIATION – Analyse interaction between classes – Examine responsibilities to determine dependencies • GUIDELINES that can help to identify associations: • Association corresponds to a noun or a prepositional phrase – Ex part of, next to, works for, contained in • Reference from one class to another class • QUESTIONS that can help to identify associations: – Is the class capable of fulfilling the required task by itself? – If not, what does it need? – From what other class can it acquire what it needs? – If an object is responsible for a specific task (behavior) and lacks all the necessary information to perform that task, then the object must delegate the entire task to another object that possesses such knowledge. 22

I. Association Relationships • ASSOCIATION PATTERNS – Location association – Ex: Next To, Part Of, Contained In » Cheddar cheese is–part-of soup – Communication association – Ex: Talk To, Order To » Customer places an order – Directed actions association • ELIMINATE UN-NECESSARY ASSOCIATION – Implementation association • Defer till design phase – Ternary association • Restate ternary as binary association – Directed actions • State derived actions in terms of other associations – Ex: grandparent can be defines in terms of parents » John grandparent Ken » John parent of Brian Parent of Ken – Add role names wherever necessary 23

II. Super-sub class relationships • NEED – Subclasses are more specialized versions of their superclasses – Inheritance allows classes to share & reuse behaviour & attributes • GUIDELINES – Top down • Specialize only when sub-classes have significant behaviour • Look for noun phrases that are composed of various adjectives in a class name. – Bottom-up • Look for classes with similar attributes or methods » Move the common attributes & methods to an abstract class – Reusability • Move the attributes & methods as high as possible in the hierarchy • Do not create very specialised classes at the top of the hierarchy » Achieve a balance through iteration • Process ensures that you can reuse the design for other applications – Multiple inheritance • Avoid Multiple inheritance » Inherit from most appropriate class. Add the object of the other class 24

III. Part-of / aggregation relationships • PROPERTIES • Two major properties of a-part-of-relationship are transitivity and antisymmetry. –Transitivity: • The property where, if A is part of B and B is part of C, then A is part of C. –for example, a carburetor is part of an engine and an engine is part of a car; therefore, a carburetor is part of a car. –Antisymmetry: • The property of a-part-of relation where, if A is part of B, then B is not part of A. – For example, an engine is part of a car, but a car is not part of an engine. • QUESTIONS • A clear distinction determines where responsibilities for certain behavior must reside. • Ask the following questions. –Does the part class belong to a problem domain? –Is the part class within the system’s responsibilities? –Does the part class capture more than a single value? –Does it provide a useful abstraction in dealing with the problem domain? 25

III. Part-of / aggregation relationships • PATTERNS –Assembly: • An assembly is constructed from its parts and • an assembly-part situation physically exists; –for example, a French onion soup is an assembly of onion, butter, flour, wine, French bread, cheddar cheese, and so on. –Container: • A physical whole encompasses but is not constructed from physical parts; – for example, a house can be considered as a container for furniture and appliances. –Collection-member: • A conceptual whole encompasses parts that may be physical or conceptual; –for example, a football team is a collection of players. 26

CASE STUDY : Problem statement • The bank client must be able to deposit an amount & withdraw an amount from his account using the screen at the ATM kiosk • Each transaction step must be recorded, the client must be able to view all the transactions. transaction must include date, time, transaction type, amount & account balance. • A client has two types of account: checking & saving. For each saving a/c , one related checking a/c can exist • Access to Clients a/c is provided by a 4 digit pin code having digits between 0 to 9. • One pin code allows access to all. • No receipt is provided for any a/c transaction or transaction history • Neither checking nor saving a/c has negative balance. The system should automatically withdraw from the related saving account if the requested withdrawal amount on the checking amount is more than its current balance. • If the balance on the saving a/c is les than the withdrawal amount requested , the transaction will stop and the bank client notified via a message. 27

Case study • ASSOCIATION PATTERNS – Location association – Ex: Next To, Part Of, » Cheddar cheese is–part-of soup Contained In – Communication association – Ex: Talk To, Order To » Customer places an order – Directed actions association • The relation is that each account belongs to a bank client since each Bank. Client has an account. • Therefore there is an association between the Bank. Client and Account classes. 28

Case study • DEFINING SUPER-SUB RELATIONSHIP – Top-down. Look for noun phrases composed of various adjectives in the class name. – Bottom-up. Look for classes with similar attributes or methods. group the common attributes by moving the common attributes and methods to an abstract class. – Reusability. Move attributes and behaviors as high as possible in the hierarchy. – Multiple inheritance. Avoid excessive use of multiple inheritance. • Checking A/c and Savings A/c both are types of accounts. – They can be defined as specializations of the Account class. – When implemented, • the Account class will define attributes and services common to all kinds of accounts, • Checking Account and Savings Account each defining methods that make them more specialized. 29

Case study • IDENTIFYING THE AGGREGATION /A-PART-OF RELATIONSHIP: – Assembly: Physical whole is constructed from physical parts. – Container. A physical whole encompasses but is not constructed from physical parts. – Collection-Member. A conceptual whole encompasses parts that may be physical or conceptual. – Aggregation is a special type of association • A bank accounts of ATM machines, accounts, buildings, employees and so forth. • Buildings and employees are outside the domain of this application, • define the bank class as an aggregation of ATM machine and Account classes. 30

Class Generalization • Class Generalization – Represent a relation between a parent (a more abstract class) and a child (a more specific class) – Generally referred to as a “is-a-kind-of” relationship – Child objects may be used instead of parent objects since they share attributes and operations; the opposite is not true Shape Rectangle Square 31

Class Association • Class Association – Represent a structural relationship between class objects and may be used to navigate between connected objects – Association can be binary, between two classes, or n-ary, among more than two classes – Can include association name, direction, role names, Shape canvas Source 0. . * #target contains 1 32

APPROACHES FOR IDENTIFYING CLASSES • 1. 2. 3. 4. 04 alternate approaches Noun phrase Common class Use case driven & sequence collaboration Classes , responsibilities collaborators approach 33

The noun phrase approach • proposed by Rebecca , Wilkerson, and Lauren 1. Look for nouns and noun phrases in the use cases, • nouns • verbs COULD BE classes methods of the classes. –All plurals are changed to singular, 2. Some classes are implicit or taken from general knowledge. 3. All cases must make sense in the application domain; –avoid computer implementation classes defer them to the design stage. 4. Carefully choose and define class names. • List the nouns. Divide into three categories relevant classes fuzzy classes irrelevant classes. -- eliminate 34

Noun Phrase Approach • Guidelines To Help Selecting Candidate Classes From RELEVANT & FUZZY CATEGORIES • Redundant classes. –Do not keep two classes that express the same information. –If more than one word is being used to describe the same idea, select the on that is the most meaningful in the context of the system. » Faculty’s name is same as lecturer’s name • Adjectives classes. – Adjectives can be used in many ways –. an adjective can suggest a different kind of object, different use of the same object, or it could be utterly irrelevant. – Does the object represented by the noun behave differently when the adjective is applied to it. –If so create a new class for it » Adult members behave different from Youth members » 3 rd year BE students behave differently from 1 st Year BE students 35

Noun Phrase Approach • Attribute Classes: – Tentative objects that are used only as values should be defined or restated as attributes and not as a class » Phone number of student • Irrelevant classes. – Each classes must have a purpose ad every class should be clearly define and necessary. – formulate a statement of purpose for each candidate class. – If you cannot come up with a statement of purpose , simply the drop the class. » Students neighbours history 36

Process of eliminating the redundant classes Review irrelevant classes Review adjectives Review attributes 37

Problem statement • The bank client must be able to deposit an amount & withdraw an amount from his account using the screen at the ATM kiosk • Each transaction step must be recorded, the client must be able to view all the transactions. transaction must include date, time, transaction type, amount & account balance. • A client has two types of account: checking & saving. For each saving a/c , one related checking a/c can exist • Access to Clients a/c is provided by a 4 digit pin code having digits between 0 to 9. • One pin code allows access to all. • No receipt is provided for any a/c transaction or transaction history • Neither checking nor saving a/c has negative balance. The system should automatically withdraw from the related saving account if the requested withdrawal amount on the checking amount is more than its current balance. • If the balance on the saving a/c is les than the withdrawal amount requested , the transaction will stop and the bank 38 client notified via a message.

Initial list of noun phrases: candidate classes • The initial study of the use cases of the bank system produces the following noun phrases – Account balance – Amount – Atm card – Bank client – Checking account – Client’s account – Four digits – Invalid PIN – Message – Password – Pin code – Record – Savings account – System – Transaction history 39

It is safe to eliminate the irrelevant classes. • The candidate classes my be selected from relevant and fuzzy classes. • The following irrelevant classes can be eliminated because they do not belong to the problem statement : • four digits • underline indicate eliminated classes. – Account balance – Amount – Atm card – Bank client – Checking account – Client’s account – Four digits – Invalid PIN – Message – Password – Pin code – Record – Savings account – System – Transaction history 40

Reviewing the redundant classes and building a common vocabulary • review the candidate list to see which classes are redundant. • If different words are being used to describe the same idea, select the one that is the most meaningful in the context of the system and eliminate the others. • The following are the different class names that are being used to refer the same concept: –Client, bankclient = bankclient –Account , client’s account = account –Pin , pin code =pin –Checking , checking account =checking account –Savings, savings account =savings account –Atm card , card =atm card 41

the revised list of candidate classes after eliminating redundant classes –Four digits –Invalid pin –Message =bankclient –Password Client, bankclient Account, client’s account = account –Pin , pin code = pin –Pin code Checking , checking a/c =checking a/c Savings, savings a/c =savings a/c –Record Atm card = atm card –Savings account Review redundant classes –System –Transaction Review irrelevant classes Review adjectives history –Account balance –Amount –Atm card –Bank client –Checking account –Client’s account Review attributes 42

Reviewing the classes containing adjectives • review the remaining list for classes with adjectives. • does the object represent by the noun behave differently when the adjective is applied to it. – If an adjective suggests a different kind of class or the class represented by the noun behaves differently when the adjective is applied to it, then make a new class. – Patient = Patient & Pvt Patient – Account = saving & checking – However if it is a different use of the same object or the class is irrelevant eliminate it. – Client & bank. Client 43

REVIEWING THE POSSIBLE ATTRIBUTES : • The next review focuses on identifying the noun phrases that are attributes, not classes. • The noun phrases used only as values should be restated as attributes. • This process also will help us identify the attributes of the classes in the system. –Amount : A value, not a class. –Account Balance : An attribute of the Account class. –Invalid PIN : It is only a value, not a class. –PIN : An attribute of the Bank. Client class. –Password 44

REVIEWING THE POSSIBLE ATTRIBUTES : – Account balance – Amount – Atm card – Bank client – Checking account – Client’s account – – – Amount : A value, not a class. Four digits Invalid pin Account Balance : An attribute Message of the Account class. Password Pin Invalid PIN : It is only a value, Pin code not a class. Record Savings PIN : An attribute of the Savings account. Bank. Client class. System Transaction history 45

APPROACHES FOR IDENTIFYING CLASSES • REVIEWING THE CLASS PURPOSE : – Identifying the classes that play a role in achieving system goals and requirements. – Each class must have a purpose. – Every class should be clearly defined and necessary in the context of achieving the system goals. – If the statement of purpose for a class cannot be formulated, we should eliminate it or delete it from the list. –ATM Machine class : Provides an interface to the Via. Net bank. –ATM Card class : Provides a client with a key to the account. –Bank. Client class : A client is an individual that has a checking account and a Savings account –Bank class –Account class 46

APPROACHES FOR IDENTIFYING CLASSES • PROBLEMS IN USING NOUN PHRASE APPROACH : – The Noun Phrase Approach depends on the completeness and correctness of the available document, which is rare in real life. – On the other hand, large volumes of text on system documentation might lead to too many candidate classes. – Even so, the noun phrase exercise can be very educational and useful if combined with other approaches, especially with use-cases. 47

Complete UML class diagram Bank. Client first. Name last. Name card. Number pin. Number +verify. Password() has 1 1, 2 ATMMachine address state Account number balance +deposit() +withdraw() create. Transaction() Checking. Account 1 Savings: Account +withdraw() 1 transaction trans. ID trans. Date Account-Transaction* trans. Time trans. Type amount post. Balance Saving. Account Saving-Checking checking 1 48

Noun Phrase Approach……Method 1. List the nouns. Divide into three categories 2 relevant classes fuzzy classes irrelevant classes. -- eliminate Review redundant classes Review irrelevant classes Review adjectives Review attributes 3. reviewing the class purpose 49

COMMON CLASS PATTERNS APPROACH Noun phrase Common class Use case driven & sequence collaboration Classes , responsibilities collaborators approach 50

COMMON CLASS PATTERNS APPROACH • Common class patterns is the second method for identifying classes based on a knowledge base of the common classes that have been proposed 1. 2. 3. 4. 5. 6. Concept class Events class Organisation class People class Places class Tangible things & devices class 51

COMMON CLASS PATTERNS APPROACH 1. CONCEPT CLASS • CONTEXT: – – – A concept is particularly idea or understanding that we have of our world. The concept class encompasses principles that are not tangible but used to organize or keep track of business activities and communication. Example: Performance is an example of concept class. – Hospital = registration 2. EVENTS CLASS • CONTEXT: – – Event classes are points in time that must be recorded. Things Happen, usually to something else at a given date and timer as a step in an ordered sequence associated with things remembered are attributes such as who, what, when, where, how or why. Example: handling, interrupt, request and order are possible events – Billing 52

COMMON CLASS PATTERNS APPROACH 3. ORGANIZATION CLASS • CONTEXT: – – An organization class is a collection of people, resources, facilities or group to which users belong. Example: An accounting department might be considered as a potential class. 4. People class (also known as person, roles and roles played class) • CONTEXT: – The people class represents the different roles users play in – interacting with the application. Example: Employee, client, teacher and manager are examples of people. 53

COMMON CLASS PATTERNS APPROACH 5. PLACES CLASS: • CONTEXT: – – Places are physical locations that the system must keep information about. Example: Buildings, stores, sites and offices are examples of places. – Ward, OT, Medical stores 6. TANGIABLE AND DEVICE CLASS • CONTEXT: – – This class includes physical objects or groups of objects that are tangible and devices with which the application interacts. Example: cars are an example of tangible things, and pressure sensors are an example of devices. – Bar code reader 54

Ex: common class approach • The common class patterns are concepts, events, organization, people, places and tangible things and devices. 1. Event classes – They are points in time that must be recorded – Attributes are associated. – Questions asked : who when where why what how • Account class behavior inherited by saving & checking a/c • Checking Account class models checking a/c, withdrawal service • Savings Account class models client saving a/c • Transaction class track of transaction, time, date, amt & balance 2. Organization class – Organization classes specify collection of people, resources, facilities or groups to which the users belong. • bank class bank clients belong to the bank. It is a database of the accounts and transactions 55

Ex: common class approach 3. People and person approach – The people class represents the different roles users play in interacting with the application. – Class is of two types – Representing user of the system eg: clerk – People whose information is kept by the system • Bank Client Class: bank client having a/c 4. Place class – Places are physical locations that the system must keep information about • Not applicable 5. TANGIBLE AND DEVICE CLASS – This class includes physical objects or groups of objects that are tangible and devices with which the application interacts. • ATM MACHINE CLASS It allows access to all accounts held by the bank client 6. Concept class • Not applicable 56

Use case driven approach & sequence collaboration Noun phrase Common class Use case driven & sequence collaboration Classes , responsibilities collaborators approach 57

Use case driven approach – Modeling with Use-Case is a technique used by unified approach – use cases are employed 1. to model the scenarios in the system and 2. specify what external actors interact with the scenarios. – The scenarios are described in text or through a sequence of steps. – use-case modeling is considered as a problem-driven approach to object-oriented analysis, • problem-driven : the designer first considers the problem at hand • data-driven : first the relationship between objects is considered 58

• Method Use case driven approach – Develop at least one scenario for a significantly different use-case. select one use case. – Offers a high-level view – Determine what object are needed for the scenario to occur. Think about the classes that will be involved in the use case scenario. – Create a child sequence diagram or accompanying collaboration diagram for the use case. Think about the sequence of activity that the actor performs. – Models a more specific analysis – Assists in the design of system by modeling the interactions between objects – Developing sequence diagrams requires us to think about the objects that generate the events and therefore helps 59 identify the classes

Checking account use cases <<extends>> Bank ATM transaction Deposit amount <<extends>> Withdraw amount Deposit checking <<extends>> Withdraw checking Bank client Withdraw more From checking <<uses>> Withdraw saving 60

Bank client ATM Machine Account Checking a/c Insert ATM Card Request PIN Enter PIN Verify PIN OK Request kind Enter kind Request amount Enter Amount Dispense cash Request take cash Process transaction Transaction successful Withdraw checking amount Withdraw successful take cash Request continuation Terminate Print Receipt 61

Use case driven approach • The following classes are identified – Bank. Client – ATM Machine – Account – Checking Account • From other use cases the foll. Classes are identified – Bank – Saving account 62

saving account use cases Deposit amount Withdraw amount <<extends>> Deposit saving <<extends>> Withdraw saving Bank client <<extends>> Withdraw saving denied 63

Transaction use case Bank ATM transaction <<uses>> Approval process <<extends>> Invalid pin Checking transaction history Bank client <<extends>> Saving transaction history <<extends>> 64 Withdraw Amount. Deposit Amount

Classes , Responsibilities Collaborators approach { CRC } Noun phrase Common class Use case driven & sequence collaboration Classes , responsibilities collaborators approach 65

CLASSES , RESPONSIBILITIES & COLLABORATORS Classes , Responsibilities & Collaborators • Classes, responsibilities, and collaborators (CRC), • first presented as a way of teaching the basic concepts of object-oriented development. • is more a teaching technique than a method for identifying classes. • Classes, Responsibilities, and Collaborators is a technique – used for identifying classes’ responsibilities and therefore their attributes and methods. – can help us identify classes. • is based on the idea that • an object either can accomplish a certain responsibility itself or it may require the assistance of other objects, • it must collaborate with those objects to fulfill its responsibilities. • By identifying an object’s responsibilities and collaborators we can identify its attributes and methods. 66

CLASSES , RESPONSIBILITIES & COLLABORATORS Classes , responsibilities & collaborators • Method – The classes, Responsibilities, and Collaborators process consists of three steps. 1. Identify classes’ responsibilities (and identify classes) 2. Assign responsibilities. 3. Identify collaborators. –Classes » are identified and grouped by common attributes, » This grouping also provides candidates for super class. » The class names then are written onto CRC cards. » The card also notes sub- and super classes to show the class structure. –Responsibilities » The application ‘s requirements, then are examined for actions and information associated with each class to find the responsibilities of each class. » Next, the responsibilities are distributed; they should be as general as possible and placed as high as possible in the inheritance hierarchy. –Collaborators » The idea in locating collaborators is to identify how classes interact. » Classes that have a close collaboration are grouped together physically. 67

CLASSES , RESPONSIBILITIES & COLLABORATORS • Classes, Responsibilities and Collaborators cards [CRC] Class. Name Collaborators –They are 4’’ * 6’’ index cards. –All the information for an object is written Responsibilities … on a card, which is • cheap, portable, readily available & … familiar. –The upper left corner • The class name should appear in the upper left-hand corner, –The lower left corner • a bulleted list of responsibilities should appear under it in the left two thirds of the card, Account Checking Account –Right Upper left corner • the list of collaborators should appear in balance (subclass) number Savings Account the right third. • However, rather than simply tracing the details of a collaboration in the form of message sending, CRC cards place the designers’s focus on the motivation for collaboration by representing many messages as phrases of English text. -------- (subclass) Transaction • deposit • withdraw • get. Balance 68

REFERENCES Ø Ali Bahrami, “Object Oriented System Development”, Mc. Graw Hill. Ø Booch, Jacobson, Rumbagh, “The UML user Guide”, Pearson Education. 69

70