1. Chapter 7,8,appendix C Object-Oriented Analysis and Design 20.1

2. Object-Oriented Analysis and Design Objectives : Introduction to Object Oriented Approach Unified Modeling Language

3. Object Oriented Approach and Technology Modern Software Development (MSD) process uses object oriented technology and approach. Most suited to the current business environment. Why ?  As change is continuous it can maintain the system effectively.  It has ability to thoroughly represent complex relationship Function Oriented approach concentrates how the system functions,

4. Object Oriented Approach and Technology Whereas Object oriented approach concentrates on its data and the behaviour of the data function. Software is build up of self contained objects that work together. Each object has data and functions that describe the object and its behaviour respectively. Objects interact with other objects to achieve a goal of a software application.

5. Object Oriented Approach and Technology Object can be physical like car and employee Symbolic like graph, shape Conceptual like accounting system Event like registration etc. When an object is defined, it is responsible for maintaining its data, features and operation on that data.

6. Object Oriented Approach and Technology Example : Car as an object Car can be described by its colour, chassis, year, model, price and chassis number Car performs operation such as move, stop, turn left, turn right, reverse etc. Advantages: OO systems are easy to adapt changes. OO approach save development – objects can be reused.

7. Object Oriented Approach and Technology The Object Oriented Approach uses a Unified Approach for software development, which combines the best practices, processes methodologies and guidances given by Booch, Rambaugh and Jacobson to provide better understanding of OO concepts and system development. It uses Unified Modeling Language (UML) to describe modeling and documentation of a system.

8. Object Oriented Approach and Technology Unified Approach recommends the following process towards system development Analysis Identification of use cases, objects, classes. Build object oriented analysis model using use case, class diagrams. Design Build object oriented design model using analysis model. Implementation Prototyping and developing the model in increments Continuous testing The processes are repeated for all the functions till the system is fully developed.

9. The Unified Modeling Language (UML) UML provides standard notations for different OO models for better understanding UML is a modeling language used to create an abstract system scenario by visualizing, specifying, constructing and documenting various components of the system into a representative models.

10. The Unified Modeling Language (UML) A wide variety of techniques are used in object oriented analysis and design. These techniques and associated notation are incorporated into a standard object oriented language called the UML. 20.1010

11. The Unified Modeling Language (UML) Every UML diagram plays a unique contributory role in improving the understanding of the system. The eight diagrams of UML are Structural modeling Use Case diagram Static class diagram Behavioural Modeling Sequence diagram Collaboration diagram State Chart diagram Activity diagram Implementation Modeling Component diagram Deployment diagram

12. Structural(Class) Modeling Structural modeling is described things in a system and how these things are related to each other. A thing can be an object, class, a sub-system or a system. Structural modeling is very important process because it is employed throughout the entire system development cycle.

13. Object An object is a self contained entity that has well defined role in the application domain and has state and behavior. An object is a tangible or visible entity e.g. person, place or a thing Object can be physical like car and employee Symbolic like graph, shape Conceptual like accounting system Event like registration etc.

14. Object The state of an object is represented by the values of the properties (attributes) of an object. A object generally has many states, but it can only be in one state at a time. In different states, an object may exhibit different behaviour. The behaviour of an object represents how an object acts and reacts. An object’s behaviour are also known as functions or methods. The behaviour is determined by a set of operations that the object can perform.

15. Example of a student Mary represents an object. The state of this object is characterized by its attributes say name, date of birth, year, address and phone and the values these attributes currently have (Mary, 01/01/1990, Texas). Its behaviour is expressed through an operation such as find_dob which is used to calculate a student’s date of birth. Therefore Mary object packages both its state and its behaviour together

17. Classes The term “class ” refers to a group of objects that share a common attributes and common behaviour (operations). Objects are instances of a class. A class is like a mold and an instance of a class is like a molded object. Example Mary is an object instance, while Student is an object class.

