joshbloch / /charliegarrod&charlie/courses/15-214/2016-spring/slides/01-introduction.pdf15214 18...

1 15-‐214

School of Computer Science

Principles of So3ware Construc9on: Objects, Design, and Concurrency Part 1: Introduc9on Course overview and introduc9on to so3ware design Josh Bloch Charlie Garrod

2 15-‐214

Growth of code—and complexity—over 9me

(informal reports)

3 15-‐214 15-313 Software Engineering 3

4 15-‐214

Blackout of 2003 Normal night-time image

5 15-‐214



6 15-‐214

binary tree

graph search

sorting

BDDs

primes

GCD

7 15-‐214

Our goal: understanding both the building blocks and also the design principles for construction of software systems at scale

From programs to systems

Wri9ng algorithms, data structures from scratch

Func9ons with inputs

and outputs Sequen9al and local

computa9on

Full func9onal specifica9ons

Reuse of libraries, frameworks

Asynchronous and reac9ve designs

Parallel and distributed

computa9on Par9al, composable,

targeted models

8 15-‐214



9 15-‐214

Objects in the real world

10 15-‐214

Object-‐oriented programming

•  Programming based on structures that contain both data and methods

public class Bicycle { private int speed; private final Wheel frontWheel, rearWheel; private final Seat seat; … public Bicycle(…) { … } public void accelerate() { speed++; } public int getSpeed() { return speed; } }

11 15-‐214



12 15-‐214

Semester overview

•  Introduc9on –  Design goals, principles, paSerns

•  Designing classes –  Design for change: Subtype polymorphism

and informa9on hiding –  Design for reuse: inheritance and delega9on

•  Designing (sub)systems –  What to build: Domain models, system

sequence diagrams –  Assigning responsibili9es: GRASP paSerns –  Design for robustness: Excep9ons, modular

protec9on –  Design for change (2): Façade, Adapter,

Observer •  Design case studies

–  Graphical user interfaces –  Streams, I/O –  Collec9ons

•  Design for large-‐scale reuse –  Libraries, APIs, –  Frameworks –  Product lines

•  Explicit concurrency •  Distributed systems

•  CrosscuZng topics: –  Modern development tools: IDEs, version

control, build automa9on, con9nuous integra9on, sta9c analysis

–  Modeling and specifica9on, formal and informal

–  Func9onal correctness: Tes9ng, sta9c analysis, verifica9on

13 15-‐214

Sorting with a configurable order, version A

void sort(int[] list, boolean ascending) { … boolean mustSwap; if (ascending) { mustSwap = list[i] < list[j]; } else { mustSwap = list[i] > list[j]; } … }

14 15-‐214

Sorting with a configurable order, version B interface Comparator { boolean compare(int i, int j); } class AscendingComparator implements Comparator { boolean compare(int i, int j) { return i < j; } } class DescendingComparator implements Comparator { boolean compare(int i, int j) { return i > j; } } void sort(int[] list, Comparator cmp) { … boolean mustSwap = cmp.compare(list[i], list[j]); … }

15 15-‐214

Sorting with a configurable order, version B'

interface Comparator { boolean compare(int i, int j); } final Comparator ASCENDING = (i, j) -‐> i < j; final Comparator DESCENDING = (i, j) -‐> i > j; void sort(int[] list, Comparator cmp) { … boolean mustSwap = cmp.compare(list[i], list[j]); … }

16 15-‐214

Which version is better?

void sort(int[] list, boolean ascending) { … boolean mustSwap; if (ascending) { mustSwap = list[i] < list[j]; } else { mustSwap = list[i] > list[j]; } … }

interface Comparator { boolean compare(int i, int j); } final Comparator ASCENDING = (i, j) -‐> i < j; final Comparator DESCENDING = (i, j) -‐> i > j; void sort(int[] list, Comparator cmp) { … boolean mustSwap = cmp.compare(list[i], list[j]); … }

Version A:

Version B':

17 15-‐214

It depends?

18 15-‐214

Software engineering is the branch of computer science that creates practical, cost-effective solutions to computing and information processing problems, preferably by applying scientific knowledge, developing software systems in the service of mankind. Software engineering entails making decisions under constraints of limited time, knowledge, and resources. […]

