1. Example of Z Specification

1. 1. Example of Z Specification • Consider the problems raised by computerisation of an internal telephone directory, such as that used within the university. • The information is set up in a database, and allows for one person to appear on several extensions as well as several people having to share the same extension. • Six operations are to be provided: • 1. add an entry • 2. query by person • 3. query by extension • 4. remove an entry • 5. add a person • 6. remove a person.

2. 2. Operations. • 1. add an entry (association between person and extension) • 2. query by person ( gives list of extensions) • 3. query by extension (gives list of people) • 4. remove an entry • 5. add a person (followed by add entries to give extensions) • 6. remove person ( and all entries relating to that person).

3. 3. State Space • Let Person be the type of all people and Phone be the type of all possible phone numbers. • This requires a basic type definition • The relation connecting people and phones is denoted by the identifier telephones • telephones is contained in the Cartesian Product Person X Phone. • Cartesian product is the set of all pairs containing one from the first type and one from the second. [ Person , Phone ] telephones : Person <-> Phone.

4. 4. State Space continued • (diller , 4785) belongs to telephones. • So do the following: • (jarratt , 4784) • (jarratt , 3847) • (morris, 3734) • (cotton, 3734) • This subset of the telephones may be represented as a diagram. • Domain dom telephones = { diller, jarratt, morris, cotton}

5. 5. Diagram of state space. Person Phone 3847 jarratt 3734 morris cotton 4784 diller 4785

6. 6. Domain and Range • dom telephones = {diller, jarratt, morris, cotton} • The domain is the set of type Person whose members have a telephone associated with them. • The range of the relation telephones is the set of all phones associated with a person. • In this example: • ran telephones = {3847 , 3734 , 4784 , 4785} • See Diller page 45 for useful operations and further terminology.

7. 7. Union of Two Relations. • To add an extra relation to the state telephones, we might write • This adds an extra Person to the domain of telephones • and an extra Phone to the range of telephones. telephones’ = telephones U (axford,7788)

8. 8. Schemas. PhoneDB members: P Person telephones: Person <-> Phone dom telephones members AddEntry members, members’ : P Person telephones, telephones’ : Person <-> Phone name? : Person newnumber? : Phone dom telephones members dom telephones’ members’ name?  (name? , newnumber? )  telephones’ = telephones U { (name?, newnumber?) } members’ = members

9. 9. Schemas • There are two preconditions of the operation Add Entry • 1. the name must belong to the set members. i.e. you cannot add a telephone number for someone who does not belong to the university. • 2. you cannot add an entry that is already in the database. • The relation telephones’ must contain the union of the relation telephones and the new entry (name? , newnumber?) • Study the first section of the textbook to get additional symbols for concise specification of the schemas.

10. 10. Object-oriented Programming • Currently a major topic in Computer Science. • Hence very fashionable. Annual conference on Object-oriented Programming Systems, Languages and Applications (OOPSLA). • When you read around the topic, you will need to consider what you are reading very critically. • Some papers are genuine “object-oriented” methods. • Others use the term inaccurately, becaus it is fashionable. • You will have to sort the gold from the dross.

11. 11.Object-Oriented Approach. • This views systems and programs as collections of interacting software components. • Not as sequences of functions. • These components are called OBJECTS • Each object has its own set of associated operations. • Messages pass from object to object. • An object is an ENTITY, which has a STATE and a defined SET OF OPERATIONS to modify that state.

12. 12. Object Oriented Approach. • Operations to modify the state may be called “constructor operations”. • Operations which access the state may be called “access operations”. • Object-oriented Design/Programming provides a more direct way of modelling the world than “function-oriented” design/programming. • It is a form of structured design/programming in which the units of structure are software components, not statements or expressions.

13. 13.Object-Oriented Design. • This should not be confused with “object-oriented programming” or “object-oriented programming languages”. • The Object-oriented Languages support the notion of objects. • They allow and object-oriented design to be implemented directly. • Object-oriented design is a methodology which is not dependent on any specific implementation language.

14. 14. Object Oriented Design • Modularity is achieved via abstraction. • Data Abstraction. • Procedural Abstraction. • Iteration Abstraction. • These are instances of INFORMATION HIDING. • Key concepts in object-oriented methods • 1. Information hiding. • 2. Inheritence.

