Initial commit
This commit is contained in:
github-classroom[bot]
GitHub
commit
440559dc57
16 changed files with 1952 additions and 0 deletions
111
.gitignore
vendored
Normal file
111
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
# Generated files
|
||||
upload/
|
||||
build.json
|
||||
|
||||
# Finder
|
||||
.DS_Store
|
||||
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# Diagnostic reports (https://nodejs.org/api/report.html)
|
||||
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
|
||||
# Directory for instrumented libs generated by jscoverage/JSCover
|
||||
lib-cov
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
coverage
|
||||
*.lcov
|
||||
|
||||
# nyc test coverage
|
||||
.nyc_output
|
||||
|
||||
# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
|
||||
.grunt
|
||||
|
||||
# Bower dependency directory (https://bower.io/)
|
||||
bower_components
|
||||
|
||||
# node-waf configuration
|
||||
.lock-wscript
|
||||
|
||||
# Compiled binary addons (https://nodejs.org/api/addons.html)
|
||||
build/Release
|
||||
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
jspm_packages/
|
||||
|
||||
# TypeScript v1 declaration files
|
||||
typings/
|
||||
|
||||
# TypeScript cache
|
||||
*.tsbuildinfo
|
||||
|
||||
# Optional npm cache directory
|
||||
.npm
|
||||
|
||||
# Optional eslint cache
|
||||
.eslintcache
|
||||
|
||||
# Microbundle cache
|
||||
.rpt2_cache/
|
||||
.rts2_cache_cjs/
|
||||
.rts2_cache_es/
|
||||
.rts2_cache_umd/
|
||||
|
||||
# Optional REPL history
|
||||
.node_repl_history
|
||||
|
||||
# Output of 'npm pack'
|
||||
*.tgz
|
||||
|
||||
# Yarn Integrity file
|
||||
.yarn-integrity
|
||||
|
||||
# dotenv environment variables file
|
||||
.env
|
||||
.env.test
|
||||
|
||||
# parcel-bundler cache (https://parceljs.org/)
|
||||
.cache
|
||||
|
||||
# Next.js build output
|
||||
.next
|
||||
|
||||
# Nuxt.js build / generate output
|
||||
.nuxt
|
||||
dist
|
||||
|
||||
# Gatsby files
|
||||
.cache/
|
||||
# Comment in the public line in if your project uses Gatsby and *not* Next.js
|
||||
# https://nextjs.org/blog/next-9-1#public-directory-support
|
||||
# public
|
||||
|
||||
# vuepress build output
|
||||
.vuepress/dist
|
||||
|
||||
# Serverless directories
|
||||
.serverless/
|
||||
|
||||
# FuseBox cache
|
||||
.fusebox/
|
||||
|
||||
# DynamoDB Local files
|
||||
.dynamodb/
|
||||
|
||||
# TernJS port file
|
||||
.tern-port
|
||||
72
README.md
Normal file
72
README.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
# MSDE Software Architecture 2022
|
||||
|
||||
Modeling Assignment Repository
|
||||
|
||||
## Getting started
|
||||
|
||||
```
|
||||
brew install yarn plantuml
|
||||
yarn install
|
||||
yarn global add onchange
|
||||
```
|
||||
|
||||
For installation of brew take a look at:
|
||||
|
||||
* https://brew.sh/
|
||||
|
||||
Make sure that your `java` version is compatible with `plantuml`
|
||||
|
||||
## Building the document
|
||||
|
||||
```
|
||||
yarn build
|
||||
```
|
||||
|
||||
The document [Markdown](https://www.markdownguide.org/cheat-sheetplan) and [PlantUML](https://plantuml.com/) source is found in the `src/sa/model/` folder.
|
||||
|
||||
Write your assignments extending the template `index.md` as you solve each exercise.
|
||||
|
||||
Enter your project title and your name in the header.
|
||||
|
||||
```
|
||||
---
|
||||
title:
|
||||
Model of My Project
|
||||
---
|
||||
author:
|
||||
Enter Your Full Name
|
||||
---
|
||||
```
|
||||
|
||||
The HTML output and the generated SVG diagrams are stored in the `upload` folder.
|
||||
|
||||
## Clean the Output
|
||||
```
|
||||
yarn clean
|
||||
```
|
||||
|
||||
## Continuous Build
|
||||
```
|
||||
yarn watch
|
||||
```
|
||||
|
||||
This requires `yarn global add onchange` to work. It will automatically rebuild the documentation when the source files are modified. Stop it using `^C`.
|
||||
|
||||
|
||||
## Submitting Your Work
|
||||
|
||||
After adding (with `git add`) whatever file you have modified (please **do not** include the generated files inside the `upload` folder), use the following commit message to indicate your work is ready to be checked:
|
||||
|
||||
```
|
||||
git commit -m "exercise N complete, please check"
|
||||
git push
|
||||
```
|
||||
|
||||
where N is the assignment number (0-15).
|
||||
|
||||
We will use github issues to provide feedback about your model.
|
||||
|
||||
Also, be ready to present and discuss your work during lectures.
|
||||
|
||||
|
||||
|
||||
593
build.js
Normal file
593
build.js
Normal file
|
|
@ -0,0 +1,593 @@
|
|||
const { PerformanceObserver, performance } = require('perf_hooks');
|
||||
let t_start = performance.now();
|
||||
|
||||
process.on('exit', function () {
|
||||
let t_end = performance.now();
|
||||
console.log("Done in " + (t_end - t_start) + "ms");
|
||||
});
|
||||
|
||||
const fs = require('fs-extra');
|
||||
const glob = require('glob-fs')({ gitignore: true });
|
||||
const marked = require('marked');
|
||||
const marked_toc = require('marked');
|
||||
const plantuml = require('plantuml');
|
||||
const _ = require('lodash');
|
||||
const slugify = require('uslug');
|
||||
|
||||
|
||||
|
||||
|
||||
const child_process = require('child_process');
|
||||
|
||||
|
||||
function run(cmd, cwd, done) {
|
||||
|
||||
console.log(cmd);
|
||||
|
||||
const exec = child_process.exec;
|
||||
exec(cmd, { cwd }, (err, stdout, stderr) => {
|
||||
if (err) {
|
||||
//some err occurred
|
||||
console.error(err);
|
||||
} else {
|
||||
// the *entire* stdout and stderr (buffered)
|
||||
console.log(`stdout: ${stdout}`);
|
||||
console.log(`stderr: ${stderr}`);
|
||||
if (typeof done == "function") {
|
||||
done(err, stdout, stderr);
|
||||
} else { }
|
||||
}
|
||||
});
|
||||
|
||||
}
|
||||
|
||||
|
||||
const build_json = fs.readJSONSync('build.json', { throws: false }) || {};
|
||||
|
||||
build_json.doc_build = (build_json.doc_build || 0) + 1;
|
||||
|
||||
fs.outputJsonSync('build.json', build_json, { spaces: 2 });
|
||||
|
||||
|
||||
String.prototype.hashCode = function () {
|
||||
var hash = 0, i, chr;
|
||||
if (this.length === 0) return hash;
|
||||
for (i = 0; i < this.length; i++) {
|
||||
chr = this.charCodeAt(i);
|
||||
hash = ((hash << 5) - hash) + chr;
|
||||
hash |= 0; // Convert to 32bit integer
|
||||
}
|
||||
return hash;
|
||||
};
|
||||
|
||||
const cache_json = fs.readJSONSync('./upload/puml_cache.json', { throws: false }) || {};
|
||||
|
||||
|
||||
function cache_lookup(text, miss) {
|
||||
let hash = new String(text).hashCode();
|
||||
|
||||
if (cache_json[hash]) { //hit
|
||||
return new Promise((resolve, reject) => resolve(cache_json[hash]));
|
||||
} else {
|
||||
return miss(text).then((output) => {
|
||||
cache_json[hash] = output;
|
||||
fs.outputJson('./upload/puml_cache.json', cache_json, { spaces: 2 });
|
||||
return output;
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
let puml_count = 0;
|
||||
let epuml_count = 0;
|
||||
let fml_count = 0;
|
||||
|
||||
|
||||
function toc(str) {
|
||||
|
||||
// var defaultTemplate = '<%= depth %><%= bullet %>[<%= heading %>](#<%= url %>)\n';
|
||||
var defaultTemplate = '<a class="d<%=d%>" href="#<%= url %>"><%- heading %></a>\n';
|
||||
|
||||
const utils = {};
|
||||
|
||||
utils.arrayify = function (arr) {
|
||||
return !Array.isArray(arr) ? [arr] : arr;
|
||||
};
|
||||
|
||||
utils.escapeRegex = function (re) {
|
||||
return re.replace(/(\[|\]|\(|\)|\/|\.|\^|\$|\*|\+|\?)/g, '\\$1');
|
||||
};
|
||||
|
||||
utils.isDest = function (dest) {
|
||||
return !dest || dest === 'undefined' || typeof dest === 'object';
|
||||
};
|
||||
|
||||
utils.isMatch = function (keys, str) {
|
||||
keys = utils.arrayify(keys);
|
||||
keys = (keys.length > 0) ? keys.join('|') : '.*';
|
||||
|
||||
// Escape certain characters, like '[', '('
|
||||
var k = utils.escapeRegex(String(keys));
|
||||
|
||||
// Build up the regex to use for replacement patterns
|
||||
var re = new RegExp('(?:' + k + ')', 'g');
|
||||
if (String(str).match(re)) {
|
||||
return true;
|
||||
} else {
|
||||
return false;
|
||||
}
|
||||
};
|
||||
|
||||
utils.sanitize = function (src) {
|
||||
src = src.replace(/(\s*\[!|(?:\[.+ →\]\()).+/g, '');
|
||||
src = src.replace(/\s*\*\s*\[\].+/g, '');
|
||||
return src;
|
||||
};
|
||||
|
||||
utils.slugify = function (str) {
|
||||
str = str.replace(/\/\//g, '-');
|
||||
str = str.replace(/\//g, '-');
|
||||
str = str.replace(/\./g, '-');
|
||||
str = _.str.slugify(str);
|
||||
str = str.replace(/^-/, '');
|
||||
str = str.replace(/-$/, '');
|
||||
return str;
|
||||
};
|
||||
|
||||
var omit = ['grunt', 'helper', 'handlebars-helper', 'mixin', 'filter', 'assemble-contrib', 'assemble'];
|
||||
|
||||
utils.strip = function (name, options) {
|
||||
var opts = _.extend({}, options);
|
||||
if(opts.omit === false) {omit = [];}
|
||||
var exclusions = _.union(omit, utils.arrayify(opts.strip || []));
|
||||
var re = new RegExp('^(?:' + exclusions.join('|') + ')[-_]?', 'g');
|
||||
return name.replace(re, '');
|
||||
};
|
||||
|
||||
var opts = {
|
||||
firsth1: false,
|
||||
blacklist: true,
|
||||
omit: [],
|
||||
maxDepth: 3,
|
||||
slugifyOptions: { allowedChars: '-' },
|
||||
slugify: function (text) {
|
||||
return slugify(text, opts.slugifyOptions).replace("ex-","ex---");
|
||||
}
|
||||
};
|
||||
|
||||
var toc = '';
|
||||
var tokens = marked.lexer(str);
|
||||
var tocArray = [];
|
||||
|
||||
// Remove the very first h1, true by default
|
||||
if (opts.firsth1 === false) {
|
||||
tokens.shift();
|
||||
}
|
||||
|
||||
// Do any h1's still exist?
|
||||
var h1 = _.some(tokens, { depth: 1 });
|
||||
|
||||
var task_count = 0;
|
||||
|
||||
tokens.filter(function (token) {
|
||||
// Filter out everything but headings
|
||||
if (token.type !== 'heading' || token.type === 'code') {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Since we removed the first h1, we'll check to see if other h1's
|
||||
// exist. If none exist, then we unindent the rest of the TOC
|
||||
if (!h1) {
|
||||
token.depth = token.depth - 1;
|
||||
}
|
||||
|
||||
// Store original text and create an id for linking
|
||||
token.heading = opts.strip ? utils.strip(token.text, opts) : token.text;
|
||||
|
||||
if (token.heading.indexOf("Ex -") >= 0) {
|
||||
task_count++;
|
||||
token.heading = token.heading.replace("Ex -", `<span class='task'>${task_count}.</span> `);
|
||||
}
|
||||
|
||||
// Create a "slugified" id for linking
|
||||
token.id = opts.slugify(token.text);
|
||||
|
||||
// Omit headings with these strings
|
||||
var omissions = ['Table of Contents', 'TOC', 'TABLE OF CONTENTS'];
|
||||
var omit = _.union([], opts.omit, omissions);
|
||||
|
||||
if (utils.isMatch(omit, token.heading)) {
|
||||
return;
|
||||
}
|
||||
|
||||
return true;
|
||||
}).forEach(function (h) {
|
||||
|
||||
if (h.depth > opts.maxDepth) {
|
||||
return;
|
||||
}
|
||||
|
||||
var bullet = Array.isArray(opts.bullet)
|
||||
? opts.bullet[(h.depth - 1) % opts.bullet.length]
|
||||
: opts.bullet;
|
||||
|
||||
var data = _.extend({}, opts.data, {
|
||||
d: h.depth,
|
||||
depth: new Array((h.depth - 1) * 2 + 1).join(' '),
|
||||
bullet: bullet ? bullet : '* ',
|
||||
heading: h.heading,
|
||||
url: h.id
|
||||
});
|
||||
|
||||
tocArray.push(data);
|
||||
toc += ejs.render(defaultTemplate,data);
|
||||
//toc += _.template(opts.template || defaultTemplate, data);
|
||||
});
|
||||
|
||||
return {
|
||||
data: tocArray,
|
||||
toc: opts.strip
|
||||
? utils.strip(toc, opts)
|
||||
: toc
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
|
||||
const renderer = new marked.Renderer();
|
||||
|
||||
renderer._paragraph = renderer.paragraph;
|
||||
|
||||
renderer.paragraph = function (text) {
|
||||
|
||||
//console.log(text);
|
||||
|
||||
if (text.trim().startsWith("{")) {
|
||||
|
||||
renderer.sec_depth = renderer.sec_depth || 0;
|
||||
renderer.sec_depth++;
|
||||
|
||||
let c = text.split(".");
|
||||
c.shift();
|
||||
|
||||
if (c.length > 0) {
|
||||
return `<section class="${c.join(" ")}">`;
|
||||
} else {
|
||||
return "<section>"
|
||||
}
|
||||
}
|
||||
|
||||
if (text.trim().startsWith("}")) {
|
||||
|
||||
renderer.sec_depth = renderer.sec_depth || 0;
|
||||
renderer.sec_depth--;
|
||||
|
||||
return "</section>"
|
||||
}
|
||||
|
||||
if (text.trim().startsWith("Pass: ") && renderer.sec_depth > 0) {
|
||||
return `<section class="pass"><span>★☆☆: </span>${text.split("Pass: ")[1]}</section>`;
|
||||
}
|
||||
if (text.trim().startsWith("Good: ") && renderer.sec_depth > 0) {
|
||||
return `<section class="ok"><span>★★☆: </span>${text.split("Good: ")[1]}</section>`;
|
||||
}
|
||||
if (text.trim().startsWith("Exceed: ") && renderer.sec_depth > 0) {
|
||||
return `<section class="exceed"><span>★★★: </span>${text.split("Exceed: ")[1]}</section>`;
|
||||
}
|
||||
if (text.trim().startsWith("Hint: ") && renderer.sec_depth > 0) {
|
||||
return `<section class="hint"><span>Hint: </span>${text.split("Hint: ")[1]}</section>`;
|
||||
}
|
||||
|
||||
return renderer._paragraph(text);
|
||||
}
|
||||
|
||||
renderer._code = renderer.code;
|
||||
|
||||
renderer.code = function (code, infostring, escaped) {
|
||||
//console.log(code, infostring, escaped);
|
||||
if (infostring) {
|
||||
if (infostring.startsWith("puml")) {
|
||||
let i = epuml_count++;
|
||||
cache_lookup(code, () => plantuml(code)).then(svg => {
|
||||
fs.writeFile(renderer._out_folder + "puml_e" + i + ".svg", svg)
|
||||
})
|
||||
return `<img src="./puml_e${i}.svg">`;
|
||||
}
|
||||
}
|
||||
return renderer._code(code, infostring, escaped);
|
||||
|
||||
};
|
||||
|
||||
renderer._image = renderer.image;
|
||||
|
||||
renderer.image = function (href, title, text) {
|
||||
|
||||
//console.log(href, title, text);
|
||||
|
||||
if (href.endsWith(".puml")) {
|
||||
|
||||
let i = puml_count++;
|
||||
|
||||
fs.readFile(href.replace("./", renderer._in_folder)).then(puml => {
|
||||
return cache_lookup(puml, () => plantuml(puml))
|
||||
//return plantuml(puml)
|
||||
}).then(svg => {
|
||||
fs.writeFile(renderer._out_folder + "puml_" + i + ".svg", svg)
|
||||
})
|
||||
|
||||
return `<img src="./puml_${i}.svg" alt="${text}">`;
|
||||
|
||||
}
|
||||
|
||||
if (href.endsWith(".fml")) {
|
||||
|
||||
let i = fml_count++;
|
||||
|
||||
const fml_output = renderer._out_folder + "fml_" + i + ".svg";
|
||||
|
||||
run("node fml " + href.replace("./", renderer._in_folder) + " " + fml_output);
|
||||
|
||||
return `<img src="./fml_${i}.svg" alt="${text}">`;
|
||||
|
||||
}
|
||||
|
||||
if (href.endsWith(".c5")) {
|
||||
|
||||
let i = fml_count++;
|
||||
|
||||
const fml_output = renderer._out_folder + "c5_" + i + ".svg";
|
||||
|
||||
run("node c5 " + href.replace("./", renderer._in_folder) + " " + fml_output);
|
||||
|
||||
return `<img src="./c5_${i}.svg" alt="${text}">`;
|
||||
|
||||
}
|
||||
|
||||
if (href.endsWith(".madr")) {
|
||||
|
||||
let md = fs.readFileSync(href.replace("./", renderer._in_folder));
|
||||
|
||||
return `<h3>${text}</h3>` + marked.parse("" + new String(md));
|
||||
|
||||
}
|
||||
|
||||
return renderer._image(href, title, text);
|
||||
|
||||
}
|
||||
|
||||
renderer._heading = renderer.heading;
|
||||
|
||||
let task_count = 0;
|
||||
|
||||
renderer.heading = function (text, level, raw, slugger) {
|
||||
|
||||
// console.log(text);
|
||||
|
||||
if (text.indexOf("Ex -") >= 0) {
|
||||
task_count++;
|
||||
text = text.replace("Ex -", `<span class='task'>${task_count}.</span> `);
|
||||
}
|
||||
|
||||
// let sec = "<section>"
|
||||
|
||||
// if (task_count > 1) {
|
||||
// sec = "</section>" + sec;
|
||||
// }
|
||||
|
||||
return renderer._heading(text, level, raw, slugger);
|
||||
};
|
||||
|
||||
|
||||
marked.setOptions({
|
||||
renderer, //: new marked.Renderer(),
|
||||
highlight: function (code) {
|
||||
return code; //require('highlight').highlightAuto(code).value;
|
||||
},
|
||||
pedantic: false,
|
||||
gfm: true,
|
||||
breaks: false,
|
||||
sanitize: false,
|
||||
smartLists: true,
|
||||
smartypants: false,
|
||||
xhtml: false
|
||||
});
|
||||
|
||||
function loadMD(f, vars = {}) {
|
||||
|
||||
let txt = "" + new String(fs.readFileSync(f));
|
||||
|
||||
if (txt.indexOf("---") >= 0) {
|
||||
|
||||
let parts = txt.split("\n---\n");
|
||||
|
||||
parts.slice(0, -1).forEach(p => {
|
||||
let lines = p.split("\n");
|
||||
let k = lines[0].split(":");
|
||||
vars[k[0]] = lines.slice(1).join("\n");
|
||||
});
|
||||
|
||||
txt = parts[parts.length - 1];
|
||||
|
||||
}
|
||||
|
||||
//convert strings to booleans
|
||||
Object.keys(vars).forEach(k => {
|
||||
if (vars[k] === "false") vars[k] = false;
|
||||
if (vars[k] === "true") vars[k] = true;
|
||||
})
|
||||
|
||||
console.log(vars);
|
||||
|
||||
task_count = 0;
|
||||
|
||||
return { md: marked.parse(txt), meta: vars, toc: toc(txt) };
|
||||
}
|
||||
|
||||
|
||||
let ejs = require('ejs');
|
||||
|
||||
let views = {}
|
||||
|
||||
function render_one(model, out_file, template) {
|
||||
|
||||
model.out_file = out_file;
|
||||
|
||||
views[template] = views[template] || new String(fs.readFileSync("./template/" + template + ".ejs"));
|
||||
|
||||
let html = ejs.render(views[template], model);
|
||||
|
||||
fs.ensureFileSync(out_file);
|
||||
fs.writeFileSync(out_file, html);
|
||||
|
||||
};
|
||||
|
||||
|
||||
var walk = function (dir, done) {
|
||||
var results = [];
|
||||
fs.readdir(dir, function (err, list) {
|
||||
if (err) return done(err);
|
||||
var i = 0;
|
||||
(function next() {
|
||||
var file = list[i++];
|
||||
if (!file) return done(null, results);
|
||||
file = dir + '/' + file;
|
||||
fs.stat(file, function (err, stat) {
|
||||
if (stat && stat.isDirectory()) {
|
||||
walk(file, function (err, res) {
|
||||
results = results.concat(res);
|
||||
next();
|
||||
});
|
||||
} else {
|
||||
results.push({ name: file, stat });
|
||||
next();
|
||||
}
|
||||
});
|
||||
})();
|
||||
});
|
||||
};
|
||||
|
||||
|
||||
|
||||
function deltaBuild() {
|
||||
let old_file_list = {};
|
||||
try {
|
||||
old_file_list = fs.readJsonSync('upload/files.json');
|
||||
} catch (e) { }
|
||||
|
||||
walk("src", function (err, list) {
|
||||
|
||||
if (list === undefined) {
|
||||
console.log("Missing src folder")
|
||||
return;
|
||||
}
|
||||
|
||||
if (list.length == 0) {
|
||||
console.log("Empty src folder")
|
||||
return;
|
||||
}
|
||||
|
||||
let flat = {};
|
||||
list.filter((f) => !f.name.endsWith(".DS_Store")).forEach(f => {
|
||||
flat[f.name] = f.stat;
|
||||
});
|
||||
|
||||
let todo = {};
|
||||
|
||||
let deleted = {};
|
||||
Object.keys(old_file_list).forEach(k => { deleted[k] = old_file_list[k] });
|
||||
|
||||
let changed = [];
|
||||
|
||||
function extract_dir(k) {
|
||||
let a = k.split("/")
|
||||
return a.slice(1, 3).join("/");
|
||||
}
|
||||
|
||||
function push(k) {
|
||||
let d = extract_dir(k);
|
||||
todo[d] = (todo[d] || 0) + 1;
|
||||
|
||||
changed.push(k);
|
||||
}
|
||||
|
||||
Object.keys(flat).forEach((k) => {
|
||||
if (old_file_list[k]) {
|
||||
if (flat[k].mtimeMs != old_file_list[k].mtimeMs) {
|
||||
push(k);
|
||||
}
|
||||
delete deleted[k]; //k was found so what's left over should have been deleted
|
||||
} else {
|
||||
push(k); //this is a new addition
|
||||
}
|
||||
});
|
||||
|
||||
fs.writeJson("upload/files.json", flat);
|
||||
|
||||
console.log('Changed', changed);
|
||||
console.log('Deleted', Object.keys(deleted));
|
||||
|
||||
if (Object.keys(todo).length == 0) {
|
||||
todo['sa/model'] = 1;
|
||||
}
|
||||
|
||||
//todo['exercises/8-ws'] = 1;
|
||||
|
||||
if (Object.keys(todo).indexOf('templates/doc.ejs') != -1) {
|
||||
todo = Array.from(new Set(Object.keys(flat).map(extract_dir))).reduce((a, c) => { a[c] = 1; return a; }, {});
|
||||
delete todo['templates/doc.ejs'];
|
||||
}
|
||||
|
||||
Object.keys(todo).filter(k => k.endsWith('meta.json')).forEach(mk => {
|
||||
delete todo[mk];
|
||||
Array.from(new Set(Object.keys(flat).map(extract_dir))).filter(k => k.startsWith(mk.split("/")[0])).forEach(k => {
|
||||
todo[k] = 1;
|
||||
})
|
||||
})
|
||||
|
||||
console.log("Building", todo);
|
||||
|
||||
Object.keys(todo).forEach(buildDoc.bind(null, changed, Object.keys(deleted)));
|
||||
|
||||
})
|
||||
}
|
||||
|
||||
function buildDoc(changed, deleted, slide) {
|
||||
|
||||
console.log("Building " + slide);
|
||||
|
||||
let md_path = "./src/" + slide + "/index.md";
|
||||
|
||||
let md = { meta: {} };
|
||||
|
||||
let meta_path = "./src/" + slide.split("/")[0] + "/meta.json";
|
||||
try {
|
||||
md.meta = fs.readJSONSync(meta_path);
|
||||
} catch (e) {
|
||||
//console.log(e);
|
||||
}
|
||||
|
||||
md.meta.build = build_json.doc_build;
|
||||
//md.meta.lecture = "Web Atelier 2020 ";
|
||||
md.meta.timestamp = new Date().toLocaleString();
|
||||
|
||||
if (fs.existsSync(md_path) && fs.lstatSync(md_path).isFile()) {
|
||||
|
||||
renderer._out_folder = `./upload/${slide}/`;
|
||||
renderer._in_folder = `./src/${slide}/`;
|
||||
|
||||
md = loadMD(md_path, md.meta);
|
||||
|
||||
md.meta.series = "";
|
||||
|
||||
let model = { title: slide, md: md.md, toc: md.toc, meta: md.meta, pid: slide + "." + build_json.build }
|
||||
|
||||
let mdout = `./upload/${slide}/index.html`;
|
||||
|
||||
render_one(model, mdout, 'doc');
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
fs.ensureDirSync("upload/");
|
||||
deltaBuild();
|
||||
1
c5.js
Normal file
1
c5.js
Normal file
File diff suppressed because one or more lines are too long
1
fml.js
Normal file
1
fml.js
Normal file
File diff suppressed because one or more lines are too long
25
package.json
Normal file
25
package.json
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
{
|
||||
"name": "msde-2023-sa",
|
||||
"version": "1.0.0",
|
||||
"description": "Software Architecture Modeling Exercises",
|
||||
"main": "build.js",
|
||||
"author": "Cesare Pautasso",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@svgdotjs/svg.js": "^3.1.2",
|
||||
"dagrejs": "^0.2.1",
|
||||
"ejs": "^3.1.6",
|
||||
"fs-extra": "^10.0.0",
|
||||
"glob-fs": "^0.1.7",
|
||||
"lodash": "^4.17.21",
|
||||
"marked": "^4.0.12",
|
||||
"metalsmith-plantuml": "^0.0.4",
|
||||
"svgdom": "^0.1.10",
|
||||
"uslug": "^1.0.4"
|
||||
},
|
||||
"scripts": {
|
||||
"build": "node build.js",
|
||||
"clean": "rm -rf upload/*",
|
||||
"watch": "onchange src/** -- yarn build"
|
||||
}
|
||||
}
|
||||
36
src/sa/model/decisions/decision-template.madr
Normal file
36
src/sa/model/decisions/decision-template.madr
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
## ADR #0 (Template)
|
||||
|
||||
1. What did you decide?
|
||||
|
||||
Give a short title of solved problem and solution
|
||||
|
||||
2. What was the context for your decision?
|
||||
|
||||
What is the goal you are trying to achieve?
|
||||
|
||||
What are the constraints?
|
||||
|
||||
What is the scope of your decision? Does it affect the entire architecture?
|
||||
|
||||
3. What is the problem you are trying to solve?
|
||||
|
||||
You may want to articulate the problem in form of a question.
|
||||
|
||||
4. Which alternative options did you consider?
|
||||
|
||||
List at least 3 options
|
||||
|
||||
5. Which one did you choose?
|
||||
|
||||
Pick one of the options as the outcome of your decision
|
||||
|
||||
6. What is the main reason for that?
|
||||
|
||||
List the positive consequences (pros) of your decision:
|
||||
|
||||
* quality improvement
|
||||
* satisfaction of external constraint
|
||||
|
||||
If any, list the negative consequences (cons)
|
||||
|
||||
* quality degradation
|
||||
49
src/sa/model/examples/connector-view.c5
Normal file
49
src/sa/model/examples/connector-view.c5
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
/// The Connector View is a graph of components/connectors
|
||||
|
||||
/// Simple 1-1 connectors are modeled on the edges
|
||||
|
||||
Client -call-> Server
|
||||
|
||||
Source -stream-> Filter -stream-> Sink
|
||||
|
||||
Writer -file-> Reader
|
||||
|
||||
Sender -queue-> Recipient
|
||||
|
||||
/// N-M connectors are modeled as nodes with a given type
|
||||
|
||||
/// the shared "db" connector (Shared is just a label)
|
||||
|
||||
Business Logic -> db Shared -> Analytics
|
||||
|
||||
/// the message "bus" (ESB is just a label)
|
||||
|
||||
Service -> bus ESB -> Microservice
|
||||
|
||||
bus ESB -> Nanoservice
|
||||
|
||||
/// the "web" (API is just a label)
|
||||
|
||||
Browser -> web API -> Web Server
|
||||
|
||||
/// the shared "ram" memory (Buffer is just a label)
|
||||
|
||||
Writer Thread -> ram Buffer -> Reader Thread
|
||||
|
||||
/// the "disruptor"
|
||||
|
||||
Producer Thread -> disruptor Buffer -> Consumer Thread
|
||||
|
||||
disruptor Buffer -> Another Consumer Thread
|
||||
|
||||
/// the "tuple" Space (Space is just a label)
|
||||
/// note that it is possible to label the edges
|
||||
|
||||
Producer -in-> tuple Space -out-> Consumer
|
||||
|
||||
/// the "blockchain"
|
||||
|
||||
Miner -> blockchain -> Smart Contract
|
||||
|
||||
/// Edges can flow in either or both directions
|
||||
/// -> <- <->
|
||||
16
src/sa/model/examples/context.puml
Normal file
16
src/sa/model/examples/context.puml
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
@startuml
|
||||
!include <C4/C4_Container>
|
||||
|
||||
Person(user_s, "Students", "")
|
||||
Person(user_p, "Profs", "")
|
||||
|
||||
System_Boundary(boundary, "ASQ") {
|
||||
|
||||
}
|
||||
|
||||
System_Ext(icorsi, "iCorsi")
|
||||
|
||||
Rel(user_s, boundary, "Answer questions")
|
||||
Rel(user_p, boundary, "Ask questions")
|
||||
Rel(boundary, icorsi, "Import/Export", "Student List, Grades")
|
||||
@enduml
|
||||
33
src/sa/model/examples/feature.fml
Normal file
33
src/sa/model/examples/feature.fml
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
|
||||
/// First the Feature Tree
|
||||
|
||||
/// Adding [*] before the feature name will make it Required
|
||||
/// Adding [ ] before the feature name will mark it as Optional
|
||||
|
||||
/// Composite features can express constraints between their sub-features
|
||||
/// { } a set of exclusive features (pick one)
|
||||
/// ( ) any combination of the features is possible
|
||||
/// [ ] a set of features (usually combined with the [*] [ ] annotation)
|
||||
|
||||
Product: [
|
||||
[*] Required Feature : {
|
||||
Alternative Sub Feature1,
|
||||
Alternative Sub Feature1
|
||||
},
|
||||
[ ] Optional Feature : [
|
||||
[*] Required Sub Feature,
|
||||
[ ] Optional Sub Feature
|
||||
],
|
||||
Combined Feature : (
|
||||
Sub Feature1,
|
||||
Sub Feature2
|
||||
)
|
||||
]
|
||||
|
||||
/// Then the feature relationships
|
||||
|
||||
/// Implication
|
||||
Sub Feature1 => Optional Sub Feature
|
||||
|
||||
/// Exclusive
|
||||
Alternative Sub Feature1 <--> Sub Feature2
|
||||
46
src/sa/model/examples/feature.puml
Normal file
46
src/sa/model/examples/feature.puml
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
|
||||
@startuml
|
||||
rectangle "Feature" as A
|
||||
rectangle "Optional" as B
|
||||
rectangle "Required" as C
|
||||
|
||||
A --0 B
|
||||
A --@ C
|
||||
|
||||
rectangle "Feature" as E
|
||||
note left
|
||||
Sub-features Combination
|
||||
end note
|
||||
rectangle "Sub Feature 1" as F
|
||||
rectangle "Sub Feature 2" as G
|
||||
|
||||
E *-- F
|
||||
E *-- G
|
||||
|
||||
rectangle "Feature" as H
|
||||
note right
|
||||
Exclusive Sub-features
|
||||
end note
|
||||
|
||||
rectangle "Alternative\nSubFeature 1" as I
|
||||
rectangle "Alternative\nSubFeature 2" as J
|
||||
|
||||
H o-- I
|
||||
H o-- J
|
||||
|
||||
F -[dotted]> B : require
|
||||
|
||||
|
||||
C <-[dotted]> J : exclusive
|
||||
|
||||
rectangle "Product" as R
|
||||
|
||||
R --0 A
|
||||
R --0 E : optional
|
||||
R --@ H : required
|
||||
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
skinparam defaultFontName Courier
|
||||
@enduml
|
||||
114
src/sa/model/examples/interface1.puml
Normal file
114
src/sa/model/examples/interface1.puml
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
@startuml
|
||||
hide circle
|
||||
|
||||
class App {
|
||||
|
||||
requires:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
print(PDF)
|
||||
print(id)
|
||||
scheduleJob(PS)
|
||||
|
||||
--
|
||||
properties:
|
||||
..
|
||||
paper_size
|
||||
color
|
||||
duplex
|
||||
|
||||
--
|
||||
events:
|
||||
..
|
||||
print_started
|
||||
print_done
|
||||
|
||||
|
||||
}
|
||||
|
||||
|
||||
class Driver {
|
||||
|
||||
provides:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
print(PDF)
|
||||
|
||||
}
|
||||
|
||||
|
||||
class Spooler {
|
||||
|
||||
provides:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
scheduleJob(PS)
|
||||
|
||||
==
|
||||
|
||||
requires:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
post(PS)
|
||||
|
||||
}
|
||||
|
||||
|
||||
class Queue {
|
||||
|
||||
provides:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
post(PS)
|
||||
get(id)
|
||||
delete(id)
|
||||
|
||||
}
|
||||
|
||||
class Printer {
|
||||
|
||||
provides:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
print(id)
|
||||
|
||||
--
|
||||
properties:
|
||||
..
|
||||
paper_size
|
||||
color
|
||||
duplex
|
||||
|
||||
--
|
||||
events:
|
||||
..
|
||||
print_started
|
||||
print_done
|
||||
|
||||
==
|
||||
|
||||
requires:
|
||||
--
|
||||
operations:
|
||||
..
|
||||
get(id)
|
||||
delete(id)
|
||||
|
||||
}
|
||||
|
||||
App -(0- Driver
|
||||
App -(0- Spooler
|
||||
App -(0- Printer
|
||||
Printer -(0- Queue
|
||||
Spooler -(0- Queue
|
||||
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
@enduml
|
||||
74
src/sa/model/examples/interface2.puml
Normal file
74
src/sa/model/examples/interface2.puml
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
@startuml
|
||||
component App
|
||||
component Driver
|
||||
interface " " as iDriver
|
||||
|
||||
component Spooler
|
||||
interface " " as iSpooler
|
||||
|
||||
component Queue
|
||||
interface " " as iQueue
|
||||
|
||||
component Printer
|
||||
interface " " as iPrinter
|
||||
|
||||
App -( iDriver
|
||||
iDriver - Driver
|
||||
|
||||
App --( iSpooler
|
||||
iSpooler - Spooler
|
||||
|
||||
Spooler --( iQueue
|
||||
iQueue - Queue
|
||||
|
||||
Printer --( iQueue
|
||||
iPrinter - Printer
|
||||
|
||||
App --( iPrinter
|
||||
|
||||
|
||||
note top of iDriver
|
||||
operation:
|
||||
..
|
||||
print(PDF)
|
||||
end note
|
||||
|
||||
note left of iSpooler
|
||||
operation:
|
||||
..
|
||||
scheduleJob(PS)
|
||||
end note
|
||||
|
||||
note left of iQueue
|
||||
operations:
|
||||
..
|
||||
post(PS)
|
||||
get(id)
|
||||
delete(id)
|
||||
end note
|
||||
|
||||
|
||||
note left of iPrinter
|
||||
operation:
|
||||
..
|
||||
print(id)
|
||||
|
||||
--
|
||||
events:
|
||||
..
|
||||
print_started
|
||||
print_done
|
||||
|
||||
--
|
||||
properties:
|
||||
..
|
||||
paper_size
|
||||
color
|
||||
duplex
|
||||
end note
|
||||
|
||||
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
@enduml
|
||||
10
src/sa/model/examples/wiki.fml
Normal file
10
src/sa/model/examples/wiki.fml
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
E-Shop : [
|
||||
[*] Catalogue,
|
||||
[*] Payment: (
|
||||
[*] Bank Transfer, [ ] Credit Card
|
||||
),
|
||||
[*] Security: {
|
||||
High, Standard
|
||||
},
|
||||
[ ] Search
|
||||
]
|
||||
523
src/sa/model/index.md
Normal file
523
src/sa/model/index.md
Normal file
|
|
@ -0,0 +1,523 @@
|
|||
lecture:
|
||||
Software Architecture
|
||||
---
|
||||
title:
|
||||
Model of My Project
|
||||
---
|
||||
author:
|
||||
Enter Your Full Name
|
||||
---
|
||||
|
||||
# Getting started
|
||||
|
||||
You will use [Markdown](https://www.markdownguide.org/cheat-sheetplan), [PlantUML](https://plantuml.com/), [architectural decision records](https://github.com/adr/madr), feature models and connector views to describe a software architecture model about your own project.
|
||||
|
||||
This document will grow during the semester as you sketch and refine your software architecture model.
|
||||
|
||||
When you are done with each task, please push so we can give you feedback about your work.
|
||||
|
||||
We begin by selecting a suitable project domain.
|
||||
|
||||
|
||||
|
||||
# Ex - Domain Selection
|
||||
|
||||
{.instructions
|
||||
|
||||
Submit the name and brief description (about 100 words) of your domain using the following vision statement template:
|
||||
|
||||
```
|
||||
For [target customers]
|
||||
Who [need/opportunity/problem]
|
||||
The [name your project]
|
||||
Is [type of project]
|
||||
That [major features, core benefits, compelling reason to buy]
|
||||
Unlike [current reality or competitors]
|
||||
Our Project [summarize main advantages over status quo, unique selling point]
|
||||
```
|
||||
|
||||
Please indicate if your choice is:
|
||||
|
||||
* a project you have worked on in the past (by yourself or with a team)
|
||||
* a project you are going to work on this semester in another lecture (which one?)
|
||||
* a new project you plan to build in the future
|
||||
* some existing open source project you are interested to contribute to
|
||||
|
||||
The chosen domain should be unique for each student.
|
||||
|
||||
Please be ready to give a 2 minute presentation about it (you can use one slide but it's not necessary)
|
||||
|
||||
Hint: to choose a meaningful project look at the rest of the modeling tasks which you are going to perform in the context of your domain.
|
||||
|
||||
}
|
||||
|
||||
Project Name: *My Project*
|
||||
|
||||
Project Type:
|
||||
|
||||
Vision Statement:
|
||||
|
||||
Additional Information:
|
||||
|
||||
|
||||
|
||||
# Ex - Architectural Decision Records
|
||||
|
||||
{.instructions
|
||||
|
||||
Software architecture is about making design decisions that will impact the quality of the software you plan to build.
|
||||
|
||||
Let's practice how to describe an architectural decision. We will keep using ADRs to document architectural decisions in the rest of the model.
|
||||
|
||||
Use the following template to capture one or more architectural design decisions in the context of your project domain
|
||||
|
||||
Pass: 1 ADR
|
||||
|
||||
Good: 2 ADR
|
||||
|
||||
Exceed: >2 ADR
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
# Ex - Quality Attribute Scenario
|
||||
|
||||
{.instructions
|
||||
|
||||
1. Pick a scenario for a specific quality attribute. Describe it with natural language.
|
||||
|
||||
2. Refine the scenario using the following structure:
|
||||
|
||||
```puml
|
||||
@startuml
|
||||
|
||||
skinparam componentStyle rectangle
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
|
||||
rectangle Environment {
|
||||
|
||||
[Source] -> [System] : Stimulus
|
||||
|
||||
[System] -> [Measure] : Response
|
||||
|
||||
}
|
||||
|
||||
@enduml
|
||||
```
|
||||
|
||||
*Stimulus*: condition affecting the system
|
||||
|
||||
*Source*: entity generating the stimulus
|
||||
|
||||
*Environment*: context under which stimulus occurred (e.g., build, test, deployment, startup, normal operation, overload, failure, attack, change)
|
||||
|
||||
*Response*: observable result of the stimulus
|
||||
|
||||
*Measure*: benchmark or target value defining a successful response
|
||||
|
||||
Pass: 3 scenarios
|
||||
|
||||
Good: >3 scenarios
|
||||
|
||||
Exceed: >6 scenarios using challenging qualities
|
||||
|
||||
}
|
||||
|
||||
## Example Scenario
|
||||
|
||||
Quality: _Recoverability_
|
||||
|
||||
Scenario: In case of power failure, rebooting the system should take up to 20 seconds.
|
||||
|
||||
```puml
|
||||
@startuml
|
||||
|
||||
skinparam componentStyle rectangle
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
|
||||
rectangle "After Power has been restored" {
|
||||
|
||||
rectangle "Admin" as Source
|
||||
rectangle "max 20s" as Measure
|
||||
|
||||
Source -> [System] : "Boot"
|
||||
|
||||
[System] -> [Measure] : "Online"
|
||||
|
||||
}
|
||||
|
||||
@enduml
|
||||
```
|
||||
|
||||
|
||||
# Ex - Quality Attribute Tradeoff
|
||||
|
||||
{.instructions
|
||||
|
||||
Pick a free combination of two qualities on the [map](https://usi365.sharepoint.com/:x:/s/MSDE2023-SoftwareArchitecture/EbK1lRTVOUZJhQoz0XdUBwIBd5vd5yQblOaOwYze4ovbuA?e=6aexs6) and write your name to claim it.
|
||||
|
||||
Then write a short text giving an example for the tradeoff in this assignment.
|
||||
|
||||
Pass: 1 unique trade-off
|
||||
|
||||
Good: 2 trade-offs
|
||||
|
||||
Exceed: >2 trade-offs
|
||||
|
||||
}
|
||||
|
||||
## Portability vs. Performance (Example)
|
||||
|
||||
Developing an app natively for each OS is expensive and time consuming, but it benefits from a good performance. Choosing a cross-platform environment on the other hand simplify the development process, making it faster and cheaper, but it might suffer in performance.
|
||||
|
||||
# Ex - Feature Modeling
|
||||
|
||||
{.instructions
|
||||
|
||||
In the context of your chosen project domain, describe your domain using a feature model.
|
||||
|
||||
The feature model should be correctly visualized using the following template:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If possible, make use of all modeling constructs.
|
||||
|
||||
Pass: Include at least 4 non-trivial features
|
||||
|
||||
Good: Include at least 6 non-trivial features, which are all implemented by your project
|
||||
|
||||
Exceed: Include more than 8 non-trivial features, indicate which are found in your project and which belong to one competitor
|
||||
|
||||
}
|
||||
|
||||
|
||||
# Ex - Context Diagram
|
||||
|
||||
{.instructions
|
||||
|
||||
Prepare a context diagram to define the design boundary for your project.
|
||||
|
||||
Here is a PlantUML/C4 example to get started.
|
||||
|
||||
|
||||
|
||||
Make sure to include all possible user personas and external dependencies you may need.
|
||||
|
||||
Pass: 1 User and 1 Dependency
|
||||
|
||||
Good: >1 User and >1 Dependency
|
||||
|
||||
Exceed: >1 User and >1 Dependency, with both incoming and outgoing dependencies
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
# Ex - Component Model: Top-Down
|
||||
|
||||
{.instructions
|
||||
|
||||
Within the context of your project domain, represent a model of your modular software architecture decomposed into components.
|
||||
|
||||
The number of components in your logical view should be between 6 and 9:
|
||||
|
||||
- At least one component should be further decomposed into sub components
|
||||
- At least one component should already exist. You should plan how to reuse it, by locating it in some software repository and including in your model the exact link to its specification and its price.
|
||||
- At least one component should be stateful.
|
||||
|
||||
The logical view should represent provide/require dependencies that are consistent with the interactions represented in the process view.
|
||||
|
||||
The process view should illustrate how the proposed decomposition is used to satisfy the main use case given by your domain model.
|
||||
|
||||
You can add additional process views showing how other use cases can be satisfied by the same set of components.
|
||||
|
||||
This assignment will focus on modularity-related decisions, we will worry about deployment and the container view later.
|
||||
|
||||
Here is a PlantUML example logical view and process view.
|
||||
|
||||
```puml
|
||||
@startuml
|
||||
skinparam componentStyle rectangle
|
||||
|
||||
!include <tupadr3/font-awesome/database>
|
||||
|
||||
title Example Logical View
|
||||
interface " " as MPI
|
||||
interface " " as SRI
|
||||
interface " " as CDI
|
||||
interface " " as PSI
|
||||
[Customer Database <$database{scale=0.33}>] as CDB
|
||||
[Music Player] as MP
|
||||
[User Interface] as UI
|
||||
[Payment Service] as PS
|
||||
[Songs Repository] as SR
|
||||
MP - MPI
|
||||
CDI - CDB
|
||||
SRI -- SR
|
||||
PSI -- PS
|
||||
MPI )- UI
|
||||
UI --( SRI
|
||||
UI -( CDI
|
||||
MP --( SRI
|
||||
CDB --( PSI
|
||||
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
skinparam defaultFontName Courier
|
||||
@enduml
|
||||
```
|
||||
|
||||
```puml
|
||||
@startuml
|
||||
title Example Process View: Buy and Play the Song
|
||||
|
||||
participant "User Interface" as UI
|
||||
participant "Music Player" as MP
|
||||
participant "Songs Repository" as SR
|
||||
participant "Customer Database" as CDB
|
||||
participant "Payment Service" as PS
|
||||
|
||||
UI -> SR: Browse Songs
|
||||
UI -> CDB: Buy Song
|
||||
CDB -> PS: Charge Customer
|
||||
UI -> MP: Play Song
|
||||
MP -> SR: Get Music
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
skinparam defaultFontName Courier
|
||||
@enduml
|
||||
```
|
||||
|
||||
Hint: How to connect sub-components to other external components? Use this pattern.
|
||||
|
||||
```puml
|
||||
@startuml
|
||||
component C {
|
||||
component S
|
||||
component S2
|
||||
S -(0- S2
|
||||
}
|
||||
interface I
|
||||
S - I
|
||||
|
||||
component C2
|
||||
I )- C2
|
||||
|
||||
skinparam monochrome true
|
||||
skinparam shadowing false
|
||||
skinparam defaultFontName Courier
|
||||
@enduml
|
||||
```
|
||||
|
||||
Pass: 6 components (1 decomposed), 1 use case/process view
|
||||
|
||||
Good: 6 components (1 decomposed), 2 use case/process view
|
||||
|
||||
Exceed: >6 components (>1 decomposed) and >2 use case/process view
|
||||
|
||||
}
|
||||
|
||||
## Logical View
|
||||
|
||||
|
||||
|
||||
## Process Views
|
||||
|
||||
Use Case:
|
||||
|
||||
|
||||
|
||||
# Ex - Component Model: Bottom-Up
|
||||
|
||||
{.instructions
|
||||
|
||||
Within the context of your project domain, represent a model of your modular software architecture decomposed into components.
|
||||
|
||||
To design this model you should attempt to buy and reuse as many components as possible.
|
||||
|
||||
In addition to the logical and process views, you should give a precise list to all sources and prices of the components you have selected to be reused.
|
||||
|
||||
Write an ADR to document your component selection process (indicating which alternatives were considered).
|
||||
|
||||
Pass: Existing design with at least 1 reused components (1 Logical View, 1 Process View)
|
||||
|
||||
Good: Existing design with at least 3 reused components (1 Logical View, 1 Process View, 1 ADR)
|
||||
|
||||
Exceed: Redesign based on >3 reused components (1 Logical View, >1 Process View, >1 ADR)
|
||||
|
||||
}
|
||||
|
||||
|
||||
# Ex - Interface/API Specification
|
||||
|
||||
{.instructions
|
||||
|
||||
In this iteration, we will detail your previous model to specify the provided interface of all components based on their interactions found in your existing process views.
|
||||
|
||||
1. choose whether to use the top down or bottom up model. If you specify the interfaces of the bottom up model, your interface descriptions should match what the components you reuse already offer.
|
||||
|
||||
2. decide which interface elements are operations, properties, or events.
|
||||
|
||||
Get started with one of these PlantUML templates, or you can come up with your own notation to describe the interfaces, as long as it includes all the necessary details.
|
||||
|
||||
The first template describes separately the provided/required interfaces of each component.
|
||||
|
||||
|
||||
|
||||
The second template annotates the logical view with the interface descriptions: less redundant, but needs the logical dependencies to be modeled to show which are the required interfaces.
|
||||
|
||||
|
||||
|
||||
Pass: define interfaces of all outer-level components
|
||||
|
||||
Good: Define interfaces of all outer-level components. Does your architecture publish a Web API? If not, extend it so that it does.
|
||||
|
||||
Exceed: Also, document the Web API using the OpenAPI language. You can use the [OpenAPI-to-Tree](http://api-ace.inf.usi.ch/openapi-to-tree/) tool to visualize the structure of your OpenAPI description.
|
||||
|
||||
}
|
||||
|
||||
# Ex - Connector View
|
||||
|
||||
{.instructions
|
||||
|
||||
Extend your existing models introducing the connector view
|
||||
|
||||
For every pair of connected components (logical view), pick the most suitable connector. Existing components can play the role of connector, or new connectors may need to be introduced.
|
||||
|
||||
|
||||
|
||||
Make sure that the interactions shown in the process views reflect the primitives of the selected connector
|
||||
|
||||
Pass: model existing connectors based on previous model decisions
|
||||
|
||||
Good: model existing connectors based on previous model decisions, write an ADR about the choice of one connector
|
||||
|
||||
Exceed: introduce a new type of connector and update your existing process view
|
||||
(sequence diagram) to show the connector primitives in action
|
||||
|
||||
}
|
||||
|
||||
# Ex - Adapters and Coupling
|
||||
|
||||
{.instructions
|
||||
|
||||
1. Highlight the connectors (or components) in your existing bottom-up design playing the role of adapter. (We suggest to use the bottom-up design since when dealing with externally sourced components, their interfaces can be a source of mismatches).
|
||||
2. Which kind of mismatch** are they solving?
|
||||
3. Introduce a wrapper in your architecture to hide one of the previously highlighted adapters
|
||||
4. Where would standard interfaces play a role in your architecture? Which standards could be relevant in your domain?
|
||||
5. Explain how one or more pairs of components are coupled according to different coupling facets
|
||||
6. Provide more details on how each adapter solves the mismatches identified using pseudo-code or the actual code
|
||||
7. How can you improve your architectural model to minimize coupling between components? (Include a revised logical/connector view with your solution)
|
||||
|
||||
Pass: 1-5 (with one adapter)
|
||||
|
||||
Good: 1-6 (with at least two adapters)
|
||||
|
||||
Exceed: 1-7 (with at least two adapters)
|
||||
|
||||
** If you do not find any mismatch in your existing design we suggest to introduce one artificially.
|
||||
|
||||
## Hints
|
||||
|
||||
* (1) Should we find cases where two components cannot communicate (and are doing it wrongly) and highlight they would need an adapter?, or cases where we have already a "component playing the role of adapter in the view" and highlight only the adapter?
|
||||
|
||||
*Both are fine. We assumed that if you draw a dependency (or a connector) the interfaces match, but if you detect that the components that should communicate cannot communicate then of course introduce an adapter to solve the mismatch*
|
||||
|
||||
* (2) Please show the details about the two interfaces which do not match (e.g., names of parameters, object structures) so that it becomes clear why an adapter is needed and what the adapter should do to bridge the mismatch
|
||||
|
||||
* (5-6) These questions are about the implications on coupling based on the decisions you documented in the connector view.
|
||||
Whenever you have a connector you couple together the components and different connectors will have different forms of coupling
|
||||
|
||||
For example, if you use calls everywhere, do you really need them everywhere? is there some pair of components where you could use a message queue instead?
|
||||
|
||||
Regarding the coupling facets mentioned in question 5. You do not have to answer all questions related to "discovery", "session", "binding", "interaction", "timing", "interface" and "platform" (p.441, Coupling Facets). Just the ones that you think are relevant for your design and by answering them you can get ideas on how to do question 6.
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
# Ex - Physical and Deployment Views
|
||||
|
||||
{.instructions
|
||||
|
||||
a. Extend your architectural model with the following viewpoints:
|
||||
|
||||
1. Physical or Container View
|
||||
|
||||
2. Deployment View
|
||||
|
||||
Your model should be non-trivial: include more than one physical device/virtual container (or both). Be ready to discuss which connectors are found at the device/container boundaries.
|
||||
|
||||
b. Write an ADR about which deployment strategy you plan to adopt. The alternatives to be considered are: big bang, blue/green, shadow, pilot, gradual phase-in, canary, A/B testing.
|
||||
|
||||
c. (Optional) Prepare a demo of a basic continuous integration and delivery pipeline for your architectural documentation so that you can obtain a single, integrated PDF with all the viewpoints you have modeled so far.
|
||||
|
||||
For example:
|
||||
|
||||
- configure a GitHub webhook to be called whenever you push changes to your documentation
|
||||
- setup a GitHub action (or similar) to build and publish your documentation on a website
|
||||
|
||||
Pass: 1 physical view, 1 deployment view, 1 ADR (b.)
|
||||
|
||||
Good: >1 physical view, >1 deployment view, 1 ADR (b.)
|
||||
|
||||
Exceed: 1 physical view, 1 deployment view, 1 ADR (b.) + 1 demo (c.)
|
||||
|
||||
}
|
||||
|
||||
# Ex - Availability and Services
|
||||
|
||||
{.instructions
|
||||
|
||||
The goal of this week is to plan how to deliver your software as a service with high availability.
|
||||
|
||||
1. If necessary, change your deployment design so that your software is hosted on a server (which could be running as a Cloud VM). Your SaaS architecture should show how your SaaS can be remotely accessed from a client such as a Web browser, or a mobile app
|
||||
2. Sketch your software as a service pricing model (optional)
|
||||
3. How would you define the availability requirements in your project domain? For example, what would be your expectation for the duration of planned/unplanned downtimes or the longest response time tolerated by your clients?
|
||||
4. Which strategy do you adopt to monitor your service's availability? Extend your architecture with a watchdog or a heartbeat monitor and motivate your choice with an ADR.
|
||||
5. What happens when a stateless component goes down? model a sequence diagram to show what needs to happen to recover one of your critical stateless components
|
||||
6. How do you plan to recover stateful components? write an ADR about your choice of replication strategy and whether you prefer consistency vs. availability. Also, consider whether event sourcing would help in your context.
|
||||
7. How do you plan to avoid cascading failures? Be ready to discuss how the connectors (modeled in your connector view) impact the reliability of your architecture.
|
||||
8. How did you mitigate the impact of your external dependencies being not available? (if applicable)
|
||||
|
||||
Pass: 1, 3, 4, one of: 5, 6, 7, 8
|
||||
|
||||
Good: 1, 2, 3, 4, two of: 5, 6, 7, 8
|
||||
|
||||
Exceed: 1, 2, 3, 4, 5, 6, 7, 8
|
||||
|
||||
}
|
||||
|
||||
# Ex - Flexibility
|
||||
|
||||
{.instructions
|
||||
|
||||
Only dead software stops changing. You just received a message from your customer, they have an idea. Is your architecture ready for it?
|
||||
|
||||
1. Pick a new use case scenario. Precisely, what exactly do you need to change of your existing architecture so that it can be supported? Model the updated logical/process/deployment views.
|
||||
|
||||
2. Pick another use case scenario so that it can be supported without any major architectural change (i.e., while you cannot add new components, it is possible to extend the interface of existing ones or introduce new dependencies). Illustrate with a process view, how your previous design can satisfy the new requirement.
|
||||
|
||||
3. Change impact. One of your externally sourced component/Web service API has announced it will introduce a breaking change. What is the impact of such change? How can you control and limit the impact of such change? Update your logical view
|
||||
|
||||
4. Open up your architecture so that it can be extended with plugins by its end-users. Where would be a good extension point? Update your logical view and give at least one example of what a plugin would actually do.
|
||||
|
||||
5. Assuming you have a centralized deployment with all stateful components storing their state in the same database, propose a strategy to split the monolith into at least two different microservices. Model the new logical/deployment view as well as the interfaces of each microservice you introduce.
|
||||
|
||||
Pass: 1, one out of 2-5.
|
||||
|
||||
Good: 1, two out of 2-5.
|
||||
|
||||
Exceed: 1-5.
|
||||
|
||||
}
|
||||
248
template/doc.ejs
Normal file
248
template/doc.ejs
Normal file
|
|
@ -0,0 +1,248 @@
|
|||
<html>
|
||||
|
||||
<head>
|
||||
<title><%=meta.author%> - <%=meta.title%></title>
|
||||
<link rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Fira+Sans|Fira+Mono">
|
||||
<link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.2.0/build/styles/default.min.css">
|
||||
<style>
|
||||
body,
|
||||
* {
|
||||
font-family: "Fira Sans";
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
body {
|
||||
margin: 1em;
|
||||
}
|
||||
|
||||
#usi-logo {
|
||||
width: 75px;
|
||||
height: 75px;
|
||||
}
|
||||
|
||||
header {
|
||||
display: flex;
|
||||
align-content: space-between;
|
||||
width: 100%;
|
||||
justify-items: center;
|
||||
}
|
||||
|
||||
header ul {
|
||||
list-style: none;
|
||||
}
|
||||
|
||||
header .title {
|
||||
flex: 1;
|
||||
margin-left: 1em;
|
||||
}
|
||||
|
||||
html {
|
||||
min-height: 100vh;
|
||||
}
|
||||
|
||||
pre,
|
||||
code {
|
||||
font-family: "Fira Mono"
|
||||
}
|
||||
|
||||
pre {
|
||||
background: rgb(202, 227, 255);
|
||||
padding: 1em;
|
||||
}
|
||||
|
||||
td {
|
||||
text-align: center
|
||||
}
|
||||
|
||||
td:last-child {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
th {
|
||||
font-weight: normal;
|
||||
color: rgb(0, 61, 131);
|
||||
}
|
||||
|
||||
thead {
|
||||
border-bottom: 2px solid rgb(202, 227, 255);
|
||||
}
|
||||
|
||||
table {
|
||||
width: 100%
|
||||
}
|
||||
|
||||
span.task {
|
||||
display: inline-flex;
|
||||
border-radius: 50%;
|
||||
border: 1px solid white;
|
||||
background: #ffbc00;
|
||||
width: 2em;
|
||||
height: 2em;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
font-weight: normal;
|
||||
margin-top: 2em;
|
||||
}
|
||||
|
||||
section.feedback {
|
||||
padding: 2em;
|
||||
background-color: rgb(92, 192, 223);
|
||||
background-image: linear-gradient(1deg, white, transparent,rgba(255,255,255,0.5) 90%,transparent 100%);
|
||||
}
|
||||
|
||||
section.instructions {
|
||||
padding: 2em;
|
||||
background-color: rgb(255, 241, 196);
|
||||
background-image: linear-gradient(1deg, white, transparent,rgba(255,255,255,0.5) 90%,transparent 100%);
|
||||
}
|
||||
|
||||
section.instructions::before {
|
||||
content: "Task Description";
|
||||
font-size: 1.75em;
|
||||
color: #ffbc00;
|
||||
font-weight: bold;
|
||||
transform: translateY(-2em) rotate(1deg);
|
||||
display: block;
|
||||
margin-bottom: -2em;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
section.pass, section.exceed, section.ok {
|
||||
margin-top: 1em;
|
||||
}
|
||||
|
||||
section.pass span, section.exceed span, section.hint span, section.ok span {
|
||||
margin-right: 0.5em;
|
||||
padding: 0.5em;
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
section.pass {
|
||||
border: 2px solid green;
|
||||
}
|
||||
|
||||
section.ok {
|
||||
border: 2px solid rgb(6, 175, 6);
|
||||
}
|
||||
|
||||
section.exceed {
|
||||
border: 2px solid rgb(34, 255, 34);
|
||||
}
|
||||
|
||||
section.hint {
|
||||
border: 2px solid rgb(255, 214, 34);
|
||||
}
|
||||
|
||||
section.pass span {
|
||||
background-color: green; color: white;
|
||||
background-image: linear-gradient(45deg, #000000a6, transparent);
|
||||
}
|
||||
|
||||
section.ok span {
|
||||
background-color: rgb(6, 175, 6); color: white;
|
||||
background-image: linear-gradient(135deg, #000000a6, transparent);
|
||||
}
|
||||
|
||||
section.exceed span {
|
||||
background-color: rgb(34, 255, 34);
|
||||
background-image: linear-gradient(-45deg, white, transparent);
|
||||
}
|
||||
|
||||
section.hint span {
|
||||
background-color: rgb(255, 214, 34);
|
||||
background-image: linear-gradient(-45deg, white, transparent);
|
||||
}
|
||||
|
||||
.deadline {
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
p.deadline {
|
||||
font-size: 2em;
|
||||
}
|
||||
|
||||
.deadline b {
|
||||
border-bottom: 1px solid black;
|
||||
}
|
||||
|
||||
form label {
|
||||
display: inline-block;
|
||||
margin-right: 1em;
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
border-left: 10px solid #fff2ca;
|
||||
padding-left: 2em;
|
||||
margin: 1em;
|
||||
}
|
||||
|
||||
|
||||
form button {
|
||||
min-width: 10em;
|
||||
min-height: 2em;
|
||||
background: #008d4f;
|
||||
color: white;
|
||||
font-weight: bold;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
form input[type=text],
|
||||
form textarea,
|
||||
form select {
|
||||
flex: 3;
|
||||
margin: 0.5em;
|
||||
font-size: 1.1em;
|
||||
}
|
||||
|
||||
form p { display: flex;
|
||||
align-items: stretch;
|
||||
min-height: 2.5em;
|
||||
padding-left: 0.5em;
|
||||
flex-direction: column}
|
||||
|
||||
nav .task {display: unset; background:white}
|
||||
|
||||
nav .d1 {display: block}
|
||||
nav .d1 + .d2 {margin-left: 2em}
|
||||
nav .d2 {margin-left: 1em}
|
||||
|
||||
footer {
|
||||
text-align: center; color: gray;
|
||||
}
|
||||
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<header> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" id="usi-logo" x="0px" y="0px" width="200" height="200" viewBox="0 0 200 200" style="enable-background:new 0 0 200 200;" xml:space="preserve" class="injected-svg svg">
|
||||
<g>
|
||||
<path d="M180,41.7h-51.1V31.1h42.2C153.1,12.5,127.8,1,99.9,1C45.2,1.1,0.9,45.4,1,100.1c0,26.8,10.7,51.1,28.1,68.9 c-1.4-2-2.4-4.1-3-6.1c-1-3.5-1-5.9-1.1-15.8v-47.1h14.8v48.5c0,3.4-0.1,6.6,1,9.6c3,7.6,11.3,8.5,16,8.5c2.3,0,8.3-0.1,12.6-3.9 c4.4-3.9,4.4-8.4,4.4-15v-47.7h14.9v49.7c-0.1,8.9-0.1,16.3-8.5,23.5c-8,7-18.4,7.7-23.8,7.7c-4.8,0-9.5-0.6-14-2.1 c-1.8-0.6-3.5-1.4-5-2.3c17.1,14,39,22.4,62.8,22.4c54.7-0.1,99-44.4,98.9-99.1C199,78.1,191.9,58,180,41.7z M175.3,94.4l-6.3-9 c2.1-1.4,8.7-5.7,8.7-17.7c0-2-0.2-4.1-1-6.2c-1.7-4.1-4.6-4.9-6.6-4.9c-3.6,0-4.9,2.5-5.7,4.3c-0.5,1.3-0.6,1.5-1.8,6.6l-1.5,6.9 c-0.9,3.6-1.3,5.4-2,7.2c-1.1,2.6-4.5,9.6-14,9.6c-10.9,0-17.8-9.2-17.8-22.6c0-12.3,6.1-19,11.6-23l6.6,8.8 c-2.8,1.9-8.5,5.7-8.5,14.8c0,5.8,2.6,10.8,7,10.8c4.9,0,5.8-5.3,6.8-10.5l1.3-5.9c1.6-7.7,4.8-18.6,17-18.6 c13.1,0,18.4,12.2,18.4,24.3c0,3.2-0.3,6.7-1.3,10.2C185.1,83.4,182.3,90.1,175.3,94.4z"></path>
|
||||
</g>
|
||||
</svg>
|
||||
<div class="title">
|
||||
<h2><%=meta.lecture%></h2>
|
||||
<h1><%=meta.title%></h1>
|
||||
</div>
|
||||
<ul>
|
||||
<li><%=meta.author%></li>
|
||||
</ul>
|
||||
</header>
|
||||
|
||||
<nav>
|
||||
<h1>Table of Contents</h1>
|
||||
<%-toc.toc %>
|
||||
</nav>
|
||||
|
||||
<main>
|
||||
<%-md %>
|
||||
</main>
|
||||
|
||||
|
||||
<footer>
|
||||
<%=meta.timestamp%>
|
||||
</footer>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
Reference in a new issue