150 likes | 276 Vues
This guide explores the programming of large object-oriented systems, presenting key tools, techniques, architecture patterns, and frameworks essential for diploma and forthcoming master students. Focusing on practical applications through a case study of a pay station, it emphasizes best practices such as test-driven development (TDD), continual refactoring, and maintaining clean production code. Students will learn to navigate the complexities of software design, enabling them to implement reliable and efficient systems while gaining hands-on experience on a manageable scale.
E N D
PaSOOS Programming of Large Object-Oriented Systems Henrik Bærbak Christensen
PaSOOS • PaSOOS • Three pieces • Værktøjer og teknikker (ToolTech) • Arkitektur, Patterns og Frameworks (APF) • Programmeringsprojekt (ProgProj) • Audience • Diploma Students • Forthcoming Master Students Henrik Bærbak Christensen
PaSOOS • ToolTech • Focus on the supporting techniques for large systems • APF • Focus on the architecture and design of large systems (or at least some of it) • ProgProj • Try it out on a (small ) large system Henrik Bærbak Christensen
Experience from Exam • Oral presentation Henrik Bærbak Christensen
Literature • Primary literature • Reliable and Flexible Software Explained (RFSE) • Work in progress... • Cheap! • Comments most welcome! • Compendium • Extracts from various books • Electronic material • Papers etc. posted on the web site. Henrik Bærbak Christensen
RFSE Recurring Case: Pay Station Introduction to case study
Case: Pay Station • Customer – Alphatown county: • The pay station must: • accept coins for payment • show time bought • print parking time receipts • US: 2 minutes cost 5 cent • handle buy and cancel • maintenance (empty it)
TDD • Test-driven development of the pay station • The values • small steps, keep focus • The rhythm • quickly add test, red, add production code, green, refactor • Patterns • test list, test first, test • fake it till you make it (keep focus, small steps) + triangulate • isolated test, evident test, evident data • break, do over
Next... • What I will do the next couple of weeks is to: • throw all sorts of new requirements at it • keep the production code ‘clean’ by refactoring • analyze my options carefully before committing to design • make it a pay station framework that is pretty configurable... • and derive a lot of design patterns as I go...