18. Class diagram A class is depicted graphically in a class diagram. In UML, a class is represented by a rectangle with three compartments separated by horizontal lines. The class name appears in the top compartment, the list of attributes in the middle compartments and the list of operations in the bottom compartment of a box.

19. Shape -origin -color +move() +resize() BankAccount -account Name -customerName +getbalance(): float +setbalance() Examples

20. Object diagram An object can be shown in an object diagram as a rectangle with two compartments. The name of the object and its class are underlined and shown in the top compartment as objectname : classname. The object’s attributes and their values are shown in the second compartment

21. Classes A class has methods and attributes while object instances have behaviour and states Example: Bank account is a class which covers many different account types. John’s and Mary accounts are instances of the bank account class.

22. Bank Account -name -balance +debit(in amount) +credit(in amount) Object1 : Bank Account Name = John Smith Balance = 1,000.00 Object2 : Bank Account Name = Robert Jones Balance = - 1,000.00

23. Classes The two instances are in different states. John’s account is in the credit state (positive balance), while Robert’s account is in the withdrawn state (negative balance). The state of the objects can be changed by calling the credit or debit operations. Robert’s account can be changed to the credit state if a credit operation is invoked with a parameter greater than 200.

25. Attributes Things in the real world have properties. An attribute is a property of a class. Attributes attached to classes and objects describe the class or object. An attribute is a data item where an object holds its own state information. Attributes have a name, value and data type e.g. integer, Boolean.

26. Example : A class automobile has an attribute colour. The domain of values for colour is (white, black, silver, gray, blue, red, yellow, green). A book can be described in terms of its author, ISBN, publisher, etc.

27. Operations Each object can perform a set of functions in order to provide a number of services in a software system. A service is defined by one or more operations. An operation is a function or a procedure which can access the object’s data. An operation consists of two parts name argument(s) Thus each object must define its operation for each of its services. The collection of operations is the object’s interface. Other objects only need to know the interface of an object in order to invoke the operations provided by the object.

28. Operations An operation is sometimes called a method or a member function. Examples withdraw(amount) deposit (amount) getbalance()

29. Encapsulation : Information Hiding It is only through such operations that other objects can access or manipulate the information stored in an object. The collection of operations provides an external interface to a class. The interface presents the outside view of the class without showing its internal structure or how the operations are implemented. It is only the producer, developer of that object that knows the details of the internal construction of that object. The users of an object are denied knowledge of the inner working of the object. Other objects only need to know the interface of an object in order to invoke the operations provided by the object. Public interface Protected interface Thus, objects are treated as black boxes. The implementation of objects are hidden from those that use them. This is a powerful concept called “Information Hiding”, better known as encapsulation principle.

30. Encapsulation : Information Hiding Example : The operation “GetColor” for the automobile will extract color stored in the color attribute. The class automobile has been designed to receive a stimulus that request the colour of the particular instance of a class. Whenever an object receives a stimulus, it initiates some behavior i.e. retrieve the color of automobile.

31. Naming Classes Classes are named as noun or a noun phrase. When using name phrases, eliminate the spaces and concatenate the words with their first letter in uppercase e.g. SavingAccount, BankAccount

32. Messages An objects calls another object’s service by sending it a message Messages are the means by which objects interact. A message stimulates some behavior to occur in the receiving object. The behavior is accomplished when an operation is executed.

33. Relationships Relationships exist among objects which links the type of link that exists between objects. Through the link it is possible to discover the other objects that are related to it. Association Generalization Aggregation

34. Association An association is a structural relationship that specifies that objects of one thing are connected to objects of another. A plain association is between two peer classes which means that both classes are conceptually at the same level, no one more important than the other. Given an association connecting two classes, one can navigate( send messages) from an object of one class to an object of the other class and vice versa. It is possible that an object of the class can be linked to other objects of the same class.

35. Association An association that connects exactly two classes is called a binary association. An association that connect more than two classes are called n-ary associations. Graphically, an association is rendered as a solid line connecting the same or different classes. Use association when you want to show structural relationships.

