- •BlackBox
- •Component Pascal Language Report
- •1. Introduction
- •5. Constant Declarations
- •6.1 Basic Types
- •6.2 Array Types
- •6.3 Record Types
- •6.4 Pointer Types
- •6.5 Procedure Types
- •6.6 String Types
- •7. Variable Declarations
- •8. Expressions
- •8.1 Operands
- •8.2 Operators
- •8.2.1 Logical operators
- •8.2.2 Arithmetic operators
- •8.2.3 Set operators
- •8.2.4 String operators
- •8.2.5 Relations
- •9. Statements
- •9.1 Assignments
- •9.2 Procedure Calls
- •9.3 Statement Sequences
- •9.4 If Statements
- •9.5 Case Statements
- •9.6 While Statements
- •9.7 Repeat Statements
- •9.8 For Statements
- •9.9 Loop Statements
- •9.10 Return and Exit Statements
- •9.11 With Statements
- •10. Procedure Declarations
- •10.2 Methods
- •10.3 Predeclared Procedures
- •Function procedures
- •Proper procedures
- •10.4 Finalization
- •11. Modules
- •Appendix a: Definition of Terms
- •Array compatible
- •Parameter compatible
- •Expression compatible
- •Appendix b: Syntax of Component Pascal
- •Appendix c: Domains of Basic Types
- •Appendix d: Mandatory Requirements for Environment
- •Object Lesson 1 - objects and inheritance
- •Introduction
- •Course Aims - Creating Beautiful Systems
- •Why Design?
- •Design methods
- •Objects
- •How do objects relate to other concepts in design methods?
- •Inheritance
- •The big deal about inheritance
- •Clarity
- •Delegation
- •Relationships
- •One to one relationships
- •One to many relationships
- •Many to many relationships
- •Object Models
- •Exercises
- •Object Lesson 3 Analysis - the rudiments of an approach
- •Removing synonyms and/or generalising
- •Look for attributes
- •Irrelevant objects
- •The process of development
- •Prototyping
- •Evolutionary development
- •Charters
- •Why object modelling lends itself to iterative methods
- •Lesson 4 - Dynamic Modelling - Event traces Dynamic Modelling
- •Event traces - building scenarios
- •Progressing the analysis with event traces
- •What do you do with the event traces?
- •Dynamic modelling - state diagrams
- •An example of an object model for a simple computer
- •An object model for genetic algorithms.
- •Business Activity Modelling - a Starting Point for Software Development Applied to The Functional Specification of a System for Planning Elderly Care in the European Community (planec)
- •Abstract
- •Functional modelling - data flows
- •Use Cases
- •Opening up the use-case requirements model
- •Conclusion
- •Business Process Reengineering
- •Conclusion
Clarity
The notion of breaking the world down into hierarchies of types is not as old as the hills, but it goes back at least as far as the Ancient Greeks: all men are mortal, Socrates is a man, so Socrates is mortal. The reductionist, classification approach is embedded in Western thought, and should be natural for most people to follow.
Experience shows that describing things using hierarchies is an easy and comprehensive way of communicating both structure and functionality.
Summary of this lesson
Objects are a natural way of representing things.
Objects are described by their attributes and their operations.
Objects can be organised in inheritance hierarchies.
Exercises
Describe two of the following objects in terms of their attributes and operations: motor car, sheep, kite, hospital, elephant, garden, school, bacon, teddy bear, bank customer, bus.
Devise a simple inheritance hierarchy for two of the following: geometry, sports teams, politicians, rodents, viral infections, restaurants.
Object Lesson 2 - Relationships and Object Models
Aggregation
We can make up objects our of other objects. This is known as aggregation. The behaviour of the bigger object is defined by the behaviour of its component parts, separately and in conjunction with each other. You will have met a similar idea in program decomposition. Here is a simple example of a juggler:
A juggler has two hands and two feet. He or she uses hands to catch, drop, pick up and throw a ball, and perhaps from time to time scratch his or her head. He or she may also kick a ball with his or her foot.
By analysing our juggler object and breaking it down into component objects, we now have a better understanding of our object. Also, we have discovered two new operations, scratch head and kick.
The diamond in the diagram indicates that one object is made up of another object. The numbers are indicative of how many - more will be said about this shortly. Now the behaviour of a juggler is entirely defined by the behaviour of his or her hands and feet. Of course, real jugglers are made of quite a bit more, but for the purposes of considering their juggling skills we can focus on just the bits of them that are involved in juggling.
Hands and feet could be broken down into their constituent parts, say palms and fingers, soles and toes. However, that does not seem to help us to understand juggling, so the decomposition above is probably enough.
Let us look at another example.
A car engine lubricant is made up of a number of base oils blended with an additive package. The additive package consists of one or more detergents to keep engine surfaces clean, one or more dispersants to suspend particles in the oil to be carried to the filter, one or more anti-oxidants to slow up the thermal decay of the oil, and a viscosity improver to control the viscosity of the oil at different temperatures. A research scientist will experiment with different oils by running engines containing the oils and analysing the effect of the engines on the oils.
Let us look at another example.
For the purposes of assessing the care provision for someone, it is necessary to know their assets, any disabilities they have, any disease they have, any carers they have. Assets are made up of liquid assets, such as cash in the bank, and non-liquid assets such as their home. Carers may be family carers or care packages provided by various services. A care package may be made up of a number of social care packages, such as home helps, and health care packages such as GP service and hospital services.
One of the important analysis and design tools we have is the break-down of complex objects into their constituent parts. It provides a meaningful and sensible decomposition, and it provides scope for re-use of components. Further, the constituent components are often easier to design than large, complex components - this is the thesis on which the early ideas of structured programming were based.