Engineering quality resides in engineering judgment. […] Quality of the software product depends on the engineer’s faithfulness to the engineered artifact. […] Engineering requires reconciling conflicting constraints. […] Engineering skills improve as a result of careful systematic reflection on experience. […] Costs and time constraints matter, not just capability. […]

Software Engineering for the 21st Century: A basis for rethinking the curriculum

Manifesto, CMU-ISRI-05-108

19 15-‐214

So3ware Engineering (SE) at CMU

•  15-‐214: Code-‐level design –  Extensibility, reuse, concurrency, func9onal correctness

•  15-‐313: Human aspects of so3ware development –  Requirements, teamwork, scalability, security, scheduling, costs, risks,

business models

•  15-‐413 Prac9cum, 17-‐413 Seminar, Internship •  Various Master's level courses on requirements, architecture,

so3ware analysis, etc. •  SE Minor: hSp://isri.cmu.edu/educa9on/undergrad

19

20 15-‐214



21 15-‐214

Concurrency

•  Simply: doing more than one thing at a 9me

22 15-‐214

Semester overview

•  Introduc9on –  Design goals, principles, paSerns

•  Designing classes –  Design for change: Subtype polymorphism

and informa9on hiding –  Design for reuse: inheritance and delega9on

•  Designing (sub)systems –  What to build: Domain models, system

sequence diagrams –  Assigning responsibili9es: GRASP paSerns –  Design for robustness: Excep9ons, modular

protec9on –  Design for change (2): Façade, Adapter,

Observer •  Design case studies

–  Graphical user interfaces –  Streams, I/O –  Collec9ons

•  Design for large-‐scale reuse –  Libraries, APIs, –  Frameworks –  Product lines

•  Explicit concurrency •  Distributed systems

•  CrosscuZng topics: –  Modern development tools: IDEs, version

control, build automa9on, con9nuous integra9on, sta9c analysis

–  Modeling and specifica9on, formal and informal

–  Func9onal correctness: Tes9ng, sta9c analysis, verifica9on

23 15-‐214

Summary: Course themes

•  Object-‐oriented programming •  Code-‐level design •  Analysis and modeling •  Concurrency and distributed systems

24 15-‐214

COURSE ORGANIZATION

25 15-‐214

Precondi9ons

•  15-‐122 or equivalent –  Two semesters of programming –  Knowledge of C-‐like languages

•  Specifically: –  Basic programming skills –  Basic (formal) reasoning about programs

•  Pre/post condi9ons, invariants, formal verifica9on –  Basic algorithms and data structures

•  Lists, graphs, sor9ng, binary search, etc.

26 15-‐214

Learning goals

•  Ability to design medium-‐scale programs –  Design goals (e.g., design for change, design for reuse) –  Design principles (e.g., low coupling, explicit interfaces) –  Design paSerns (e.g., strategy paSern, decorator paSern), libraries, and frameworks –  Evalua9ng trade-‐offs within a design space –  Paradigms such as event-‐driven GUI programming

•  Understanding OO programming concepts & how they support design decisions –  Polymorphism, encapsula9on, inheritance, object iden9ty

•  Proficiency with basic quality assurance techniques for func9onal correctness –  Unit tes9ng –  Sta9c analysis –  (Verifica9on)

•  Fundamentals of concurrency and distributed systems •  Prac9cal skills

–  Ability to write medium-‐scale programs in Java –  Ability to use modern development tools

•  VCS, IDE, debugger, build and test automa9on, sta9c analysis, …

27 15-‐214

Course staff

•  Josh Bloch [email protected] Wean 4213

•  Charlie Garrod [email protected] Wean 5101

•  Teaching assistants: Jacob, Jordan, Kathleen, Kirn, Marcel, Nora, Reid, Tianyu

28 15-‐214

Course mee9ngs

•  Lectures: Tuesday and Thursday 3:00 – 4:20pm WEH 7500 •  Recita9ons: Wednesdays 9:30 -‐ … -‐ 2:20pm

–  Supplementary material, hands-‐on prac9ce, feedback