36. Association If an association connects between two objects instead of classes, it is called a link. A link is an instance of an association.

37. BillGates:Person Microsoft:Company Name of link WorkFor Links provide a convenient way to trace the relationship between objects. Specify only those relationships that are necessary for the system

38. Person Company Name of association WorkFor

39. Association There are four adornments that apply to associations. Name Role Multiplicity Note

40. Name : An association can have a name to describe the nature of the relationship. In order to avoid ambiguity about its meaning, the name is given direction by providing a direction triangle that points in the direction the name is to be read as shown below.

41. PersonCompany Name Name direction association Works for

42. Role When a class participates in an association, it has a specific role that it plays in that relationship. A role is just a face the class. Each end of an association ha a role e.g. a Person playing the role of employee is associated with a Company playing the role of employer. The same class can play the same or different roles in other associations.

43. Person Company EmployeeEmployer Role

44. Multiplicity : Multiplicity refers to the number of objects associated with a given object. In many modeling situations, it is important for you to state how many objects may be connected across an instance of an association. This “how many” is called the multiplicity of an association’s role and is written as an expression that evaluates to a range or an explicit value as shown below.

45. Multiplicity : Multiplicity of exactly one is shown as (1), zero or 1 as (0..1), many (0.. *) or one or more a (1.. *). You can even state an exact number ( e.g. 3). We can also specify more complex multiplicities by using a list such as 0..1, 3..4, 6..*, which would mean “ any number of objects other than 2 or 5”.

46. Person Company EmployeeEmployer 1..n 1 Multiplicity : If the multiplicity is not specified, the default value of 1 is assumed.

47. Notes : A Note is a graphical symbol for holding constraints and comments attached to an objects or a class. Constraints are restrictions on attributes and associations of an object or a class for which there is no specific notation. Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment.

48. Reflexive Association and Roles A reflexive association is an association that relates one object of a class to another object of the same class. In other words, a class can be associated with itself Course Prerequisite For

49. Association Class An association can be described by including additional attributes which do not naturally belong to the objects involved in association e.g. the year of enrollment of a student in a course does not belong to the student class or course class. In this case, an association class Enrollment is added to hold the attribute year. The association class has its own class name, attributes and may have operations also.

50. StudentCourse 1..n 1 Enrolled in Enrollment -year Instructor Trained by Taught by

51. Person Company EmployeeEmployer 1..n 1 WorksFor Position -title -starting date -salary

52. Aggregation : Aggregation is a stronger form of association. To model a “whole/part or part-of relationship in which one class represents a larger thing ( the “whole”), which consists of smaller things (“ the parts”) is called aggregation. It represents a “has-a” relationship, meaning that an object of the whole has objects of the part. In UML, a link is placed between the whole and parts classes with a diamond head, attached to the whole class to indicate that this is an aggregation.

53. Company Department whole part aggregation 1 * Aggregation :

54. Multiplicity can be specified at the end of the association for each of the part-of classes to indicate the quantity of the constituent parts. Aggregations are not named Keywords used to identify aggregations are “consists of”, contains, is part of.

55. A stronger form of aggregation is called composition, which implies whole class has exclusive ownership of the parts classes. This means parts may be created after a composite (whole) is created, but such parts will be explicitly removed before the destruction of the composite. In UML, a filled diamond indicates the composition relationship. Composition

56. Person Company EmployeeEmployer 1..n1 Example WorkFor Position -title -starting date -salary Division Department 1..n

57. Object aggregation

59. School Instructor Course Department Student has Member attends Assigned to teaches 0…1 1..* * ** * 1 1

60. Classes All objects that exists within a class inherit its attributes and the operations that are available to manipulate the attributes. A super class is a collection of classes A subclass is a specialized instance of a class.

61. Inheritance The attributes and operations common to a group of subclasses are attached to a super- class and inherited by its sub-classes. Each subclass may also include new features on its own.

