Distributed Systems

Data Types: Parnas suggested criteria to be used in decomposing systems into modules IPARN721 Each module should hide design decisions from the other modules of the program. Software Life Cycle: In the years 1972 and 1973 there was increased awareness of total software life IOMLE901. The various activities in software development requirement engineering, design, coding, testing, and maintenance were combined to the conventional life cycle /ROYCE701. 2.1 Milestones in Software Evolution 23 Chief Programmers Team: During this time, management aids for the development process were also proposed. In order to organize the cooperation of program developers during the different phases of the development process, the chief programers team was suggested IBR075/. Programmer teams are structured hierarchically like surgical teams. A chief programmer is responsible for all the work but he is supported by several assistants for documentation, administration, etc. Requirement Specification Techniques: From 1974 to 1977 research concentrated on requirement specification and design techniques in order to improve program reliability. Research activities were based on the assumption that a complete understanding and precise description of the task to be performed would reduce the total development effort. The first formal or semiformal techniques for requirement and design specification were developed IWAR74/, IWAR81/, IJACK75/, ICHEN76/, IROSS77/, IDEMAR79/, IALF77/. A classification of the major techniques of software specification and design can be found in IZAVE901. Chapter 4 in ITHD0901 contains a collection of papers about software specification and design. Software Development Tools: Since then, many attempts have been made to develop tools which support a number of the specification and design techniques described above. These tools help to automate the software development process. A collection of papers describing software engineering tools is contained in chapter 5 of ITHD0901. Computer Aided Software Engineering (CASE): A set of integrated tools which supports many or all software development activities is called a CASE environment /MCCLU89a1. CASE environments often run on personal computers (PC) or workstations (WS). Object Oriented Programming: During the last years, object oriented programming has become a major aspect of software development. There are promising signs that object oriented programmingm will make a major contribution to efficient program development and its reuse IPETE87/. Methods for developing concurrent and distributed software systems have arisen within this general evolutionary path of software enginering. In the sixties, during the construction of large operating systems, new methods for implementing concurrent systems were proposed !HANS73/. In 1965 Dijkstra IDIJK651IDIJK68a1lay the foundation for concurrent systems. He analyzed communication and synchronisation problems in concurrent programs. Subsequently, many communication and synchronisation concepts for concurrent systems were published IDIJK651, !HOARE74/, ICAHA74/, IHANS78/, !HOARE78/. Parallel to the development of these concepts, which are more related 24 2 Software Engineering to programming languages, several attempts were made to describe concurrent systems at a more abstract level IPETRI62/, IKERAS2/, IPETESlI, IREISS2/, /ALF77/, /ALFS5a/, !MILNSO/, /SDU, !ESTELLE!, !LOTOS/. The concepts have been used to define the requirements of concurrent systems and are important for implementing operating systems, process control systems, communication systems, and online information systems. i.i Software Engineering Activities The major software engineering activities are requirement specification, design, and implementation. A specification defines the requirements of a system to be developed; the design describes the components of a system and their purpose; and the program is produced in the implementation. Specification, design, and implementation are intimately interconnected /SWBAS2I.1t is not possible to separate these activities exactly. Alot depends on the circumstances; whether for example the requirement that the final software system must run on a Unix system is considered to be part of the requirement specification or is an implementation issue. If a company follows the strategy that all applications must be developed on a Unix platform then it is part of the requirement specification. Every specification is a design and implementation of some other high level specification. This means that each definition of what is specification, design or implementation is arbitrary. Despite this, the result of all these activities must be a running system: the implementation. The major activities performed in the software development process are described in more detail in this section. The sequence in which these activities are described does not imply that they are executed in that order. They have to be performed whatever the type of program to be developed. They can be based on different development philosophies or concepts and can be supported by a particular tool set. 2.2.1 Software Requirement Engineering In general, requirement engineering is a combination of the analysis of the functions of a special system and their documentation in a requirement specification. Software requirement engineering is concerned with analyzing and documenting the requirements of a software system. The analysis of the needs of a software system involves deciding on the task domain, which tasks have to be performed, which subset of the tasks are to be performed by the system to be developed (the objective). Included in the task domain is the environment of the system to be implemented. After that the requirements of the system to be implemented must be analysed. We can distinguish between functional and nonfunctional requirements /GRCAS5/. The functional requirements describe a model of the solution system. This involves modelling the relevant internal states and the behaviour of the solution system 2.2 Software Engineering Activities 25 and its environment IGRCA851. The solution model serves as a vehicle for communication between customers and developers as well as between developers. Non-functional requirements describe the technical, political, and commercial framework into which the solution system must fit. Examples include the use of a certain database system, hardware system, operating system or programming language. A very important non-functional requirement is that the system to be developed must cooperate with existing software systems. Other non-functional technical requirements might take into consideration portability, interface, performance, and availability constraints. Examples of political non-functional requirements are the use of components from only a certain vendor or the exclusion of components from certain countries, i.e. embargos. The best known commercial non-functional requirement is that the solution must be developed within a given maximum cost. The various requirements are documented in a requirement specification. Different approaches can be applied to the documentation of the results of the requirement analysis in a requirement specification. In IZAVE901 three principal approaches are distinguished: • Natural language specifications These types of specifications are well known and used the most. The requirements are described in natural language. • Operational Specifications An operational model of software requirements can be executed. The description language used in the requirements specification has semantics defined in terms of an execution model. • Mathematical Specifications The semantics of a mathematical specification language is based on a proof system. Proofs are used to validate a requirements specification in order to discover inconsistencies, check completeness, and derive consequences of the specification. In practise requirement specification languages are mostly mixtures of these basic types. Non-functional requirements are usually expressed in natural language. Operational and mathematical requirement specification techniques are mainly restricted to functional requirements. Performance and time constraints can be expressed in some of these requirement specification languages, especially in languages developed to describe communication and process control software systems. 2.2.2 Software Design As already mentioned, the difference between specification and design is not very clear. Different authors consider the same technology either as a requirement specification technology or as a design technology. Sometimes structured analysis (see 26 2 Software Engineering chapter 6) is either considered as a specification technology IPRESS87/, IFAIR851 or a design technology IJON79!, NATS86!. In this book we follow IFAIR85! when defining the different steps of software design, irespective of the design technology used. During the software design process a software solution which meets the software requirements definitions is developed. Designing a software system involves identifying the components (subsystems) and describing the functions of these components. According to IFAIR85!, NATS86! there are three distinct types of design activities: • External design In the external design the observable characteristics of a software system are described. Examples of these characteristics are external behaviour, interfaces, report layouts, data sinks, and data sources. The external design can be considered as the bridge between the requirement analysis and the design activities. This also means that the boundary between specification and external design is very fuzzy. Depending on one's point of view, an activity can be considered as specification or design. • Architectural design In the architectural design, the software system is decomposed into functional parts and internal data objects. These components can be fu