- •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
The process of development
The approach to development recommended here is an iterative one. It involves repeated refinement of the object model. The process needs to be controlled by an appropriate project management process, involving reviews and checkpointing.
There are a variety of techniques for driving this cycle.
Prototyping
The design of the process progresses by the construction of a series of prototypes. The prototypes are constructed using the most productive tools in terms of speed of development. The final system, when constructed, is functionally equivalent to the final prototype, but it is implemented in the most suitable technology for use of the system.
For example, a patient monitoring system, requiring lots of graphical displays from a digital feed, might be prototyped in a spreadsheet because the spreadsheet has very powerful graphics. However, when the system is built it would have to be implemented to run on a specific computer with a limited display and limited amount of memory, without a spreadsheet license. Using iterative design methods, a series of prototypes could be developed using a spreadsheet until functionality is finally agreed. The final prototype would then be used as an active specification for the final system which might be written in C.
Prototyping is useful in the following contexts
at the beginning of a project
in research-oriented projects where there needs to be some exploration of different ways of solving problems
where there is a need to clearly define interfaces
where the client needs reassurance that progress is being made
The weaknesses of prototyping are:
the prototype is often taken on as a final system
there can be difficulty explaining a long lag between first prototype and final system
inevitably there will be some differences between the final system and the final prototype because of different interface mechanisms
Evolutionary development
This process involves a staged implementation of the system. Analysis and design of the next stage is after successful implementation of the previous stage. Evolutionary development is useful if:
a partial implementation of the proposed system is of some use
it is not replacing another system which cannot be integrated appropriately at each stage of development
The weaknesses of evolutionary development are:
disruption caused by each stage of implementation
difficulty controlling the end-point of development
Boxing
Computer systems development is constrained by money, time and personnel available to develop, implement and install. The idea of boxing is to drive the iterative process of development by checkpointing at key stages according to one of the three constraints.
Time-boxing involves setting a time limit on each iteration of the cycle. As the time limit nears, the system is implemented, irrespective of whether the planned functionality is fully implemented. The system is reviewed, and the plans for the next stage take into account what has been achieved and what has been learnt.
Money-boxing is similar to time-boxing, except that the reviews are triggered by expenditure limits. Personnel-boxing involves controlling the process using the time of certain personnel.
Boxing has an advantage of driving the system, and forcing changes of plan as the system development progresses.