Software engineering in an academic computer science curriculum

This paper illustrates one possibl e way to introduce topics from Softwar e Engineering into an academic Compute r Science Curriculum. The UAB curriculu m in Computer and Information Sciences doe s not contain a course labeled "Softwar e Engineering", but some concepts from thi s field form a natural part of the Operatin g Systems course. This course currentl y uses Madnick and Donovan's text', whic h includes a detailed design of a Sampl e Operating System (SOS). Students in th e course in the Fall of 1974 were asked t o evaluate the SOS kernel from the point o f view of Software Engineering (as expressed by Liskov's rules 2), and to propos e improvements if appropriate. This paper is a composite of th e students' and the instructor's efforts. The paper will first outline Madnic k and Donovan's design and Liskov's rules. Then the design will be reviewed in th e light of Liskov's rules and some possible changes will be proposed. 2. Madnick and Donovan's Sample Operating System (SOS) is a skeleton multi-programming operating system "designe d in a modular and structured manner". SOS is "intended to be a pedagogica l aid to the understanding of th e principles of operating systems". The kernel of SOS provides the basi c functions for process support : sharin g of the system resources among processes , and inter-process communication. The system is implemented as a serie s of levels. The innermost level (level 0) is the hardware, which (as always) respond s to the various hardware instructions. Th e hardware is clothed by several levels o f software, each of which responds to a set of extended instructions. Fo r example, level 2 responds to the extende d instruction "allocate a block of mai n memory space", and to three other extended instructions concerned with memory management. The hierarchical structure of th e system is obtained by imposing the restriction that each successive level depends only on the existence of the level s below it. That is, any given level ma y issue instructions to lower levels, bu t not instructions to higher levels. Wit h this restriction the design and implementation of the system can proceed in a n orderly bottom-up manner. This wa s originally suggested by Dijkstra 3 and ha s been further discussed by Goos 4 and man y others. The desired hierarchical structure …