The Idea of Program Refinement Programs are complex. They are typically so complex, that they go beyond the full comprehension even of the programmer or team who designed them, with all the consequences this has. How can we cope with such complexity in a satisfactory way? An approach, advocated for a long time, is to separate a concise specification of a program - the "what" - from a possibly involved implementation - the "how". Once a specification is obtained from the set of requirements on the program, there can still be a large gap to an efficient implementation. The development from specification to implementation can then proceed by a succession oflayers, such that each layer is a refinement of the previous one. Design decisions can be introduced in refinement steps one at a time. By this, the refinement steps can be kept small and manageable. Still, the set of all requirements can be far too large to be taken completely into account in the initial specification. Even if they could, they might obscure issues more than clarify them. For example: • An information system for stored goods needs to produce an error message on il­ legal input. Yet, the exact wording - and even the language - of those messages is irrelevant for an understanding of the essence of the system. • A banking application interacts with customers with a graphical interface. Yet the specification of the graphical layout is secondary compared to the specification of the possible transactions.

The Idea of Program Refinement Programs are complex. They are typically so complex, that they go beyond the full comprehension even of the programmer or team who designed them, with all the consequences this has. How can we cope with such complexity in a satisfactory way? An approach, advocated for a long time, is to separate a concise specification of a program - the "what" - from a possibly involved implementation - the "how". Once a specification is obtained from the set of requirements on the program, there can still be a large gap to an efficient implementation. The development from specification to implementation can then proceed by a succession oflayers, such that each layer is a refinement of the previous one. Design decisions can be introduced in refinement steps one at a time. By this, the refinement steps can be kept small and manageable. Still, the set of all requirements can be far too large to be taken completely into account in the initial specification. Even if they could, they might obscure issues more than clarify them. For example: • An information system for stored goods needs to produce an error message on il­ legal input. Yet, the exact wording - and even the language - of those messages is irrelevant for an understanding of the essence of the system. • A banking application interacts with customers with a graphical interface. Yet the specification of the graphical layout is secondary compared to the specification of the possible transactions.

The third in a series of international conferences on Integrated Formal Methods, IFM 2002, was held in Turku, Finland, May 15–17, 2002. Turku, situated in the south western corner of the country, is the former capital of Finland. The ? conference was organized jointly by Abo Akademi University and Turku Centre for Computer Science. The theme of IFM 1999 was the integration of state and behavioral based formalisms. For IFM 2000 this was widened to include all aspects pertaining to the integration of formal methods and formal notations. One of the goals of IFM 2002 was to further investigate these themes. Moreover, IFM 2002 explored the relations between formal methods and graphical notations, especially the industrialstandardlanguageforsoftwaredesign,theUni?edModelingLanguage (UML). The themes of IFM 2002 re?ect what we believe is a growing trend in the Formal Methods and Software Engineering research communities. Over the last threedecades,computerscientistshavedevelopedarangeofformalismsfocusing on particular aspects of behavior or analysis, such as sequential program str- tures,concurrentprogramstructures,dataandinformationstructures,temporal reasoning, deductive proof, and model checking. Much e?ort is now being - voted to integrating these methods in order to combine their advantages and ensure they scale up to industrial needs. Graphical notations are now widely used in software engineering and there is growing recognition of the importance ofprovidingthesewiththeformalunderpinningsandformalanalysiscapabilities found in formal methods.

The Idea of Program Refinement Programs are complex. They are typically so complex, that they go beyond the full comprehension even of the programmer or team who designed them, with all the consequences this has. How can we cope with such complexity in a satisfactory way? An approach, advocated for a long time, is to separate a concise specification of a program - the "what" - from a possibly involved implementation - the "how". Once a specification is obtained from the set of requirements on the program, there can still be a large gap to an efficient implementation. The development from specification to implementation can then proceed by a succession oflayers, such that each layer is a refinement of the previous one. Design decisions can be introduced in refinement steps one at a time. By this, the refinement steps can be kept small and manageable. Still, the set of all requirements can be far too large to be taken completely into account in the initial specification. Even if they could, they might obscure issues more than clarify them. For example: • An information system for stored goods needs to produce an error message on il­ legal input. Yet, the exact wording - and even the language - of those messages is irrelevant for an understanding of the essence of the system. • A banking application interacts with customers with a graphical interface. Yet the specification of the graphical layout is secondary compared to the specification of the possible transactions.

The Idea of Program Refinement Programs are complex. They are typically so complex, that they go beyond the full comprehension even of the programmer or team who designed them, with all the consequences this has. How can we cope with such complexity in a satisfactory way? An approach, advocated for a long time, is to separate a concise specification of a program - the "what" - from a possibly involved implementation - the "how". Once a specification is obtained from the set of requirements on the program, there can still be a large gap to an efficient implementation. The development from specification to implementation can then proceed by a succession oflayers, such that each layer is a refinement of the previous one. Design decisions can be introduced in refinement steps one at a time. By this, the refinement steps can be kept small and manageable. Still, the set of all requirements can be far too large to be taken completely into account in the initial specification. Even if they could, they might obscure issues more than clarify them. For example: • An information system for stored goods needs to produce an error message on il­ legal input. Yet, the exact wording - and even the language - of those messages is irrelevant for an understanding of the essence of the system. • A banking application interacts with customers with a graphical interface. Yet the specification of the graphical layout is secondary compared to the specification of the possible transactions.

The third in a series of international conferences on Integrated Formal Methods, IFM 2002, was held in Turku, Finland, May 15–17, 2002. Turku, situated in the south western corner of the country, is the former capital of Finland. The ? conference was organized jointly by Abo Akademi University and Turku Centre for Computer Science. The theme of IFM 1999 was the integration of state and behavioral based formalisms. For IFM 2000 this was widened to include all aspects pertaining to the integration of formal methods and formal notations. One of the goals of IFM 2002 was to further investigate these themes. Moreover, IFM 2002 explored the relations between formal methods and graphical notations, especially the industrialstandardlanguageforsoftwaredesign,theUni?edModelingLanguage (UML). The themes of IFM 2002 re?ect what we believe is a growing trend in the Formal Methods and Software Engineering research communities. Over the last threedecades,computerscientistshavedevelopedarangeofformalismsfocusing on particular aspects of behavior or analysis, such as sequential program str- tures,concurrentprogramstructures,dataandinformationstructures,temporal reasoning, deductive proof, and model checking. Much e?ort is now being - voted to integrating these methods in order to combine their advantages and ensure they scale up to industrial needs. Graphical notations are now widely used in software engineering and there is growing recognition of the importance ofprovidingthesewiththeformalunderpinningsandformalanalysiscapabilities found in formal methods.