Skip to content

Home

Jump to bottom
Tijs van der Storm edited this page Jan 27, 2014 · 28 revisions

Software Construction 2013-2014

Introduction

This page covers all relevant information concerning the course Software Construction 2013-2014 in the Master Software Engineering, University of Amsterdam.

Schedule

Lectures and workshops will be from 9:00-11:00 on Wednesday. Lectures will be given by Tijs van der Storm and. Practical course will be on Wednesday from 11:00 to 17:00 and Thursdays the whole day. For details about rooms see datanose.nl. An iCal ICS link can be found here: https://datanose.nl/course_15520.ics.

Primary contact for this course is Tijs van der Storm.

NB We will actively use Twitter during this course. Please make an account if you haven't already, and start following @SoftwCons!

Schedule

  • Week 06: Introduction + Term Frequency coding
  • Week 07: Lecture Grammars and Parsing + Parser generators
  • Week 08: Lecture Domain-Specific Languages + Finding DSLs
  • Week 09: Language Engineering
  • Week 10: Code Quality:
  • Week 11: Lecture Interpreters
  • Week 12: Code Smells

Workshop hours

  • Term frequency coding sprint (+ github setup)

  • Finding Parser generators

  • TDD Term Frequency (did your program change?)

  • Object Calisthenics Term Frequency

  • Chasing trade-offs: find papers on DSLs and trade-offs

  • Code smell hunting (Cross Code Reading)

  • Top Refactorings: google refactorings, apply on your own code. Refactoring game

  • Debugging

How to pass this course

Required skills:

  • Create good low level designs
  • Produce clean, readable code
  • Reflect upon and argue for/against software construction techniques, patterns, guidelines etc.
  • Assess the quality of code.
  • Select and apply state of the art software construction tools and frameworks.

Required knowledge:

  • Understand basic principles of language implementation (parsing, AST, evaluation, generation)
  • Understand basic aspects of code quality (readability, changeability, extensibility, etc.)
  • Understand encapsulation and modular design

How to pass this course:

  • Be present at all lectures.
  • Get a grade for your code > 5.5
  • Complete the reading assignments (pass/fail)

Knowledge of and able to apply:

  • Objects and classes
  • Higher-order functions
  • Code generators
  • Hierarchy
  • Design patterns
  • Contracts
  • Unit-tests
  • Refactoring

Required reading

The literature for this course consists of:

  • "Exercises in Programming Style" (Parts I-IV, VI) by Crista Lopes
  • Papers in the Syllabus

The papers will help you improve your programming practice. You are expected to be familiar with them and apply the techniques where meaningful.

Reading assignments

The ReadingAssignments use the examples in the Styles book to test your understanding of the papers in the Syllabus.

Lab assignment: QL, a DSL for Questionnaires

