Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Traditionally, thinking and research in software development has focused on solutions: on programs and on various abstractions that may be useful in designing and writing program texts. We have paid little or no attention to the problems that those programs are intended to solve. Even methods and approaches that claim the title of ‘problem analysis’ usually prove, on closer inspection, to deal entirely with putative or outline solutions; the problem to be solved must be inferred from its solution. This solution-oriented approach may work well in a field where the problems are all well known and have been thoroughly described, classified and investigated ¾ where innovation lies only in devising new solutions to old problems. But software development is not such a field. The versatility of computers and their rapid pace of evolution present us with a constantly changing repertoire of problems to whose solution software may be central. As a result, our field is underdeveloped in crucial respects. In particular, the repeated calls for professionalisation and for the establishment of a corpus of core software engineering knowledge are symptoms of a broad failure to identify what practising software developers should know if they are to be fit to tackle the problems of the many different application areas.
This analysis guides the decomposition, gives warning of the concerns and difficulties that are likely  to arise, and provides a context in which previously captured experience can be effectively exploited.
Some problems do not have any relationship with the physical world: e.g., factorising large integers, discovering prime numbers, playing chess.
Most problems we will face are located in the physical world.
The problem is located in the world
The computer is the solution
Problem analysis must be concerned with the world and its phenomena. We need a phenomenology that has nothing to do with programming languages or object interaction, but everything to do with the physical world.
Entities, which are mutable individuals such as cars and people;
events, atomic events occurring in time, e.g. pressing of a button, recognised as individuals;
values, which are immutable individuals such as integers and strings;
states, which are time-changing relations over non-event individuals;
truths, which are unchanging relations over non-event individuals; and
roles, which are the participation of individuals in events.
Among these it is useful to recognise the class of controllable phenomena ¾ events, state changes and roles ¾ that occur on the initiative of one part of the world rather than another. For example, a keystroke is an event in which the user and the keyboard both participate, but it is controlled by the user. It is also useful to treat roles as distinct phenomena. In the keystroke the user controls both the event and the role that is the participation of a particular key; but in a disk read operation the reader controls the event while the disk controls the paricipation of the particular record that is returned.
Domains come in three basic flavours:
Machine domain
Given domain (part of the real world)
Designed domain (a domain created by an action of the system)
The formal crtierion for success in a development is a relationship among the descriotions: machine specification, domain properties, and requirement
MS, DP ë R
Ie, if the machine behaves as specified and the domain has the described intrinsic properties, then the requirement has been satisfied. E.g., if the machine detects button presses and sensor states and operates the lift and door motors, all in accordance with the specification, and if the lift position and behaviour are related to the sensor states and motor settings as described in the domain properties description, then the lift will come when the button is pressed.
The intrinsic domain properties bridge the gap between the phenomena mentioned in the requirement and the phenomena directly accessible to the machine at its external interface to the world.
We ragrd problem classes as categorised by problem frames. Each frame is an elaboration of the general form shown on the next slide. Each frame is either elementary or composite. A problem of the class characterised by an elementary frame is to be captured by building descriptions appropriate to the frame. A problem of a composite class is first decomposed into subproblems characterised by elementary frames.
The machine, the world, and the requirements are the PRINCIPAL PARTS of the software development problem. The SOLUTION TASK is to construct a machine such that its interaction with the world will ensure satisfaction of the requirement.
The interface between the machine (Control Machine) and the controlled domain consists of shared controllable phenomena ¾ C1 controlled by the machine and C2 controlled by the controlled domain. Typically, the controlled domain is partly autonomous and partly responsive to the phenomena C1. A central concern is the adequacy of the information conveyed to the machine by the phenomena C2 for the machine to implement an effective control rule by controlling the phenomena C2. ABS is an example of a simple behaviour problem.
·    Simple Information Answers. This is an idealised form of a simple information system (Response Machine) that answers enquiries. Enquiries in the form of an unstructured stream of events E1 come from an autonomous Enquirer; the machine creates its answers (Responses) by events E2. The subject of the enquiries is the Real World, which may be static (having no controllable phenomena); if it is not static it is autonomous, controlling all the phenomena H1 at its interface with the machine. The requirement (Information Relation) stipulates a relationship between the answer events E2, the enquiry events E1, and the phenomena H2 of the real world.
A central concern is the use of the interface phenomena H1 to make inferences about the phenomena H2 that are the subject of the requirement. Provision of stock prices is an example of a simple enquiry problem. Note, the stripe in the Responses domain indicates that it is a DESIGNED DOMAIN, i.e. it is created by the activity of the system
·    Simple Information Display. This is an idealised form of a simple information system (Display Machine) that maintains a continuous display of information (Information Display) about an autonomous dynamic Real World. The requirement (Display Rules) stipulates the state S2 of the display for each state S1 of the real world. The display is reactive, changing its states S2 in response to the machine-controlled phenomena C2.
A central concern is the use of the interface phenomena C1 to provide inferences about the phenomena S1 that are the subject of the requirement. Controlling the display in a hotel lobby that shows the current positions of the lifts is an example of a simple information display problem.
·    Simple Workpieces. This is an idealised form of a problem in which the machine (Tool) acts as a simple tool for the creation and manipulation of text or graphic objects (Workpieces). The user of the tool autonomously issues an unstructured stream of commands (Operation Requests) E1, which the machine may sometimes inhibit. The workpieces are regarded as given ¾ that is, their design is not considered to be a part of the workpieces problem itself. They are state reactive: that is, their behaviour consists only of changing their states S1 in response to events E2. The heavy dot on their interface with the machine indicates that they are contained in the machine: that is, all their phenomena are phenomena of the machine.
A central concern is that the machine must inhibit invalid operation requests E1 (such as a deletion request for a non-existent workpiece), and must convert valid requests E1 into appropriate combinations of invocations E2 at the interface with the workpieces. The control of setting a VCR memo to record a TV program is an example of a simple workpieces problem.
The input stream is given, but the output stream is made by program
The requirement is the Input/Output relation. It stipulates a relationship between the phenomena Y3 (the values and truths)  of the inputs domain and the phenomena Y4 of the outputs domain. The relationship must be established ny making the outputs appropriately; the inputs are given and cannot be changed. The machine, or Program, has access to the phenomena Y1 of the inputs domain and can determine the phenomena Y2 of the outputs domain. Y1 & Y3/ Y2 & Y4 may or may not be the same. Probably not the same: the machine must deal in more elementary phenomena such as characters, while the requirement refers to larger phenomena, such as records and fields.