software architecture and the mvc pattern basics for transportation engineers l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Architecture and the MVC Pattern (basics for transportation engineers) PowerPoint Presentation
Download Presentation
Software Architecture and the MVC Pattern (basics for transportation engineers)

Loading in 2 Seconds...

play fullscreen
1 / 20

Software Architecture and the MVC Pattern (basics for transportation engineers) - PowerPoint PPT Presentation


  • 482 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Architecture and the MVC Pattern (basics for transportation engineers)' - omer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software architecture and the mvc pattern basics for transportation engineers

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

Nicolas Kruchten

March 19, 2004

software transportation engineering
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 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
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
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 se6
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
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
Approaches toward this Goal
  • Defined Process
  • Choice of Technology
  • Architecture
  • Naming, Indenting, Commenting
  • Documentation
software architecture
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
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 patterns11
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
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
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
2 Diagrams

Model

View

Controller

Graphs

Glue Code

Database

model view controller
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
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 example17
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
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
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
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’?