Design We know WHAT the system should do. Before 14 developers start coding… How do we decide HOW the pieces fit together? Design gives the team a shared blueprint. 2 3 Tasks
small working system more capability fuller product A skateboard is not 25% of a car Our first design should give every important capability a place to grow —without building everything now. 4
send(message) receive(message) «interface» CommunicationService MockCommunication send(message) receive() «interface» MessageRepository save(message) findAll() Enough to implement and test core messaging without services (such as AWS), a database, robots, etc. 5 6 InMemoryRepository
what a 'service' DOES—not on one technology. «interface» CommunicationService send(Message) MockCommunicationService Sprint 1 Later Same contract 6 7 MqttCommunicationService Different implementations
real code Given communication succeeds When send(message) Then result is success Real MQTT not required yet Good design lets us test one responsibility without requiring the entire real system. TDD and provided test assets come later. 10 10 CSC 3100 • Software Design
something? • What needs to DO something? • What information needs to EXIST? • Which responsibilities belong together? • Which dependencies should be interfaces? • What can we mock today? • Can we trace every design element back to a requirement? 11 11 CSC 3100 • Software Design
niz tion of system in terms of ) the p rts (items, elements, components) th t m ke up th t system nd b) their rel tionships. a a a a a a a a a a a 17 a a Structural models
sses in system • modi iers • Attributes • methods And the rel tionships between these cl sses: • Associ tion / Dependency • Aggreg tion / Composition • Gener liz tion / Speci liz tion / Re liz tion a a a a a a a a a a a a a a f a 19
Copyright. These slides may be used only as study material for CSC 5100 within the California State University system. They may not be distributed or used for any other purpose.