Loading in 2 Seconds...
Loading in 2 Seconds...
Software Architecture and the MVC Pattern(basics for transportation engineers) Nicolas Kruchten March 19, 2004
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.
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)
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
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!
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!)
Maintainability • ‘Good’ software: • Is readable • Displays ‘single-point-of-maintenance’ • Is documented • Is modular • Is upgradeable or fixable • Can be reused (is generic)
Approaches toward this Goal • Defined Process • Choice of Technology • Architecture • Naming, Indenting, Commenting • Documentation
Software Architecture • The top-level design of software components • Often related to the choice of technology (language, platform etc) • Data structures, visibility, components, invariants
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.
Design Patterns “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.” -- Christopher Alexander
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
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
2 Diagrams Model View Controller Graphs Glue Code Database
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
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!)
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!
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
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
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’?