62. Properties of inheritance Generalization The purpose of this property is to distribute the commonalities from the superclass among a group of similar sub classes. The subclass ( derived class) inherits all the superclass’s ( base class) operation and attributes. Example:

63. Bank Account -account number -password -balance +getBalance() : float +setBalance() CheckingAccount +checkClearing() SavingsAccount -interest +addinterestToBalance()

64. Generalization BankAccount (superclass) has an attribute account_number and an operation getBalance(), the CheckingAccount (subclass) will also have the same attribute, account_number and the operation getBalance() as it is a subclass of BankAccount. It is unnecessary and inappropriate to show the superclass attributes and operations in the subclasses

65. Specialization Specialization allows subclasses to extend the functionalities of superclass. A subclass can introduce new operations and attributes of its own. Example SavingsAccount inherits attributes account_number, password and balance from BankAccount and extends the functionalities of BankAccount with an additional attribute, interest and an additional operation, addInterestToBalance. A SavingsAccount has the attribute interest that BankAccount does not because not all bank accounts earn interest.

66. Example - specialization A subclass Y inherits all of the attributes and operations associate with its super-class X. This means that all data structures and algorithms originally designed and implemented for X are immediately available for Y- no further work need be done. Reuse has been accomplished directly. Any change to the data or operations contained within a super-class is immediately inherited by all subclasses that have inherited from the super-class. Therefore a change in the super class is immediately propagated through a system.

67. Inheritance Also, at each level of the class hierarchy, new attributes and operations may be added to those classes that have been inherited from higher levels in the hierarchy.

68. X1 CHAR1 CHAR2 CHAR3 X1 X2 CHAR1 CHAR2 CHAR3 CHAR4 CHAR5 X3 CHAR1 CHAR2 CHAR3 CHAR4 CHAR5 CHAR6 X4 CHAR1 CHAR2 CHAR3 CHAR4 CHAR5 CHAR7 CHAR 4 + CHAR 5 CHAR 7 CHAR 6

69. Library class hierarchy

70. User class hierarchy

71. Multiple inheritance Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes Can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics Makes class hierarchy reorganisation more complex

72. Multiple inheritance

73. How to perform object oriented analysis A software engineer should perform the following generic steps Elicit customer requirements for the system Identify scenarios or use case Select classes and objects using basic requirements as a guide Identify attributes and operations that organize classes Build an object relationship model Review the OO analysis model against use cases or scenarios.

74. Use-Case Diagrams Applied to analyze functional requirements of the system Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details Use-Case modeling is done in the early stages of system development life cycle, which helps developers to gain a clear understanding of the functional requirements of the system, without worrying about how to implement the requirements. 20.7474

75. What is a Use case Model? A use case model/diagram captures all the functions (known as use cases) carried out in the system. A use case contains a set of scenarios and each scenario should describe all possible sequence of interactions between a system and a user in a particular environment that are related to a particular role.

76. What is a Use case? A use case describes the behaviour of a system under various conditions as the system responds to request from principal actors. In other words, each scenario includes a normal interaction (main flow) plus scenarios for each possible exception. A use case can be stated as a present –tense verb phrase, containing the verb and the object of the verb e.g. compute gpa of student

77. Elements of a Use Case Diagram Actors: An actor is an external entity that interacts with the system. An actor portrays any entity (or entities) that exchange information with the system. An actor in a use case diagram interacts with a use case to accomplish a specific goal. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor.

78. Elements of a Use Case Diagram There is a difference between an actor and a user. A user is anyone who uses the system. An actor on the other hand, represents a role that a user can play. The actor’s name should indicate that role. An actor is a type or class of users; a user is a specific instance of an actor class playing the actor’s role. A same user can play multiple role. As actors are outside the system, there is nor need to describe them in detail. The advantage of identifying actors is that it helps us to identify the use cases they carry out.

79. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 1. Figure 1: an actor in a use case diagram

80. Elements of a Use Case Diagram To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the roles played and can be easily identified as actors in the system.

