Software Architecture and the MVC Pattern (basics for transportation engineers)

1. Software Architecture and the MVC Pattern(basics for transportation engineers) Nicolas Kruchten March 19, 2004

2. Software & Transportation Engineering • Software increasingly plays a role in TE • A major product of research here is software: • Models • Simulations • Control Systems • Data Acquisition etc.

3. No Man is an Island • No (useful) code executes in a vacuum • Our code must always interact with something or someone else: • People (users) • Other Software (data acquisition, post-processing) • Hardware (traffic signals)

4. CS & OR vs. SE • The details of how models work or how to solve math problems is largely a CS or OR issue • Software Engineering is concerned with filling the gap between models and programs and the production of complete pieces of software

5. Goals of SE • Not just getting it to work! • What are the goals of transportation engineering? • Mobility, of course, but also Low Cost, Low Impact, Safety, Accessibility, Equity!

6. Goals of SE • It’s the same with software engineering: • the software must work, of course • it must also be maintainable & reusable! • Undoubtedly, someone will want to change your software, or use it to do something else (maybe even you!)

7. Maintainability • ‘Good’ software: • Is readable • Displays ‘single-point-of-maintenance’ • Is documented • Is modular • Is upgradeable or fixable • Can be reused (is generic)

8. Approaches toward this Goal • Defined Process • Choice of Technology • Architecture • Naming, Indenting, Commenting • Documentation

9. Software Architecture • The top-level design of software components • Often related to the choice of technology (language, platform etc) • Data structures, visibility, components, invariants

10. Design Patterns Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience. 

11. Design Patterns “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.” -- Christopher Alexander

12. The I/O Context • No (useful) code executes in a vacuum • There is always an input and an output, and thus there is always some sort of interface • To humans • To software • To hardware

13. The MVC Pattern • In a nutshell: • Keep your model and your view separate! • Model: the data and operations on that data of which your software consists • View: a given way of looking at that data

14. 2 Diagrams Model View Controller Graphs Glue Code Database

15. Model-View-Controller • In the MVC pattern, the model and the view are strictly kept apart from each other • Their interaction is mediated by the controller component: the glue that binds them together • Best illustrated by an example

16. An Example • You’re developing some application and the output you seek is a graph • You build this application, and it works • Your code happens to store the data in the graph, and operates on it there. (So far, so good!)

17. An Example • Another enterprising engineer wants to use your code, but she wants the numbers, not the graph • She must now re-work your code, otherwise her application must include your graphing software, which she doesn’t need!

18. MVC to the rescue! • How the MVC pattern could have helped: • The data and operations (model) would have been stored in one set of components • The graphs (view for a human) would have been in another set of components • She would then have been able to write her own ‘view’, one that her software could use

19. More MVC Goodness • Using the MVC could also help you! • Writing generic views and models lets you mix and match, or change your mind: • Use your graphing code for your next project • Change from line to bar graphs • Tinker with your model without worrying about the graphs

20. Applying the MVC • Experience helps, but these tips might too! • Do the design up-front! • Build the model first, the views later • Look critically at your code, ask yourself ‘can I change the view without changing the model and vice versa’?