The transformational implementation of JSD process specifications via finite automata representation

Conventional structured methods of software engineering are often based on the use of functional decomposition coupled with the Waterfall development process model. This approach is argued to be inadequate for coping with the evolutionary nature of large software systems. Alternative development paradigms, including the operational paradigm and the transformational paradigm, have been proposed to address the inadequacies of this conventional view of software developement, and these are reviewed. JSD is presented as an example of an operational approach to software engineering, and is contrasted with other well documented examples. The thesis shows how aspects of JSD can be characterised with reference to formal language theory and automata theory. In particular, it is noted that Jackson structure diagrams are equivalent to regular expressions and can be thought of as specifying corresponding finite automata. The thesis discusses the automatic transformation of structure diagrams into finite automata using an algorithm adapted from compiler theory, and then extends the technique to deal with areas of JSD which are not strictly formalisable in terms of regular languages. In particular, an elegant and novel method for dealing with so called recognition (or parsing) difficulties is described,. Various applications of the extended technique are described. They include a new method of automatically implementing the dismemberment transformation; an efficient way of implementing inversion in languages lacking a goto-statement; and a new in-the-large implementation strategy.

An investigation of the dynamic characteristics of a bolted-rotor system

A Jeffcott rotor consists of a disc at the centre of an axle supported at its end by bearings. A bolted Jeffcott rotor is formed by two discs, each with a shaft on one side. The discs are held together by spring loaded bolts near the outer edge. When the rotor turns there is tendency for the discs to separate on one side. This effect is more marked if the rotor is unbalanced, especially at resonance speeds. The equations of motion of the system have been developed with four degrees of freedom to include the rotor and bearing movements in the respective axes. These equations which include non-linear terms caused by the rotor opening, are subjected to external force such from rotor imbalance. A simulation model based on these equations was created using SIMULINK. An experimental test rig was used to characterise the dynamic features. Rotor discs open at a lateral displacement of the rotor of 0.8 mm. This is the threshold value used to show the change of stiffness from high stiffness to low stiffness. The experimental results, which measure the vibration amplitude of the rotor, show the dynamic behaviour of the bolted rotor due to imbalance. Close agreement of the experimental and theoretical results from time histories, waterfall plots, pseudo-phase plots and rotor orbit plot, indicated the validity of the model and existence of the non-linear jump phenomenon.

Utveckling av programvara för läsning och skrivning till iButton

Dagens dataloggare har många funktioner vilket avspeglas i programvaran som används för att kommunicera med dem. De har fler funktioner än vad enskilda företag och privatpersoner behöver vilket gör programvaran onödigt komplicerad. Genom att minska antalet inställningsmöjligheter kan programvaran göras mindre, snabbare och lättare att lära sig. Arbetet utfördes hos Inventech Europe AB som tillhandahöll dataloggare för temperatur- och fuktighetsmätning. De ville undersöka möjligheterna att utveckla ett program som personer med begränsad datorvana snabbt kunde lära sig att använda. Därför var syftet med detta arbete att utreda hur ett sådant program kunde se ut. Arbetets fokus låg på designprocessen. Genom olika UML-diagram visualiserades de olika momenten i processen. Då projektet var relativt litet valdes en utvecklingsprocess som följer vattenfallsmodellen där de olika stegen (specifikation, design, implementation, test) utförs i följd. Det förutsätter att ett steg är färdigt innan nästa steg påbörjas. Modellen fungerar bäst när projektet är mindre och väldefinierat. Tyvärr ändrades företagets krav på hur programmet skulle fungera flera gånger under arbetets gång. Därmed borde en mer flexibel utvecklingsprocess ha valts för att ge utrymme för förändringar som kunde uppkomma under projektets gång. Slutresultatet blev en funktionsprototyp som var lätt att använda och inte hade fler inställningsmöjligheter än nödvändigt. Funktionsprototyp kan användas som bas för att lägga till egen skräddarsydd funktionalitet. För att visa detta inkluderades ytterligare två funktioner. En av funktionerna var möjligheten att kunna spara insamlad data till en extern databas som sedan kunde användas som källa till andra program vilka exempelvis skulle kunna visualisera data med hjälp av olika grafer. För att lätt kunna identifiera olika inkopplade dataloggare inkluderades även möjligheten att namnge de olika enheterna.