81. Elements of a Use Case Diagram Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. In other words, each use case must perform a distinct function. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case.

82. Figure 2: use cases in a use case diagram The name of the use case can be listed inside the ellipse or just below it.

83. Elements of a Use Case Diagram Figure 2 shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a process such as "manage patient records" can in turn have sub-processes like "manage patient's personal information" and "manage patient's medical information."

84. Elements of a Use Case Diagram System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system.

85. Figure 3: a use case diagram depicting the system boundary of a clinic application

86. Elements of a Use Case Diagram Figure 3 shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary. The actors are connected to use cases with lines and that use cases are connected to each other with arrows The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case.

87. Elements of a Use Case Diagram For large and complex systems, each of the modules may be the system boundary. For example, for an Enterprise system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.

88. Relationships in Use Cases Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. Use case relationships can be one of the following:

89. Relationships in Use Cases Include: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. Literally speaking, in an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow. An include relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead points to the child use case and the parent use case is connected at the base of the arrow. The stereotype " >" identifies the relationship as an include relationship.

90. Relationships in Use Cases The dotted line arrow does not indicate any kind of data or process flow between use cases. The use case that is “included” represents a generic function that is common to many business functions. Rather than reproduce that functionality with every use case that needs it, the functionality is factored out in a separate use case that can be used by other use cases.

91. Figure 4: an example of an include relationship

92. Relationships in Use Cases For example, in Figure 4, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the steps defined in the "Validate patient records" use case are also executed.

93. Relationships in Use Cases Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype " >" identifies the relationship as an extend relationship, as shown in Figure 5.

94. Figure 5: an example of an extend relationship

95. Relationships in Use Cases Figure 5 shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case.

96. Relationships in Use Cases Generalizations: A generalization relationship is also a parent-child relationship between use cases. The child use case in the generalization relationship is an enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow with a triangle arrowhead (see Figure 6). The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case.

97. Figure.6: an example of a generalization relationship back

98. Relationships in Use Cases On the face of it, both generalizations and extends appear to be more or less similar. But there is a subtle difference between a generalization relationship and an extend relationship.

99. Relationships in Use Cases When you establish a generalization relationship between use cases, this implies that the parent use case can be replaced by the child use case. On the other hand, an extend relationship between use cases implies that the child use case enhances the functionality of the parent use case into a specialized functionality. The parent use case in an extend relationship cannot be replaced by the child use case.

100. Relationships in Use Cases From the diagram of a generalization relationship (refer to Figure 6), you can see that "Store patient records (paper file)" (parent) use case is depicted as a generalized version of the "Store patient records (computerized file)" (child) use case. Defining a generalization relationship between the two implies that you can replace any occurrence of the "Store patient records (paper file)" use case in the system with the "Store patient records (computerized file)" use case without impacting any function. This would mean that in future you might choose to store patient records in a computerized file instead of as paper documents without impacting other functions in the system. Figure 6

101. Relationships in Use Cases Now, if we had defined this as an extend relationship between the two use cases, this would imply that the "Store patient records (computerized file)" use case is a specialized version of the "Store patient records (paper file)" use case. Hence, you would not be able to seamlessly( without effort) replace the occurrence of the "Store patient records (paper file)" use case with the "Store patient records (computerized file)" use case.

102. ATM Example An ATM system will have a key operated switch that will allow an operator to start and stop the servicing of customers. The ATM will serve on customer at a time. A customer will be required to insert an ATM card and enter a PIN both of which will be sent to the bank for validation as part of each transaction. If the PIN is not valid, then perform the use-case “invalid PIN”. Whenever a customer inserts an ATM card in the card reader of an ATM, a transaction can be started. The customer will then be able to perform one of the following transactions A customer must be able to make a cash withdrawal. A customer must be able to make deposits to any account A customer must be able to make transfer of money between any two accounts linked to the card. A customer must be able to make a balance inquiry of any account linked to the card.

