Commit 6903c703 authored by Gerson Sunyé's avatar Gerson Sunyé
Browse files

New project organization to meet new docker image conventions and scripts.

parent ab7d2169
Pipeline #15508 passed with stages
in 36 seconds
- target
- apt-get update -qy
- curl -sL | bash -
- build
- deploy
......@@ -15,17 +7,18 @@ stages:
stage: build
- bash ./
- bash /home/
- target
stage: deploy
- mkdir -p public
- rsync -r target/site/ public
- du -sh public
- ls -la public
- mkdir -p public
- rsync -r target/site/ public
- public
- master
- master
\ No newline at end of file
......@@ -2,7 +2,7 @@
mkdir -p $TARGET
bundle exec asciidoctor-revealjs $SOURCE/*.adoc -D $TARGET
bundle exec asciidoctor-revealjs $SOURCE/*.adoc -R $SOURCE -D $TARGET
rsync -r src/images/ $TARGET/images
if test ! -d $TARGET/reveal.js; then
......@@ -10,6 +10,8 @@ if test ! -d $TARGET/reveal.js; then
git clone -b 3.8.0 --depth 1
rm -rf reveal.js/.git
tar cvfz 9.18.0.tar.gz
cd reveal.js
"name": "software-construction-and-evolution",
"version": "0.0.1",
"private": true,
"devDependencies": {
"grunt": "^1.0.0",
"grunt-contrib-connect": "^1.0.2",
"grunt-contrib-watch": "^1.0.0",
"grunt-contrib-copy": "^1.0.0",
"grunt-contrib-jshint": "^1.1.0",
"load-grunt-tasks": "^3.5.2",
"grunt-build-control": "^0.7.1",
"grunt-coffeelint": "0.0.16",
"coffeelint": "^1.16.0"
"engines": {
"node": ">=4"
"repository": {
"type": "git",
"url": ""
"scripts": {
"test": "grunt test"
......@@ -12,7 +12,21 @@
:includedir: includes
= Test-Driven Development
= Agile Software Development
* *Introduction*
* TDD and unit tests
* Strategies
* Conclusion
== Agile Manifesto
== Test-Driven Development
== Plan
......@@ -12,8 +12,13 @@
:includedir: includes
= Mapping UML Designs to Code
:revealjs_plugins: src/js/revealjs-plugins.js
//:revealjs_plugins_configuration: revealjs-plugins-conf.js
Behavioral Aspects
This diff is collapsed.
Continuous Integration
Improving Software Quality And Reducing Risk
Build Software Every Change
Build may consist of the compilation, testing, inspection, and deployment.
CI scenario typically go like
Developer commits code to version control repository
CI server detects that changes have occurred in the version control repository, and then executes a build script
CI server generate feedback by e-mailing build results to specified project member
CI server continues to poll for changes in the version control repository
Features of CI
Source Code Compilation
Database Integration
Document and Feedback
How could you know you are doing CI correctly?
Are you using a version control repository (or SCM tool)?
Is your project’s build process automated and repeatable? Does it occur entirely without intervention?
Are you writing and running automated test?
Is the execution of your tests a part of your build process?
How do you enforce coding and design standards?
Which of your feedback mechanisms are automated?
Are you using a separate integration machine to build software?
What prevents teams from Using CI?
Increased overhead in maintain the CI system
Too much change
Too many failed builds
Additional hardware/software cost
Developers should be performing these activities
How Do I Get to “Continuous” Integration?
Identify – Identify a process that requires automation
Build – Creating a build script makes the automation repeatable and consistent
Share – By using a version control system
Continuous – Ensure that the automated process is run with every change applied
Is it Continuous Compilation or Continuous Integration?
How much code coverage do you have with your test?
How long does it take to run your builds?
What is your average code complexity?
How much code duplication do you have?
Are you labeling your builds in your version control repository?
Where do you store your deployed software?
How does CI complement other development practices?
Developer testing
Coding standard adherence
Small release
Collective ownership
CI and you
Commit code frequently
Don’t commit broken code
Fix broken builds immediately
Write automated developer tests
All tests and inspections must pass
Run private builds
Avoid getting broken code
Risk: Lack of Deployable Software
Scenario: “It works on My Machine”
Solution: Use a CI server along with an automated build using tools such as Ant, NAnt, or Rake
Scenario: “Synching with the Database”
Solution: Place all database artifacts in your version control repository
Scenario: “The Missing Click”
Solution: Using script to automate the deployment process
Risk: Late Discovery of Defects
Scenario: Regression Testing
Solution: Using unit test at the business, data, and common layers and run continuously as a port of your CI system
Scenario: Test Coverage
Solution: Running test coverage tool to assess the amount of source code that is actually executed by the tests
Risk: Lack of Project Visibility
Scenario: Did you Get the Memo
Solution: Automated mechanism that sends e-mails to affected parties when a build fails
Scenario: Inability to Visualize software
Solution: Automated code documentation tool
Risk: Low-Quality Software
Scenario: Coding standard adherence
Solution: Using Checkstyle and PMD to report any lines of code that were not meeting the established standards
Scenario: Architectural Adherence
Solution: Using analysis tools such as JDepend or NDepend
Scenario: Duplicate Code
Solution: Automated inspection tools such as PMD’s CPD or the Simian static analysis tools
Integration build Scalability and Performance
Gather build metric
Analyze build metric
Choose and perform improvements
Reevaluate; repeat if necessary
Continues Database Integration
Automate Database Integration
Use a local database sandbox
Use a version control repository to share database asset
Give developer the capacity to modify database
Make the DBA part of the development team
Reduce Code Complexity
Cyclomatic Complexity Number (CCN) is a plain integer that measure complexity by coding the number of distinct paths through a method
Various studies with this metric over the years have determined that methods with CCN greater than 10 have a higher risk of defects
The most effective way to reduce cyclomatic complexity is to apply the extract method technique
Perform Design Reviews Continuously
Afferent Coupling, Fan In, an object has responsibility to too many other objects (high afferent)
Efferent Coupling, Fan Out, the object isn’t sufficiently independent of other objects (high efferent)
Instability = Efferent Coupling/(Efferent Coupling + Afferent Coupling)
Maintain Organization Standards with Code Audits
Coding standard facilitate a common understanding of a code base among a diverse group of developer
Human code reviews and pair programming can be effective in monitoring coding standards, they do not scale as well as automated tools
Popular code analysis tool for Java platform is PMD
Reduce Duplicate Code using PMD-CPD or Simian
CI Resources
Automated Inspection Resources
CI Resources
Deployment Resources
FeedBack Resources
Ambient Devices
Google Talk
Documentation Resources
Evaluating tools
Compatibility with your environment
Does the tools support your current build configuration?
Does the tool require installation of additional software in order to run?
Is the tool written in the same language as your project?
......@@ -203,12 +203,14 @@ image::selenium.jpg[align=center]
* Code Review can be impressively effective; however, they are run by humans, who tend to be emotional
* Pair Programming has also been shown to be effective when applied correctly
* Automated static code analysis scales more efficiently than humans for large code bases
* What is the different between inspection and testing
== Inspection and Testing
.What is the different between inspection and testing?
* Testing is dynamic and executes the software in order to test the functionality
* Inspection analyze the code based on a set of predefined rules
* Example of inspection targets include coding “grammar” standards, architectural layering adherence, code duplication, and so on
== Plan
* Introduction
= Automatic Code Generation
== Plan
* Introduction<!-- .element: class="fragment highlight-blue" -->
* Approaches
* Xtend
* Acceleo
* Conclusion
== Code Generation
* Operation that generates textual artifacts (documents, source code, configuration, etc.) from models (graph-like).
* Motivation:
* *Abstraction*: from abstract syntax to the concrete syntax (textual)
* *Readability*: the models we generate are often not easy to read
* *Executability and testing*: easy to generate running code and test it
public class Team {
// (..)
public class Match {
// (..)
public class Player {
// (..)
== Underlying model
* Set of classes of a specific programming language allowing to instantiate a model.
* For instance, to represent a UML model in Java, we need different classes:
* `UMLClass`
* `UMLAttribute`
* `UMLOperation`
* etc.
* The underlying model can be:
* generic or specific to a modeling language.
* follow a standard: JMI (Java Metadata Interface), EMF (Eclipse Modeling Framework).
== Plan
* Introduction
* Approaches<!-- .element: class="fragment highlight-blue" -->
* Xtend
* Acceleo
* Conclusion
== Code Generation Approaches
. Script Languages
. General Purpose Languages (GPLs): Java, C#
. Generic transformation tools: Graph transformations, XSLT
. CASE tools scripting languages: Objecteering, Rose
. Dedicated model transformation languages: ATL, Operational QVT
. Dedicated model to text transformation languages: xTend, Jet, Acceleo
== Script Languages
* sed (Stream Editor), 1973
* Awk (Text processing language), 1977
* Perl, 1987
* Python, Ruby, etc.
== Script example
#!/usr/local/bin/tcsh -f
# $* : Eiffel files to process
foreach f ( $* )
set classname = `basename $f .e`
echo -n "Doing $classname. "
set newcode = /tmp/inserted_text$$
# First, extract attribute and association declarations
sed -n -e '1,/^ * -- attribute/d' \
-e '/^ * -- associations/,$d' \
-e '/^ *[a-z][_A-Za-z0-9]* *: *[A-Z][_A-Z [\]]*[^a-z]*$/s/ *: */ /p'\
$f > /tmp/att_list$$
sed -n -e '1,/^ * -- associations/d' \
-e '/^feature/,$d' \
-e '/^ *[a-z][_A-Za-z0-9]* *: *[A-Z][_A-Z [\]]*[^a-z]*$/s/ *: */ /p'\
$f > /tmp/association_list$$
== General Purpose Languages
* Java, VB, C++, C#,… Your favorite language!
* Rules and scheduling implemented from scratch using the programming language
* No overhead to learn a new language
* Tool support to write the transformations
== GPL Approaches (1/2)
* Visitor-Based Approaches:
* Some visitor mechanisms to traverse the internal representation of a model and write code to a text stream
* Iterators, sequence of `Write()` calls.
== Visitor Example
* For example, you want to perform some processing on UML classes and their attributes.
* In the underlying model, a class and its associated attributes is represented by the composition relation below:
* Several visitors can be used to traverse the model:
* To see how the traversal completes its task, we will refer to the following sequence diagram:
== Visitor Drawbacks
* Not scalable: a lot of code to write, difficult to maintain
* Basic behavior implementation: load the model, save the text, implement the methods that perform the code generation operation, etc.
* Lack of declarative query language
* Difficult to generate readable code (pretty printing)
== GPL Approaches (2/2)
* Template-Based Approaches
* A template consists of the target text containing slices of meta-code to access information from the source and to perform text selection and iterative expansion
* The structure of a template resembles closely the text to be generated
* Textual templates are independent of the target language and simplify the generation of any textual artifacts
== Templates
== Template example
class <<>> {
<<FOR Feature f: class.features>>
private <<f.type>> ;
class Person {
private int age;
== Generic transformation tools
* Typically XML based
* But XML (XMI) is verbose
* XSLT can be used to transform XML trees into other (XML) (trees)
* But models are graphs
* Associations (reference) between nodes are done by values
* XSLT transformations are not really easy to maintain
* Better for simple transformations
== XSLT example
<xsl:stylesheet version="1.0" xmlns:xsl="" xmlns:func="" xmlns:my="urn:my-functions" xmlns:date="" xmlns:math="" extension-element-prefixes="func date">
<xsl:param name="p1"/>
<xsl:param name="p2"/>
<xsl:param name="p3"/>
<xsl:param name="p4"/>
<xsl:template match="/">
<function><xsl:value-of select="my:func()"/></function>
<date><xsl:value-of select="date:date()"/></date>
<max><xsl:value-of select="math:max(//max/value)"/></max>
<p1><xsl:value-of select="$p1"/></p1>
<p2><xsl:value-of select="$p2"/></p2>
<p3><xsl:value-of select="$p3"/></p3>
<p4><xsl:value-of select="$p4"/></p4>
<func:function name="my:func">
<func:result select="'func-result'"/>
== CASE tools scripting languages
* Arcstyler from Interactive Objects
* MDA-Cartridge, JPython (Python &amp; Java)
* Objecteering from Objecteering Software
* J language
* OptimalJ from Compuware
* TPL language
* Fujaba (From UML to Java and Back Again)
* Open Source
== CASE tools scripting languages
* *Advantages*
* Good level of maturity
* Excellent integration with their CASE tool
* *Drawbacks*
* Proprietary languages and/or tight coupling with the CASE
* Often developed as a second thought, not central
* Many limitations when model transformation get complex
* Structuring, modularity, reuse problem
* Configuration management issue when they need to be evolved and maintained for long periods
== Dedicated model transformation languages
* Simplify development and maintenance of model-transformations
* Higher expression power
* Enhanced structuring
* Composition of rules
* Interoperability
== Transformation rule example
rule Member2Female {
s: Families!Member (s.isFemale())
t: Persons!Female (
fullName <- s.firstName + ' ' + s.familyName
== Model transformation drawbacks
* Transformation languages are generally used to implement model transformations
* Not really adapted to generate code
* Transformation rules tend to be granular
== Dedicated model to text transformation languages
* Acceleo
* Implementation reference for OMG's MTL (MOF Model to Text Transformation Language)
* Dedicated template engine for code generation
* Xtend
* Java + Templates + Sugar
== M2T Transformation Languages
* *Advantages*
* Template-based approach: text fragments + template expressions (constructs)
* Declarative query language: OCL, XPath, etc.
* Template engine: replaces template expressions with data at runtime and produces output files
* Scalable: at least more than other approaches
* Produces readable code
* *Drawbacks*
* Another language to learn
* Difficult to choose where to place specific behavior: in the meta-model or in the templates.
== Plan
* Introduction
* Approaches
* Xtend<!-- .element: class="fragment highlight-blue" -->
* Acceleo
* Conclusion
== Xtend
* Extension of Xpand (i.e. a template-based M2T)
* Brings together the advantages of GPLs and Template expressions
* Statically-typed PL which translates to comprehensible Java code, but improves:
* Lambda expressions
* Method dispatch &amp; method extension
* Template expressions
* Generates reusable Java code
== Lambda expresssions
Java code:
final JTextField textField = new JTextField();
textField.addActionListener(new ActionListener() {