•  Office hours: see course web page –  hSps://www.cs.cmu.edu/~charlie/courses/15-‐214/

Recitation attendance is required

29 15-‐214

Infrastructure

•  Course website hSp://www.cs.cmu.edu/~charlie/courses/15-‐214 –  Schedule, assignments, lecture slides, policy documents

•  Tools –  Git, Github: Assignment distribu9on, hand-‐in, and grades –  Piazza: Discussion board –  Eclipse: Recommended for code development –  Gradle, Travis-‐CI, Checkstyle, Findbugs: Prac9cal development tools

•  Assignments –  Homework 1 available tomorrow in recita9on

•  Ensure all tools work together: Git, Java, Eclipse, Gradle, Checkstyle •  First recita9on is tomorrow

–  Introduc9on to Java and the tools in the course –  Bring your laptop, if you have one! –  Install Git, Java, Eclipse, Gradle beforehand

30 15-‐214

Textbooks

•  Required course textbook: –  Craig Larman. Applying UML and PaSerns: An Introduc9on

to Object-‐Oriented Analysis and Design and Itera9ve Development. 3rd Edi9on. Pren9ce Hall. 2004. ISBN 0-‐13-‐148906-‐2

–  Read chapters 14 and 16 by next Tuesday

•  Addi9onal texts on Java, concurrency, and design paSerns recommended on the course web page

31 15-‐214

Grading policy (subject to change)

•  50% assignments •  20% midterms (2 x 10% each) •  20% final exam •  10% quizzes and par9cipa9on

–  Bring paper and a pen/pencil to class!

This course does not have a fixed leSer grade policy; i.e., the final leSer grades will not be A=90-‐100%, B=80-‐90%, etc.

32 15-‐214

Collabora9on policy (also on course web page)

•  We expect your work to be your own –  You must clearly cite external resources so that we can evaluate your own

personal contribu9ons.

•  Do not release your solu9ons (not even a3er end of semester) •  Ask if you have any ques9ons •  If you are feeling desperate, please mail/call/talk to us

–  Always turn in any work you've completed before the deadline

•  We use chea9ng detec9on tools

33 15-‐214

Late day policy

•  You may turn in each* homework up to 2 days late –  5 free late days per semester –  10% penalty per day a3er free late days are used

•  …but we don't accept work 3 days late •  See the syllabus for addi9onal details

34 15-‐214

10% quizzes and par9cipa9on

•  Recita9on par9cipa9on counts toward your par9cipa9on grade •  Lecture has in-‐class quizzes and faux par9cipa9on quizzes

35 15-‐214

INTRODUCTION TO SOFTWARE DESIGN

36 15-‐214

Goal of so3ware design

•  For each desired program behavior there are infinitely many programs –  What are the differences between the variants? –  Which variant should we choose? –  How can we synthesize a variant with desired proper9es?

37 15-‐214

Metrics of so3ware quality

•  Sufficiency / func9onal correctness §  Fails to implement the specifica9ons … Sa9sfies all of the specifica9ons

•  Robustness §  Will crash on any anomalous even … Recovers from all anomalous events

•  Flexibility §  Will have to be replaced en9rely if specifica9on changes … Easily adaptable to reasonable changes

•  Reusability §  Cannot be used in another applica9on … Usable in all reasonably related apps without modifica9on

•  Efficiency §  Fails to sa9sfy speed or data storage requirement … sa9sfies requirement with reasonable margin

•  Scalability §  Cannot be used as the basis of a larger version … is an outstanding basis…

•  Security §  Security not accounted for at all … No manner of breaching security is known

Source: Braude, Bernstein, Software Engineering. Wiley 2011

Design challenges/goals

38 15-‐214

Why use a design process?

•  A design process organizes your work •  A design process structures your understanding •  A design process facilitates communica9on

39 15-‐214

One simple process

1.  Discuss so3ware that needs to be wriSen 2.  Write some code 3.  Test the code to iden9fy the defects 4.  Debug to find causes of defects 5.  Fix the defects 6.  If not done, return to step 1

40 15-‐214

BeSer so3ware design

•  Think before coding •  Consider non-‐func9onal quality aSributes

