CSC 321.01, Class 07: An introduction to software engineering
- Notes and news
- Upcoming work
- Model/View/Controller frameworks
- RESTful programming
- Models of software engineering
- Important agile practices
- Why agile?
- Why not agile?
News / Etc.
- Why are students missing? Bad students! No coffee.
Good things to do
Nope, no extra credit.
- CS Table, Tuesday, 7 Feb 2017. Something on privacy.
- Scholars Convocation, Thursday, 9 Feb 2017, 11:00 a.m., JRC 101. David Orr: Climate Change and the Crisis of American Democracy.
- Thursday extras, Thursday, 9 Feb 2017, 4:15 p.m., Science 3821: Something on computer graphics (visitor from UMN).
- Software designers have tried to develop/document standard “designs” that work well for many situations.
- Model/view/controller is one of the most successful designs;
modularizes many traditional interactive programs into three
separate modules with a somewaht standand interface between them.
- Modularization helps us isolate errors.
- Can help with DRYness
- May help with reusability.
- Makes it easier to segment the work.
- We can use different views with the same model
- Model: Describes the data
- Controller: Describes changes to the data
- View: Shows the data
- In Rails, when you say “I’m working with this kind of data”, you’ll get a model, a view (.erb), and a controller.
- Modern Web: Applications get data from everywhere.
- Old Internet: Everyone had their own protocol for how to request and format data.
- People started developing common ways to request data.
- REST leverages existing Web formats, protocols, and ports to simplify the request and transmission of data.
- REST uses http as the primary protocol. So we can send
GET+ URL + data
POST+ URL + data
DELETE+ URL + data
- REST tends to use four formats for returning values
- XML - Generalized markup language
- CSV - comma-separated values
- TXT - anything goes
- REST is supposed to be stateless.
- Makes it easier to shift requests around; can be somewhat harder for the server to implement.
- REST is a series of practices/expectations layered on top of HTTP.
- A lot of the work for REST is available through libraries or toolkits.
- Keeping track of state is perhaps the hardest thing that sometimes ha to be customized.
- HTTP transactions are not encrypted. Anyone looking at the packets can
figure out what is being sent.
- Hypertext transfer protocol
- HTTPS is a moderately well encrypted format. The NSA can tell what is
being sent, because they undermined the protocol, but most people cannot.
- Hypertext transfer protocol, supposedly secure
- Protocol is a series of rules that govern a transaction.
Models of software engineering
Three models of software engineering
- Plan and document
- Waterfall - everything flows downhill
Talk to your neighbor: Similarities, differences.
- All of these methodologies have a similar sequence of steps
- Gather requirements from clients
- Verify requirements
- Design architecture
- However, they have very different numbers of iterations and iteration
- Waterfall - One iteration, often multiple years
- Spiral - Multiple iterations (usually about four), a few months
- Agile - As many iterations as necessary, one or two weeks
- Different models of specifying requirements
- More formal for waterfall
- Less formal for agile
- Agile is used a lot these days
Important agile practices
Agile is a group of practices that work together to help ensure that we build good software while using the “short iterations” model.
What do you see as the most important agile practices?
- Use customer stories as documentation / tasks / issues.
- Helps us ensure that we are building the product our users want, rather than the product we think our users want (or that our pointy-haired bosses think our users want)
- Focus on the task at hand, rather than a long-term picture.
- History suggests that what users think they want at the beginning of the project is not what they realize they want at the end.
- History suggests that program designs that sound good at the beginning may not be so good at the end.
- User stories are the tasks at hand.
- Frequent iterations, with prototypes.
- “Sprint” == “Iteration” == “…”
- Not all features available.
- Lets user see what’s done, think about what’s important
- Helps build user stories
- Test-driven design
- Makes it easier to add or change code and tell whether you’ve broken something
- Documents requirements
- Smaller teams
- Easier to collaborate
- Perhaps less need for documentation
- Supports communication
- Enable frequent meetings
- Frequent meetings
- With team - keeps you on track
- With client - keeps you on track
- Pair programming
- Make friends
- Catches errors more quickly
- Evidence suggests that pairs are more productive: More code, fewer bugs.
- Share knowledge, practices, etc.
- Provides continuous code review
- Track velocity
- Know how much you are producing
- Know how much you can produce
- Helps plan each cycle
- Helps with communications with client
- Start simple
- Don’t waste too much time on something that may be thrown away
- Lets you get prototypes out more quickly
- Ruthlessly refactor
- Rewrite bad code when it crops up.
Why do our authors (and others) promote agile approaches?
Why not agile?
Why might critics not like agile approaches?