Semi-Formal Methodologies are "first generation" methodologies that were mostly developed in the 1970s at a time when manual office administration systems were being automated for the first time. Computerized systems were seen as having the same structure and functions as manual systems and consequently, the underlying idea was simply to model the existing system and then design a computerized version it. We will call this approach to software design the semi-formal approach in recognition of the strong links these methods have to earlier program design methods.
Software design methods in the semi-formal strand the focus on the logical flow of control in the program. From a philosophical viewpoint, semi-formal methods adopt a anti-realist ontology and rationalist epistemology, that is they assume that it is ultimately impossible to understand the 'true' nature of objects but that by the application of reason we can begin to make reality more explicable. These methods assume completeness, but not closure, in other words, the designer assumes that the representation and the software description are equivalent but accepts that the representation itself might not be a complete description of reality. This allows the designer to produce descriptions with a structure ideally suited to the demands of more formal languages. Thus, the main problem becomes the validation of software: are we building the right product?
The separation between logical and physical is a powerful tool. If software designers can separate the logical design from the physical design, the task of program design is greatly simplified as the software designer can insulate the program designer from the full complexity of the world leaving the program designer with only the logical design to consider. This ought to facilitate the quick and accurate development of code and data structures and lead to the quick and efficient creation of a new system.
By focusing on the needs of program design, software design methods in the semi-formal can deliver complete logical descriptions. Nonetheless, this completeness is often achieved at the expense of any obvious link to the implementation the design. Thus, the logical description now needs to be supplemented by a physical description. Trying to maintain this split between logical and physical design can be problematical as this means undertaking two separate design exercises. The first is the logical description of the system, which is followed an attempt to reconcile the logical design with the physical reality. This wastes effort and makes the overall design less clear.
The notes for this session are available as a presentation (in pdf format) - lecture notes for session 5