–  Maintainability, extensibility, performance, …

•  Consider design alterna9ves –  Make conscious design decisions

41 15-‐214

A design case study: Simula9ng an invasive species

Photo by Walter Siegmund

Source: BC Forestry website

Lodgepole Pine Mountain Pine Beetle Galleries carved in inner bark

Widespread tree death

Further reading: Liliana Péreza and Suzana Dragićević. Exploring Forest Management Prac9ces Using an Agent-‐Based Model of Forest Insect Infesta9ons. Interna9onal Congress on Environmental Modelling and So3ware Modelling for Environment’s Sake, 2010.

42 15-‐214

Real-‐world goal: Determine how best to save the trees

•  Causes of the problem –  Warmer winters: fewer beetles die –  Fire suppression: more old (suscep9ble) trees

•  Can management help? What form(s)? –  Sanita9on harvest

•  Remove highly infested trees •  Remove healthy neighboring trees above a certain size

–  Salvage harvest •  Remove healthy trees with several infested neighbors


43 15-‐214

Applying agent-‐based modeling

•  Goal: evaluate different forest management techniques –  Use a simulated forest based on real scien9fic observa9ons

•  An agent-‐based model –  Create a simulated forest, divided into a grid –  Populate the forest with agents: trees, beetles, forest managers –  Simulate the agents over mul9ple 9me steps –  Calibrate the model to match observa9ons –  Compare tree survival in different management strategies

•  and vs. no management at all


44 15-‐214 44 Further reading: Liliana Péreza and Suzana Dragićević. Exploring Forest Management Prac9ces Using an Agent-‐Based Model of Forest Insect Infesta9ons. Interna9onal Congress on Environmental Modelling and So3ware Modelling for Environment’s Sake, 2010.

45 15-‐214 45 Further reading: Liliana Péreza and Suzana Dragićević. Exploring Forest Management Prac9ces Using an Agent-‐Based Model of Forest Insect Infesta9ons. Interna9onal Congress on Environmental Modelling and So3ware Modelling for Environment’s Sake, 2010.

46 15-‐214

A design problem (Version 1: Talk amongst yourselves)

•  How should we organize our simula9on code? •  Goals:

–  Separate simula9on infrastructure from problem-‐specific details •  May want to reuse infrastructure in other studies •  Allows mul9ple developers to work in parallel

–  Make it easy to change the simula9on setup •  May need to adjust parameters before geZng it right

–  Make it easy to add and remove problem-‐specific details •  New elements may be needed for accurate simula9on

47 15-‐214

A design problem (Version 2: Write your design on paper)

•  How should we organize our simula9on code? •  Goals:

–  Separate simula9on infrastructure from problem-‐specific details •  May want to reuse infrastructure in other studies •  Allows mul9ple developers to work in parallel

–  Make it easy to change the simula9on setup •  May need to adjust parameters before geZng it right

–  Make it easy to add and remove problem-‐specific details •  New elements may be needed for accurate simula9on

48 15-‐214

Common problems

•  “I don’t even know how to start” –  This course will help:

•  A process for design •  Design paEerns that you can apply •  Principles for selecFng among design alterna9ves •  Techniques for documenFng design for others

•  “Is my design any good?” •  “You can’t solve problem in C / without OO!”

49 15-‐214

Preview: Design goals, principles, and paSerns

•  Design goals enable evalua9on of designs –  e.g. maintainability, reusability, scalability

•  Design principles are heuris9cs that describe best prac9ces –  e.g. high correspondence to real-‐world concepts

•  Design pa3erns codify repeated experiences, common solu9ons –  e.g. template method paSern

50 15-‐214

Preview: The design process

•  Object-‐oriented analysis –  Understand the problem

•  Object-‐oriented design –  Cheaply create and evaluate plausible alterna9ves

•  Implementa9on –  Convert design to code

51 15-‐214

Summary: Design and objects

•  Design follows a process –  Structuring design helps us do it beSer

•  Quality aSributes drive so3ware design –  Proper9es that describe fitness for further development and use

joshbloch / /charliegarrod&charlie/courses/15-214/2016-spring/slides/01-introduction.pdf15214 18...

Documents