design and integration part 2 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Design and Integration: Part 2 PowerPoint Presentation
Download Presentation
Design and Integration: Part 2

Loading in 2 Seconds...

play fullscreen
1 / 18

Design and Integration: Part 2 - PowerPoint PPT Presentation

  • Uploaded on

Design and Integration: Part 2. Plus Delta Feedback. Reading and lecture repeat Ambiguous questions on quizzes Attendance quizzes Boring white lecture slides. From Yesterday – Continuous Integration. What is the corresponding old-school practice for continuous integration?

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

PowerPoint Slideshow about 'Design and Integration: Part 2' - anne-woodward

Download Now 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
plus delta feedback
Plus Delta Feedback
  • Reading and lecture repeat
  • Ambiguous questions on quizzes
  • Attendance quizzes
  • Boring white lecture slides
from yesterday continuous integration
From Yesterday – Continuous Integration
  • What is the corresponding old-school practice for continuous integration?
  • Why is testing (ideally automated testing) so important in continuous integration?
  • When does continuous integration fail?
so how would you integrate this
So - How would you integrate this?

Imagine you’re working with a company that’s building a deployment process. You’ve got several “services” each of which maintains content. The deployment consists of 3 steps:

  • Prepare
  • Deploy
  • Rollback (maybe)

Managed by a “Deployment Manager” (DM) service. Both the services and the DM are under development. The final deployment can’t be tested unless every service has correctly deployed.

Say each service and the DM are developed by a different person. How do you handle integration?

Say each service and the DM are developed by a different team. How would you handle integration?

In groups of 3-5, write down ideas that would reduce the risk of this integration process.

(Building and delivering the DM itself, AND new versions of the services.)

section 1 s ideas
Section 1’s ideas
  • Have a fake place to deploy it to, etc.:
    • Fake the deployment manager (mock it). Or,
    • Fake the services.
      • Getting one to fail is tricky. Like, sending garbage data.
  • Make a big fancy spec document.
    • Provides visibility.
  • Find a way to build it piecemeal.
    • Do something serially.
    • How do you test the DM if there’s nothing to deploy?
related tips build repeatability
Related tips - Build repeatability
  • Crucial for continuous integration
    • Requires that multiple people know how to build, and
    • You can avoid subtle bugs
  • Can you “build any version” as you come out with new ones?
    • E.g., existing features customers are using
      • How to patch these?
      • They used an old version of the operating system
related to continuous integration
Related to continuous integration
  • Continuous delivery
  • Harder
  • Typical desired scenario
    • Code – build – test today
    • Deliver tonight
  • Gives you a continuous flow of features to your customers
  • Works a lot better with SOA’s
opportunistic refactoring
Opportunistic Refactoring
  • What do you refactor your code to do?
    • Rule 1: Enable whatever you know best comes next!
    • Rule 2: Make your code easy to use:
      • Reduce duplication
      • Be more explanatory (note: agile equivalent of documentation here)
      • Improve the “smell”
      • Improve the design is of course the goal, but this can be a tricky business

We’ll have a full look at refactoring in CSSE 375…

phillips a strategic quote
Phillips: A strategic quote

There are morale issues. Many creative people are offering solutions or parts of solutions, yet the business may be dictating significant design parameters such as language, operating system, hardware, and user interface.


Another frustration of design is that sinking feeling that you are reinventing the wheel. The current design is similar to the design of last year’s project. It is just different enough to cause us to repeat the entire design process. If only we had made the last design more general-purpose.

“Let’s make a better one of these…”

old school design
“Old school” Design

Some other key thoughts from Phillips:

  • Design is about finding foresight with the same 20/20 vision as hindsight. (p 259)
  • Design is a visibility technique and a visibility product.
    • It’s both a process and an artifact. (p 259)
  • It’s creating many solutions to a problem, then choosing one according to a set of criteria,
    • And then socializing that solution. (p 260)
more phillips
More Phillips
  • Some people do not make good designers because they cannot work with design’s sloppy nature.
    • Iteration is one way to work through design frustration. (p 261)
  • Find at least 3 major deficiencies in your first design.
    • If you can’t find them, have someone else take a look. (p 261)
and more
And more
  • Designing without abstraction leads to failure. (p 262)
  • Most customers are tired of developers after the grueling requirements activities. (p 264)
  • Writing requirements in English only is a mistake. (p 265)
  • Loose coupling means that the implementation of one unit does not depend on the implementation of another. (p 265)
    • Decoupling is often “social.”
  • The most common design secrets to hide are items that have a high probability of changing. (p 266)
  • The most important step in designing for reuse is to decide to design for reuse. (p 267)
  • The first step in evaluating design decisions is to base those decisions on criteria you selected ahead of time. (p 268)
why talk about design now
Why talk about design now?
  • You’ll get this, in depth, in 374 and 477!
  • Had bits and pieces in every CSSE class.
  • Don’t say:
  • Because it’s theheart of creatingsoftware.
  • You need the big picture of software projects.
    • This is the course where you get it.
  • And – You have to do design and planning how to run the project, at the same time.
    • Like, who you need on the project depends on:
    • What skills you need to pull it off, which
    • Depends on the design.
the standard design sequence
The standard design sequence

In all of engineering, it goes like this.

  • You at least need a good problem statement.
    • It should cover functional and non-functional requirements in generality.
  • You do the high-level design from that.
    • Top-down, with lots of alternatives.
    • Then pick from those, based on lots of criteria.
    • This is Phillips’ “Abstraction” (p 262)
  • Then you use the detailed requirements to fill-in the detailed design.
    • Bottom-up.
    • Do you need to express this, beyond coding?



high level design looks like good brainstorming
High-level design looks like good brainstorming
  • Try not to mix these two:
    • Coming up with new ideas.
    • Picking one, and focusing on how to do it well.
  • But,
    • For everything beyond coding, you have to maintain it forever!
    • So – Is it throwaway?