104. Example: Draw a use case diagram (specify the relationship if any) for a university registration system. Class registration, which is the basic flow (course number, section number, term, year) is carried out by the registration clerk. He checks whether the student has opted for registration of special classes (alternative flow). If yes, the Registration for special classes use case will be performed. Registering for a special class requires prior permission of the instructor in addition to the other steps carried out for a regular registration. In normal cases, only class registration would be performed, because students would have met the prerequisite requirements. However, in situations where a student has not taken one or more of the prerequisite, the Prereq course not completed use case is performed. Student billing is initiated by University office, which interacts with the student instances by mailing the tuition invoices.

105. Figure 20-2 Use-case diagram for a university registration system 20.105105

106. Sequence diagrams Sequence diagrams is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order and the inter- system events. All systems are treated as a black box The emphasis of this diagram is events that cross the system boundary from actors to systems. The sequence diagram is a very useful tool to easily represent the dynamic behaviour of a system.

107. The sequence diagrams purpose The sequence diagram is used to primarily to show the interactions between objects in the sequential order that those interactions occur. An organization’s technical staff can find sequence diagrams useful in documenting how a future system should behave. An organization’s developers can use this diagram to force out the system’s object interactions thus fleshing out overall system design.

108. Elements of Sequence Diagram Object: This is the primary element involved in a sequence diagram is an object ( actor or an instance of a class). A sequence diagram consist of sequences of interaction among different objects over a period of time. An object is represented by a named rectangle with a dashed line descending from the center of the bottom edge.. The name to the left of the “:” is the object name and to its right is the class name.

109. freshman: student Fig No.1

110. Elements of Sequence Diagram Messages: The interaction between objects in a sequence diagram is represented as messages.An object sends a message to another object, by means of a line with an arrow pointing towards the receiving object. The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object’s class implements.

111. Elements of Sequence Diagram The first message of a sequence diagram starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.

112. Elements of Sequence Diagram Return Message. A return message is drawn as a dotted line with an arrowhead back to the originating lifeline and above this dotted line return value from the operation is placed. The return messages are optional part of a sequence diagram. Return messages are useful if finer details is required, otherwise invocation message is sufficient.

113. Elements of Sequence Diagram Iterations: A box is drawn to show the iterations i.e. the message are repeated a number of times.

114. Withdraw request Verify account Account OK Withdraw request OK Verify card details Card details OK

115. Scenario for processing a Sale using POS system. 1. Customer arrives at a POS checkout with goods and /or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier, and quantity. 4. System records sale line item and presents item description, price and running total. 5. Cashier repeats steps 3-4 until indicates done( end sale) 6. System presents total with taxes calculated 7. Cashier tells Customer the total and asks for payment 8. Customer pays ( make payment) 9. System handles payment i.e. outputs how much change is due and receipt.

116. Downloading and printing an article using LIBSYS The interaction is involved between four objects of classes User Article Form Workspace Printer A user request for an article The request triggers a request for a copyright form, which is the user has to fill. Once the user has completed the form, the article is downloaded. The user request for print out. A printing request is sent to the printer. Once the printing is completed, the user gets a message. The article is deleted from the LIBSYS workspace.

117. Requirement Statement for using an Elevator A product is to be installed to control elevators in a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints: Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the elevator visits the corresponding floor. Each floor, except the first floor and top floor has two buttons, one to request and up-elevator and one to request a down- elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor and then moves in the desired direction. When an elevator has no requests, it remains at its current floor with its doors closed.

118. Basic scenario of an Elevator Passenger pressed floor button Elevator controller detects floor button pressed Elevator Controller moves Elevator to the floor Elevator Controller makes the Elevator doors open Passenger gets in and presses elevator button Elevator Controller makes the Elevator doors close Elevator Controller makes the Elevator moves to required floor Elevator Controller makes the Elevator doors open Passenger gets out Elevator Controller makes the Elevator doors close

120. Object behaviour modelling A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use- case Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects

121. Issue of electronic items