15. 15. Data Encapsulation. • An example of Data Abstraction. • This is the combination of a data structure, together with the operations to be performed on that data structure. • Example: • A Stack. This is an ordered list where all insertions and deletions are made at one end, called the “top”. Its operations must include “push” and “pop”. X B C D A B C D B C D pop push

16. 16. Abstraction. • The functions themselves are examples of procedural abstraction. • Abstraction is a means of achieving stepwise refinement of the design, by • suppressing unnecessary details and • accentuating the relevant ones. • Iteration abstration allows the developer to specify at a high level that a loop will be used • then at a lower level, describe the exact elements over which the iteration is to be performed and the order in which they shall be processed.

17. 17. Object Oriented Approach. • All design methodologies aim to master the complexity of a problem by means of modularity and information hiding. • Object oriented methodology claims to offer the best results. • Object oriented appraoch • = Objects • + classification • + inheritence • + communication with messages.

18. 18. Key Concepts. • This approach is characterised by the following key concepts: • objects • messages and methods • classes and instances • inheritence • Next week, read the appropriate chapters in any books you can find and make your own detailed notes on each of these topics. Try and find a good example to illustrate each one. You should share your results with each other.

19. 19. Example. Send Flowers to a Friend • Arrange for the flowers to be sent by a Florist. • i.e. find an agent and pass a message containing the request. • The agent (florist) will know a method to satisfy the request. • 1. Principle of MESSAGES and METHODS. • Action is initiated by the transmission of a MESSAGE to an agent (or object) responsible for the action. In response, the agent will perform some METHOD to carry out the request. • 2. Principle of Information Hiding. • The request for action indicates only the desired result. No details about the method are needed.

20. 20. Concept of an Object. • Objects contain both data and methods ( theprocedures that act on this data). • Objects have the ability to act. • When an object receives a message, this is an action asking the object to behave in some way. • When an object-oriented program is running: • objects are created when needed. • messages move from one object to another • objects are deleted when they are no longer needed (to reclaim memory).

21. 21. Motivation. • Objects are relatively stable. • They avoid the problem of inadvertantly shifting the underlying representation when moving from analysis to design. • Published account detail problems when using design methodologies. • These usually occur when moving from data flow diagrams (the underlying netwrok organisation for analysis) to program structure charts (the underlying hierarchical organisation for design). • These problems become more severe as the systems become larger.

22. 22. Classes and Instances. • All objects are INSTANCES of a certain CLASS. • A CLASS consists of methods and data summarising the common characteristics. • The method invoked by an object in response to a message is determined by the class of the receiver. All objects in the same class respond in the same way. • e.g. In our previous example “Florist” is a subclass of “Shopkeeper” (e.g. expects money in return for goods or services) and “shopkeeper” belongs to class”Human” etc. • Inheritence is the principle that knowledge of a more general category is also applicable to a more specific category.

23. 23. Inheritence Material Object Animal Plant Mammal Dog Horse Human Artist Shopkeeper Florist Classes can be organised into a hierarchical inheritence structure. A SUBCLASS will inherit attributes from a SUPRCLASS higher in the tree. An ABSTRACT superclass has no instances. It is used only to create subclasses.

24. 24. Inheritence • Properties or characteristics received from a ancestor. • Two important relationships. • IS-A • HAS-A • 1. The first concept is a specialised instance of the second. e.g. A Car IS-A Vehicle. • 2. The second concept is a component of the first. e.g. A Car HAS-A Engine.

25. 25. Object oriented Design Weather Station Weather Data Pollution Record Clock Rainfall Wind speed Air Quality No need to change the software for the other objects when the new software concerning the pollution record is added to the system. Rain Guage Anemometer

26. 26. Example: Cash-point Machine. • Machine through which customers can perform a number of transactions. • It consists of display screen, card-reader, input keys, money dispenser, & printer. • When card is inserted, user is asked for Id (PIN number). • Main menu lists transactions e.g. • withdraw funds from account. • transfer funds between accounts. • query balence of account • end transactions. • 1. Write down all the phrases you can think of relating to this problem.

27. 27. Derive Classes and hence Objects. • Elimination Phase. • Devide your list into 3 categories, namely obvious classes, obvious nonsense and uncertain. • Discard the nonsense. • Keep the classes. • Study the others in greater detail until you have placed them in one or the other. • Then try to model the system with the classes you have retained.