- •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
Delegation
The behaviour of an object which is made up of other objects is usually defined by the behaviour of the smaller objects. For example
To start a car, you start the engine. Thus the start operation on the car involves calling the start operation on the engine. This is known as delegation. The engine then will switch on the ignition system, switch on the starter motor then switch off the starter motor. This is further delegation. To stop the car, there will be a call to stop the engine, which in turn will make a further call to switch off the ignition.
You may read elsewhere about the benefits of multiple inheritance. Most of the features of multiple inheritance can be simulated using delegation, with safer consequences. However, the arguments for and against multiple inheritance (inheriting from more than one parent) are lengthy and can be side-stepped for now.
Relationships
Objects can be related in other ways than by inheritance and aggregation. Any relationship between real world objects can be modelled: cats eat canaries, dogs bite postmen, the woodcutter murders the wolf, cars run over little old ladies, employees work for organisations, patients visit hospitals, patients stay in hospitals.
One to one relationships
In a one-to-one relationship, one object is associated with exactly one of its related objects. This is modelled by a straight line drawn between the objects. If the relationship is one-way, then an arrow is used to indicate the direction. The line can be labelled.
Thus a man marries one woman (at a time) and a woman marries one man (at a time). A cat eats one canary (before being battered to death by the little old lady who owned the canary). Canaries do not (in general) eat cats, so the eats relationship is one way.
One to many relationships
Sometimes one object can be related to many objects. This is indicated by different marks at the end of the line.
A player plays for one football team. There are at least 11 players for a given football team. Football teams do not play for players.
Zero or more suitors court the Princes. The black dot at the end of the line indicates zero or more.
Before an adequate suitor comes along, as is well known, a princess will kiss at least one frog, and possibly many more if she gets a taste for them. Frogs, being well mannered creatures and not wishing to appear in the gossip columns, never let more than one Princess kiss them.
Many to many relationships
Sometimes objects at either end of a relationship may be related to many objects at the other end.
A dog may bite zero or more postmen. A postman may be bitten by zero or more dogs.
A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.
Object Models
We now have the notation to describe quite complicated systems. The process of object-oriented analysis and design is one of elaborating an object model, increasing its detail and scope until enough is known to construct a computer system (if indeed that is what is wanted).
Here is a simple model for the Red Riding Hood story
Another example is one to describe patient referrals by GP's to specialists.
Another example is for a lift system:
The object model is the principal output of an analysis and design process. The distinction between analysis and design is much greyer in object-oriented development. Essentially it is one of detail. Analysis usually omits concerns about how a system is to be developed, and some of the objects may not be fully decomposed.
The object model is the central pillar of an analysis or design. It defines the computable elements. The dynamic and functional models discussed later all must result in objects, attributes and operations being defined in the object model. It is comprehensive and complete in terms of defining functionality, specifying not only the data but also the operations on the data.