The lab assignment is based on the Language Workbench Challenge 2013 (LWC'13). The goal of that assignment is to build a DSL for questionnaires (called QL): simple forms with conditions and computed values. See this document for more information.

Check list of required features that you will show that work during grading:

  • Questions are enabled and disabled when different values are entered.

  • The type checker detects:

    • reference to undefined questions
    • duplicate question declarations with different types
    • conditions that are not of the type boolean
    • operands of invalid type to operators
    • references to questions with an undefined value
    • cyclic dependencies between questions
    • duplicate labels (warning)

  • The language supports booleans, integers and string values.

  • Different data types in QL map to different GUI widgets.

Requirements on the implementation:

  • The parser of the DSL is implemented using a grammar-based parser generator.

  • The internal structure of a DSL program is represented using abstract syntax trees.

  • QL programs are executed as GUI programs, not command-line dialogues.

  • QL programs are executed by interpretation, not code generation.

You are encouraged to be creative in terms of libraries or frameworks that you use, but be aware of impending bloat and or a huge number of dependency (all in good measure).

As to programming language, you may choose any of the following languages: Java, C#, Javascript, Haskell, Scala, Clojure, Erlang, Smalltalk, Ruby, Python, Go, Dart. Feel free to take the opportunity to learn a new language, but be aware that your code will be graded as if you're proficient in it and aware of idiomatic coding styles. For Java we provide grammar skeleton code for the parser generators ANTLR, Jacc and Rats! These grammars are incomplete. You may copy one of the skeleton projects and complete it by adding the following features:

  • Syntax for booleans, string literals. Don't forget to take care of keyword reservation: true and false should be parsed as boolean literals, not as identifiers.

  • Add single-line comments (a la Java: //).

  • Add syntax productions for forms, questions, computed quetsions, types (int, bool, and string) and if-then and if-then-else statements. Use string literals for question labels. See the LWC'13 link above for an example questionnaire.

  • Add tests to check your syntax extensions.

  • Add AST classes for the provided expression categories, and for you syntactic extensions. Make sure the parser creates objects of the appropriate type.

  • Change the start symbol of the parser to parse forms, instead of Expressions.

Note: don't be seduced by the provided example code and start copy-pasting grammar rules around. It is important to have a basic understanding of the parser technology involved. ANTLR, Rats! and Jacc are well-documented on the web. Please use this information to fulfill the above requirements.

Honor's track

Object Algebras

Use object algebras to make an extensible implementation. Show that it works by developing a number of language extensions (e.g., unless, repeat, date time values etc.), and operations: pretty print, compile.

Direct manipulation

Spreadsheet like interface DSL (but parse expressions) Make it direct manipulation and live (like spreadsheet). Note: need separate run mode too.

Time table for the the lab assignment

There are two grading moments of the lab assignment (see above) which correspond to parts of the assignment:

  • Part 1 (Front end): the frontend covers all aspects visible to the users of the DSL: parsing, checking, and in case of the Rascal variants, IDE support.

  • Part 2 (Back end): the back end includes are aspects related to running QL programs. In the Java variant this is the interpreter, in the Rascal variants this is the compiler/codegenerator.

What we look for when grading your code

The following aspects of quality code will be our focus when grading your code:

  • Functionality (e.g., are the requirements implemented)
  • Tests (e.g., presence of meaningful unit tests)
  • Simplicity (absence of code bloat and complexity; YAGNI)
  • Modularity (e.g., encapsulation, class dependencies, package structure)
  • Layout and style (indentation, comments, naming of variables etc.)
  • SOLID principles
  • Sensible (non-)use of design patterns (e.g., Visitor)

More concretely, we ask you to take the following list of advice into consideration.

  • Code quality is of the utmost importance in this course. You will write clean, consistently formatted, concise code. Your naming and indentation convention will be consistent.

  • You show that you master the concepts of encapsulation, modularity and separation of concerns. This should be visible from the code. The structure of the code should show the design.

  • Method and functions should realize a single piece of functionality. You adhere to the Don't Repeat Yourself (DRY) principle.

  • You will select tools and libraries wisely. You can argue why you chose to use a particular artifact.

  • You know your (standard) libraries and APIs. Do not reimplement (simple) functions that can be expected to be in a (standard) library. Especially, do not claim that your version is faster, because: it is irrelevant, and, you're probably wrong. Make the trade-off for reusing a library: do you really need a heavy dependency, for some simple functionality?

  • Test your code using unit tests if this is meaningful. Do not write tests, because your are somehow supposed to. Do not write your own testing framework; use appropriate libraries and/or language features of the platform (e.g., JUnit on Java). Separate test code from main code.

  • Use asserts in the correct way. Asserts are used to document and check assumptions. They are not used for input validation or error handling.

  • Use exception handling wisely. Do not implement your Exception class in a situation where a standard library exception makes perfect sense. Handle exceptions sanely, if possible. Empty catch-blocks are unacceptable 99.9% of the time.

  • Non-constant static variables should be avoided at all cost.

  • If you are forced to need instanceof a lot, you probably have a flaw in your design.

  • You are expected not to indulge in elaborate gold plating. For instance, fancy graphics/user interfaces are not important. YAGNI: You Ain't Gonna Need It. Focus on the simplest thing that could possibly work, first.

  • Do not optimize your code unless you can argue there is a real problem (proven by profiling). Simplicity of the code has priority.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. --Donald Knuth

  • You are not supposed to show off how smart you are.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan

  • You are expected to write comments, only if you need to explain a complicated algorithm or motivate a particular piece of code. Do not engage in obligatory comments. Javadoc (or similar) is ok, but think about the purpose of Javadoc first.

  • It is unacceptable that there are remnants of dead code, commented out sections, or debugging print statements etc. in the code that you will present for grading.

  • You will only present working code for grading. Note: working code implies your project compiles without errors. Additionally, you should use the IDE in the correct way, setup dependencies correctly, provide build-scripts if necessary. If you don't use an IDE, you will use command line build tools or scripts to not repeat yourself.

Please take this advice to heart. It will influence your grade.

Administrativia

Each participant will have to use Github; please make an account if you haven't already. Then send me a note with your Github user name so that I can add you as a team member. After you have commit access, you can clone the following repository and start coding in your own subdirectory.

https://github.com/software-engineering-amsterdam/poly-ql.

To start with one of the skeleton projects copy the contents of one of the prototype projects into your private directory. E.g., on Unix-like machines:

cd my-user-dir cp -r prototypes/QLJava/* .

IMPORTANT: You are required to use Github. You should also commit regularly: NO huge final commit before the deadline.

IMPORTANT: You are required to complete the lab assignment individually. We will use clone detection tools to detect plagiarism.

IMPORTANT: You are required to use Eclipse for the skeleton projects.

IMPORTANT: Remember this is a single, shared Github repository, I expect everyone to act responsibly and try not to break the repository for everyone else, nor mess with anyone else's files.

Deadlines

  • Part 1 (front-end)
  • Part 2 (back-end)
  • Part 2 1-day part-time students: 4th of March, 2013
  • Part 2 "herkansing" (max grade = 8): 4th of March, 2013
Clone this wiki locally