commit 18b301594d4f9d1cbde9b7ae3159eae03a9523ce parent 4e6c9e3221f1cb1a4786be7381ac39621de8387f Author: Alex Balgavy <alex@balgavy.eu> Date: Thu, 30 Dec 2021 16:00:20 +0100 Add software design notes Diffstat:
108 files changed, 1140 insertions(+), 4016 deletions(-)
diff --git a/content/_index.md b/content/_index.md @@ -38,7 +38,7 @@ title = "Alex's university course notes" * [Operating Systems](os-notes) * [Intelligent Systems](is-notes/) * [Linear Algebra](lin-algebra-notes/) -* [Software Design](https://thezeroalpha.github.io/softdesign-notes) +* [Software Design](softdesign-notes) * [Logic & Modelling](logic-modelling-notes/) * [Databases](databases-notes) * [A Likelihood Approach to Statistics (Honors)](likelihood-notes/notes.pdf) diff --git a/content/softdesign-notes/_index.md b/content/softdesign-notes/_index.md @@ -0,0 +1,60 @@ ++++ +title = 'Software Design' ++++ +# Software Design +[Here](software-design.apkg) is my [Anki](https://apps.ankiweb.net) deck that I'm using to prepare for the exam. + +- [Software abstraction & modeling](software-abstraction-modeling) + - [Models](software-abstraction-modeling#models) +- [Software development process](software-development-process) + - [Waterfall development process](software-development-process#waterfall-development-process) + - [Agile development process](software-development-process#agile-development-process) +- [Requirements engineering with UML](requirements-engineering) + - [What is UML?](requirements-engineering#what-is-uml) + - [Requirements engineering](requirements-engineering#requirements-engineering) + - [Natural language specification](requirements-engineering#natural-language-specification) + - [Use case diagrams](requirements-engineering#use-case-diagrams) + - [Summary of notation](requirements-engineering#summary-of-notation) +- [Structure modeling with UML](structure-modeling) + - [Class](structure-modeling#class) + - [Attribute syntax](structure-modeling#attribute-syntax) + - [Operation syntax](structure-modeling#operation-syntax) + - [Class variable and class operation](structure-modeling#class-variable-and-class-operation) + - [Relationships](structure-modeling#relationships) + - [Binary association](structure-modeling#binary-association) + - [n-ary association](structure-modeling#n-ary-association) + - [Association class](structure-modeling#association-class) + - [Aggregation](structure-modeling#aggregation) + - [Shared aggregation](structure-modeling#shared-aggregation) + - [Composition](structure-modeling#composition) + - [Generalization](structure-modeling#generalization) + - [Creating a class diagram](structure-modeling#creating-a-class-diagram) +- [Object-oriented design patterns in UML](oo-design-patterns#object-oriented-design-patterns-in-uml) + - [Creational](oo-design-patterns#creational) + - [Singleton](oo-design-patterns#singleton) + - [Factory method](oo-design-patterns#factory-method) + - [Structural](oo-design-patterns#structural) + - [Adapter](oo-design-patterns#adapter) + - [Behavioral](oo-design-patterns#behavioral) + - [Observer](oo-design-patterns#observer) + - [Chain of responsibility](oo-design-patterns#chain-of-responsibility) +- [Modeling behavior with UML State Machines](modeling-behavior-state-machines#modeling-behavior-with-uml-state-machines) + - [Introduction](modeling-behavior-state-machines#introduction) + - [States](modeling-behavior-state-machines#states) + - [Transitions](modeling-behavior-state-machines#transitions) + - [Types of events](modeling-behavior-state-machines#types-of-events) + - [Types of states](modeling-behavior-state-machines#types-of-states) + - [Entry and exit points](modeling-behavior-state-machines#entry-and-exit-points) +- [Sequence Diagrams](sequence-diagrams#sequence-diagrams) + - [Introduction](sequence-diagrams#introduction) + - [Basics](sequence-diagrams#basics) + - [Interactions, interaction partners](sequence-diagrams#interactions-interaction-partners) + - [Messages](sequence-diagrams#messages) + - [Combined fragments](sequence-diagrams#combined-fragments) + - [Branches & loops](sequence-diagrams#branches-loops) + - [Concurrency and order](sequence-diagrams#concurrency-and-order) + - [Filters and assertions](sequence-diagrams#filters-and-assertions) + - [Further language elements](sequence-diagrams#further-language-elements) +- [Philosophy of Software Design](philosophy-of-software-design#philosophy-of-software-design) + - [Summary of Design Principles](philosophy-of-software-design#summary-of-design-principles) + - [Summary of red flags](philosophy-of-software-design#summary-of-red-flags) diff --git a/content/softdesign-notes/addjs.sh b/content/softdesign-notes/addjs.sh @@ -1,10 +0,0 @@ -#!/usr/bin/env bash -if ! command -v vim; then - echo "Don't know how to do this without vim yet." - exit 1 -elif [ $# -ne 1 ]; then - echo "Need to pass the file as argument." - exit 1 -fi - -vim -c 'v/<head> <script/ s#<head>#<head> <script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>' -c 'wq' $1 diff --git a/content/softdesign-notes/index.html b/content/softdesign-notes/index.html @@ -1,216 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>index</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Software Design"><h1 id="Software Design">Software Design</h1></div> -<p> -<a href="software-design.apkg">Here</a> is my <a href="https://apps.ankiweb.net">Anki</a> deck that I'm using to prepare for the exam. -</p> - -<ul> -<li> -<a href="software-abstraction-modeling.html#Software abstraction & modeling">Software abstraction & modeling</a> - -<ul> -<li> -<a href="software-abstraction-modeling.html#Software abstraction & modeling-Models">Models</a> - -</ul> -<li> -<a href="software-development-process.html#Software development process">Software development process</a> - -<ul> -<li> -<a href="software-development-process.html#Software development process-Waterfall development process">Waterfall development process</a> - -<li> -<a href="software-development-process.html#Software development process-Agile development process">Agile development process</a> - -</ul> -<li> -<a href="requirements-engineering.html#Requirements engineering with UML">Requirements engineering with UML</a> - -<ul> -<li> -<a href="requirements-engineering.html#Requirements engineering with UML-What is UML?">What is UML?</a> - -<li> -<a href="requirements-engineering.html#Requirements engineering with UML-Requirements engineering">Requirements engineering</a> - -<ul> -<li> -<a href="requirements-engineering.html#Requirements engineering with UML-Requirements engineering-Natural language specification">Natural language specification</a> - -<li> -<a href="requirements-engineering.html#Requirements engineering with UML-Requirements engineering-Use case diagrams">Use case diagrams</a> - -</ul> -<li> -<a href="requirements-engineering.html#Requirements engineering with UML-Summary of notation">Summary of notation</a> - -</ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML">Structure modeling with UML</a> - -<ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Class">Class</a> - -<ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Class-Attribute syntax">Attribute syntax</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Class-Operation syntax">Operation syntax</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Class-Class variable and class operation">Class variable and class operation</a> - -</ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships">Relationships</a> - -<ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Binary association">Binary association</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-n-ary association">n-ary association</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Association class">Association class</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Aggregation">Aggregation</a> - -<ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Aggregation-Shared aggregation">Shared aggregation</a> - -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Aggregation-Composition">Composition</a> - -</ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Relationships-Generalization">Generalization</a> - -</ul> -<li> -<a href="structure-modeling.html#Structure modeling with UML-Creating a class diagram">Creating a class diagram</a> - -</ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML">Object-oriented design patterns in UML</a> - -<ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Creational">Creational</a> - -<ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Creational-Singleton">Singleton</a> - -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Creational-Factory method">Factory method</a> - -</ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Structural">Structural</a> - -<ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Structural-Adapter">Adapter</a> - -</ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Behavioral">Behavioral</a> - -<ul> -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Behavioral-Observer">Observer</a> - -<li> -<a href="oo-design-patterns.html#Object-oriented design patterns in UML-Behavioral-Chain of responsibility">Chain of responsibility</a> - -</ul> -</ul> -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines">Modeling behavior with UML State Machines</a> - -<ul> -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-Introduction">Introduction</a> - -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-States">States</a> - -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-Transitions">Transitions</a> - -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-Types of events">Types of events</a> - -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-Types of states">Types of states</a> - -<li> -<a href="modeling-behavior-state-machines.html#Modeling behavior with UML State Machines-Entry and exit points">Entry and exit points</a> - -</ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams">Sequence Diagrams</a> - -<ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Introduction">Introduction</a> - -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Basics">Basics</a> - -<ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Basics-Interactions, interaction partners">Interactions, interaction partners</a> - -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Basics-Messages">Messages</a> - -</ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Combined fragments">Combined fragments</a> - -<ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Combined fragments-Branches & loops">Branches & loops</a> - -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Combined fragments-Concurrency and order">Concurrency and order</a> - -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Combined fragments-Filters and assertions">Filters and assertions</a> - -</ul> -<li> -<a href="sequence-diagrams.html#Sequence Diagrams-Further language elements">Further language elements</a> - -</ul> -<li> -<a href="philosophy-of-software-design.html#Philosophy of Software Design">Philosophy of Software Design</a> - -<ul> -<li> -<a href="philosophy-of-software-design.html#Philosophy of Software Design-Summary of Design Principles">Summary of Design Principles</a> - -<li> -<a href="philosophy-of-software-design.html#Philosophy of Software Design-Summary of red flags">Summary of red flags</a> - -</ul> -</ul> - -</body> -</html> diff --git a/content/softdesign-notes/modeling-behavior-state-machines.html b/content/softdesign-notes/modeling-behavior-state-machines.html @@ -1,399 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>modeling-behavior-state-machines</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Modeling behavior with UML State Machines"><h2 id="Modeling behavior with UML State Machines">Modeling behavior with UML State Machines</h2></div> -<div id="Modeling behavior with UML State Machines-Introduction"><h3 id="Introduction">Introduction</h3></div> -<p> -every object has finite set of states during life. -</p> - -<p> -state machine diagram is used to: -</p> -<ul> -<li> -model possible states of system/object - -<li> -show how state transitions occur as consequence of events - -<li> -show behavior of system in each state - -</ul> - -<p> -<img src="img/simple-example.png" alt="Simple example" /> -</p> - -<div id="Modeling behavior with UML State Machines-States"><h3 id="States">States</h3></div> -<p> -states are the nodes of state machine -</p> - -<p> -when a state is active: -</p> -<ul> -<li> -object is in that state - -<li> -all internal activities in that state can be executed: - -<ul> -<li> -<code>entry/Activity</code> - when object enters the state - -<li> -<code>do/Activity</code> - while object remains in this state - -<li> -<code>exit/Activity</code> - when object exits the state - -</ul> -</ul> - -<div id="Modeling behavior with UML State Machines-Transitions"><h3 id="Transitions">Transitions</h3></div> -<p> -change from one state to another -</p> - -<p> -<img src="img/transition-diagram.png" alt="Transition diagram" /> -</p> - -<p> -Syntax of transitions: -</p> -<blockquote> -<img src="img/syntax-of-transitions.png" alt="Syntax of transitions" /> -</blockquote> - -<ul> -<li> -Event (trigger) - -<ul> -<li> -can trigger state transition - -</ul> -<li> -Guard (condition) - -<ul> -<li> -boolean expression - -<li> -if event occurs, guard is checked - -<li> -if guard is true: - -<ol> -<li> -all activities in current state are terminated - -<li> -exit activity is executed - -<li> -transition happens - -</ol> -</ul> -<li> -Activity (effect) - -<ul> -<li> -sequence of actions that happen during transition - -</ul> -</ul> - -<p> -Types: -</p> -<ul> -<li> -internal: - -</ul> -<blockquote> -<img src="img/internal-state-transition.png" alt="Internal state transition" /> -</blockquote> - -<ul> -<li> -if <code>event1</code> happens, object stays in <code>state1</code> and <code>Activity3</code> runs - -</ul> - -<ul> -<li> -external: - -</ul> -<blockquote> -<img src="img/external-state-transition.png" alt="External state transition" /> -</blockquote> - -<ul> -<li> -if <code>event1</code> happens: - -<ul> -<li> -object leaves <code>state1</code>, <code>Activity2</code> runs - -<li> -<code>Activity3</code> runs - -<li> -object enters <code>state1</code> and <code>Activity1</code> runs - -</ul> -</ul> - -<p> -Timing of transitions: -</p> - -<p> -<img src="img/table-of-transition-timing.png" alt="Table of transition timing" /> -</p> - -<div id="Modeling behavior with UML State Machines-Types of events"><h3 id="Types of events">Types of events</h3></div> -<ul> -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Signal event:"></span><strong id="Signal event:">Signal event:</strong> receipt of a signal (<code>rightmousedown</code>, <code>sendSMS(message)</code>) - -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Call event:"></span><strong id="Call event:">Call event:</strong> operation call (<code>occupy(user, lectureHall)</code>, <code>register(exam)</code>) - -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Time event:"></span><strong id="Time event:">Time event:</strong> time-based state transition (relative or absolute time) - -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Any receive event:"></span><strong id="Any receive event:">Any receive event:</strong> when any event occurs that doesn't trigger another transition from the active state - -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Completion event:"></span><strong id="Completion event:">Completion event:</strong> automatic when everything is completed in the current state - -<li> -<span id="Modeling behavior with UML State Machines-Types of events-Change event:"></span><strong id="Change event:">Change event:</strong> permanently checking when a condition becomes true - -</ul> - -<p> -A change event is permanently checked. A guard is only checked when the event occurs. -</p> - -<div id="Modeling behavior with UML State Machines-Types of states"><h3 id="Types of states">Types of states</h3></div> -<p> -Initial state: -</p> -<ul> -<li> -"start" of the diagram - -<li> -pseudo-state, system can't remain in this state - -<li> -no incoming edges - -<li> -outgoing edges have to be mutually exclusive and at least one target must be reachable. no events allowed. - -<li> -system immediately switches from initial state. - -<li> -notation: <img src="img/initial-state-notation.png" alt="Initial state notation" /> - -</ul> - -<p> -Final state: -</p> -<ul> -<li> -real state - -<li> -end of sequence of states - -<li> -can remain in this state forever - -<li> -notation: <img src="img/final-state-notation.png" alt="Final state notation" /> - -</ul> - -<p> -Terminate node: -</p> -<ul> -<li> -pseudo-state - -<li> -terminates state machine - -<li> -modeled object is deleted - -<li> -notation: <img src="img/terminate-node-notation.png" alt="Terminate node notation" /> - -</ul> - -<p> -Decision node: -</p> -<ul> -<li> -pseudo-state - -<li> -used for alternative transitions - -<li> -notation: <img src="img/decision-node-notation.png" alt="Decision node notation" /> - -</ul> - -<p> -Parallelization node: -</p> -<ul> -<li> -pseudo-state - -<li> -splits control flow into multiple concurrent flows - -<li> -1 incoming edge, >1 outgoing edges - -<li> -notation: <img src="img/parallelization-node-notation.png" alt="Parallelization node notation" /> - -</ul> - -<p> -Synchronization node: -</p> -<ul> -<li> -pseudo-state - -<li> -merges multiple concurrent flows - -<li> ->1 incoming edge, 1 outgoing edge - -<li> -notation: <img src="img/synchronization-node-notation.png" alt="Synchronization node notation" /> - -</ul> - -<p> -Composite state: -</p> -<ul> -<li> -contains substates, with only one of them active at any time - -<li> -arbitrary nesting depth - -<li> -higher level events take priority - -</ul> -<blockquote> -<img src="img/composite-state-diagram.png" alt="Composite state diagram" /> -</blockquote> - -<p> -Orthogonal state: -</p> -<ul> -<li> -composite state divided into two or more regions, separated by dashed line - -<li> -one state of each region is always active at some point (concurrent substates) - -<li> -final state has to be reached in all regions to trigger completion - -</ul> -<blockquote> -<img src="img/orthogonal-state-diagram.png" alt="Orthogonal state diagram" /> -</blockquote> - -<p> -Submachine state (SMS) -</p> -<ul> -<li> -to reuse parts of state machine diagrams in other ones - -<li> -as soon as submachine state is activated, behavior of submachine is executed (subroutine) - -<li> -notation: <code>state:submachineState</code> - -</ul> -<blockquote> -<img src="img/submachine-state-diagram.png" alt="Submachine state diagram" /> -</blockquote> - -<p> -History state: -</p> -<ul> -<li> -remembers the last active substate of a composite state - -<li> -activates 'old' substate and all entry activities run sequentially from outside to inside of composite state - -<li> -exactly one outgoing edge of history state points to a substate. used if the composite state was never active, or it was exited via final state. - -<li> -shallow history state restores state on the same level of the composite state (<code>H</code>) - -<li> -deep history state restores last active substate over <em>all levels</em> (<code>H*</code>) - -</ul> - -<div id="Modeling behavior with UML State Machines-Entry and exit points"><h3 id="Entry and exit points">Entry and exit points</h3></div> -<p> -Encapsulation mechanism: a composite state shall be entered/exited via a state other than initial and final states. -</p> - -<p> -external transition must/need not know structure of composite state. -</p> - -</body> -</html> diff --git a/content/softdesign-notes/img/composite-state-diagram.png b/content/softdesign-notes/modeling-behavior-state-machines/composite-state-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/decision-node-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/decision-node-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/external-state-transition.png b/content/softdesign-notes/modeling-behavior-state-machines/external-state-transition.png Binary files differ. diff --git a/content/softdesign-notes/img/final-state-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/final-state-notation.png Binary files differ. diff --git a/content/softdesign-notes/modeling-behavior-state-machines/index.md b/content/softdesign-notes/modeling-behavior-state-machines/index.md @@ -0,0 +1,146 @@ ++++ +title = 'Modeling behavior with UML State Machines' ++++ +## Modeling behavior with UML State Machines +### Introduction +every object has finite set of states during life. + +state machine diagram is used to: +* model possible states of system/object +* show how state transitions occur as consequence of events +* show behavior of system in each state + + + +### States +states are the nodes of state machine + +when a state is active: +* object is in that state +* all internal activities in that state can be executed: + * `entry/Activity` - when object enters the state + * `do/Activity` - while object remains in this state + * `exit/Activity` - when object exits the state + +### Transitions +change from one state to another + + + +Syntax of transitions: + + + +* Event (trigger) + * can trigger state transition +* Guard (condition) + * boolean expression + * if event occurs, guard is checked + * if guard is true: + 1. all activities in current state are terminated + 2. exit activity is executed + 3. transition happens +* Activity (effect) + * sequence of actions that happen during transition + +Types: +* internal: + +  + + * if `event1` happens, object stays in `state1` and `Activity3` runs + +* external: + +  + + * if `event1` happens: + * object leaves `state1`, `Activity2` runs + * `Activity3` runs + * object enters `state1` and `Activity1` runs + +Timing of transitions: + + + +### Types of events +* *Signal event:* receipt of a signal (`rightmousedown`, `sendSMS(message)`) +* *Call event:* operation call (`occupy(user, lectureHall)`, `register(exam)`) +* *Time event:* time-based state transition (relative or absolute time) +* *Any receive event:* when any event occurs that doesn't trigger another transition from the active state +* *Completion event:* automatic when everything is completed in the current state +* *Change event:* permanently checking when a condition becomes true + +A change event is permanently checked. A guard is only checked when the event occurs. + +### Types of states +Initial state: +* "start" of the diagram +* pseudo-state, system can't remain in this state +* no incoming edges +* outgoing edges have to be mutually exclusive and at least one target must be reachable. no events allowed. +* system immediately switches from initial state. +* notation:  + +Final state: +* real state +* end of sequence of states +* can remain in this state forever +* notation:  + +Terminate node: +* pseudo-state +* terminates state machine +* modeled object is deleted +* notation:  + +Decision node: +* pseudo-state +* used for alternative transitions +* notation:  + +Parallelization node: +* pseudo-state +* splits control flow into multiple concurrent flows +* 1 incoming edge, >1 outgoing edges +* notation:  + +Synchronization node: +* pseudo-state +* merges multiple concurrent flows +* >1 incoming edge, 1 outgoing edge +* notation:  + +Composite state: +* contains substates, with only one of them active at any time +* arbitrary nesting depth +* higher level events take priority + + + +Orthogonal state: +* composite state divided into two or more regions, separated by dashed line +* one state of each region is always active at some point (concurrent substates) +* final state has to be reached in all regions to trigger completion + + + +Submachine state (SMS) +* to reuse parts of state machine diagrams in other ones +* as soon as submachine state is activated, behavior of submachine is executed (subroutine) +* notation: `state:submachineState` + + + +History state: +* remembers the last active substate of a composite state +* activates 'old' substate and all entry activities run sequentially from outside to inside of composite state +* exactly one outgoing edge of history state points to a substate. used if the composite state was never active, or it was exited via final state. +* shallow history state restores state on the same level of the composite state (`H`) +* deep history state restores last active substate over _all levels_ (`H*`) + +### Entry and exit points +Encapsulation mechanism: a composite state shall be entered/exited via a state other than initial and final states. + +external transition must/need not know structure of composite state. + diff --git a/content/softdesign-notes/img/initial-state-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/initial-state-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/internal-state-transition.png b/content/softdesign-notes/modeling-behavior-state-machines/internal-state-transition.png Binary files differ. diff --git a/content/softdesign-notes/img/orthogonal-state-diagram.png b/content/softdesign-notes/modeling-behavior-state-machines/orthogonal-state-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/parallelization-node-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/parallelization-node-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/simple-example.png b/content/softdesign-notes/modeling-behavior-state-machines/simple-example.png Binary files differ. diff --git a/content/softdesign-notes/img/submachine-state-diagram.png b/content/softdesign-notes/modeling-behavior-state-machines/submachine-state-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/synchronization-node-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/synchronization-node-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/syntax-of-transitions.png b/content/softdesign-notes/modeling-behavior-state-machines/syntax-of-transitions.png Binary files differ. diff --git a/content/softdesign-notes/img/table-of-transition-timing.png b/content/softdesign-notes/modeling-behavior-state-machines/table-of-transition-timing.png Binary files differ. diff --git a/content/softdesign-notes/img/terminate-node-notation.png b/content/softdesign-notes/modeling-behavior-state-machines/terminate-node-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/transition-diagram.png b/content/softdesign-notes/modeling-behavior-state-machines/transition-diagram.png Binary files differ. diff --git a/content/softdesign-notes/oo-design-patterns.html b/content/softdesign-notes/oo-design-patterns.html @@ -1,472 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>oo-design-patterns</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Object-oriented design patterns in UML"><h2 id="Object-oriented design patterns in UML">Object-oriented design patterns in UML</h2></div> -<p> -design pattern: a reusable form of solution to a common design problem (like a 'template') -</p> - -<p> -not a finished design, cannot be transformed directly into source code -</p> - -<p> -not prescriptive, so don't memorize them. it's important to understand when and why they're needed. -</p> - -<p> -speaking of, they're not always needed. don't over-complicate shit, you'll end up with a dumpster fire that nobody can maintain. -</p> - -<p> -essential parts of a design pattern -</p> -<ul> -<li> -Pattern name - -<ul> -<li> -provides common vocab for software designers - -</ul> -<li> -Intent - -<ul> -<li> -What does the design pattern do? - -<li> -What is its rationale and intent? - -<li> -What design issue/problem does it address? - -</ul> -<li> -Solution - -<ul> -<li> -the basic elements providing solution to the problem (structure, participants, collaborations) - -</ul> -<li> -Consequences - -<ul> -<li> -results and trade offs by applying the pattern - -</ul> -</ul> - -<div id="Object-oriented design patterns in UML-Creational"><h3 id="Creational">Creational</h3></div> -<p> -how objects can be created (maintainability, control, extensibility) -</p> - -<p> -we study the singleton and factory method. then there are also abstract factory, object pool, and prototype. -</p> - -<div id="Object-oriented design patterns in UML-Creational-Singleton"><h4 id="Singleton">Singleton</h4></div> -<table> -<tr> -<th> -Name -</th> -<th> -Singleton -</th> -</tr> -<tr> -<td> -Intent -</td> -<td> -To ensure that only one instance of a class is allowed in a system. <br>Controlled access to a single object is needed -</td> -</tr> -<tr> -<td> -Solution -</td> -<td> -<img src="img/singleton-solution-diagram.png" alt="Singleton solution diagram" /> -</td> -</tr> -<tr> -<td> -Consequences -</td> -<td> -Controlled access to sole instance <br> Reduced name space (fewer 'global' variables) <br> permits variable number of instances -</td> -</tr> -</table> - -<p> -Implementation -</p> - -<pre java> -public class SingleObject { - // private constructor, cannot be instantiated from outside - private SingleObject(){} - - // create the one single instance - private static SingleObject instance = new SingleObject(); - - // get the only instance - public static SingleObject getInstance() { - return instance; - } - - public void showMessage() { - System.out.println("Hello world!"); - } -</pre> - -<div id="Object-oriented design patterns in UML-Creational-Factory method"><h4 id="Factory method">Factory method</h4></div> -<table> -<tr> -<th> -Name -</th> -<th> -Factory method -</th> -</tr> -<tr> -<td> -Intent -</td> -<td> -to abstract process of object creation so that type of created object can be determined at run time <br> to make design more customizable in terms of which objects can be created <br> avoiding the <code>new</code> operator because you don't want to hard code the class to be instantiated -</td> -</tr> -<tr> -<td> -Solution -</td> -<td> -<img src="img/factory-method-diagram.png" alt="Factory method diagram" /> -</td> -</tr> -<tr> -<td> -Consequences -</td> -<td> -end up with dedicated class to create instances of objects <br> can pass arguments to the class to control the features of the objects -</td> -</tr> -</table> - -<p> -Implementation -</p> - -<pre java> -public class ShapeFactory { - public Shape getShape(String shapeTYpe) { - if (shapeType == null) { - return null; - } - if (shapeType.equalsIgnoreCase("CIRCLE")) { - return new Circle(); - } - else if (shapeType.equalsIgnoreCase("RECTANGLE")) { - return new Rectangle(); - } - else if (shapeType.equalsIgnoreCase("SQUARE")) { - return new Square(); - } - - return null; - } -} -</pre> - -<div id="Object-oriented design patterns in UML-Structural"><h3 id="Structural">Structural</h3></div> -<p> -how to form larger structures (management of complexity, efficiency) -</p> - -<p> -adapter is studied in this course. also have proxy, bridge, decorator, facade, flyweight, composite, private class data. -</p> - -<div id="Object-oriented design patterns in UML-Structural-Adapter"><h4 id="Adapter">Adapter</h4></div> -<table> -<tr> -<th> -Name -</th> -<th> -Adapter -</th> -</tr> -<tr> -<td> -Intent -</td> -<td> -to convert interface of class into another interface <br> to let two or more classes with incompatible interfaces work together <br> to wrap an existing class with a new one <br> to have a kinda homogeneous interface that masks diversity of some set of various objects -</td> -</tr> -<tr> -<td> -Solution -</td> -<td> -<img src="img/adapter-diagram-1.png" alt="Adapter diagram 1" /> <img src="img/adapter-diagram-2.png" alt="Adapter diagram 2" /> -</td> -</tr> -<tr> -<td> -Consequences -</td> -<td> -single class is responsible to join functionalities of independent/incompatible classes -</td> -</tr> -</table> - -<p> -Implementation -</p> - -<pre java> -public class Wrapper { - // the wrapped object - private LegacyComponent legacyComponent; - - // constructor - public Wrapper (LegacyComponent instance) { - this.legacyComponent = instance; - } - - // call to wrapped method - public int doThis() { - int result = 0; - float value = this.legacyComponent.doThat(); - // magic the value into an integer somehow, then - return result; - } -} -</pre> - -<div id="Object-oriented design patterns in UML-Behavioral"><h3 id="Behavioral">Behavioral</h3></div> -<p> -how responsibilities can be assigned to objects (objects decoupling, flexibility, better communication) -</p> - -<p> -we study observer and chain of responsibility. there are also command, interpreter, iterator, mediator, memento, null object, state, strategy, template method, and visitor. -</p> - -<div id="Object-oriented design patterns in UML-Behavioral-Observer"><h4 id="Observer">Observer</h4></div> -<table> -<tr> -<th> -Name -</th> -<th> -Observer -</th> -</tr> -<tr> -<td> -Intent -</td> -<td> -to let some object(s) be notified of state changes in other objects in the system <br> when on object changes state, all dependents are notified and updated automatically -</td> -</tr> -<tr> -<td> -Solution -</td> -<td> -<img src="img/observer-diagram.png" alt="Observer diagram" /> -</td> -</tr> -<tr> -<td> -Consequences -</td> -<td> -supports broadcast communication <br> state changes in object(s) should trigger behavior in other objects <br> you can reuse objects without reusing their observers and v-v. <br> you can remove observers without changing the subjects -</td> -</tr> -</table> - -<p> -Implementation -</p> - -<pre java> -public abstract class Observer { - protected Subject subject; - public abstract void update(); -} - -class MappingRover extends Observer { - // specify observed subject in constructor - public MappingRover(Subject subject) P - this.subject = subject; - subject.attach(this); - } - - // observers "pull" information - public void update() { - if (this.subject.getState() == 0) { - // map the environment - } - else { - // "come back home", whatever that means - } - } -} -public abstract class Subject { - private List<Observer> observers = new ArrayList<Observer>(); - private int state; - - public int getState() { ... } - public void setState(int state) { ... } // and notify all observers - public void attach(Observer observer) { ... } // add to observers list - public void detach(Observer observer) { ... } //remove from observers list - - public void notifyAllObservers() { ... } // run the update function for each observer in list -} - -public static void main(String[] args) { - CentralStation cs = new CentralStation(); - cs.setState(0); - - MappingRover rover1 = new MappingRover(cs); - CameraRover rover2 = new CameraRover(cs); - CameraRover rover3 = new CameraRover(cs); - - cs.setState(1); -} -</pre> - -<div id="Object-oriented design patterns in UML-Behavioral-Chain of responsibility"><h4 id="Chain of responsibility">Chain of responsibility</h4></div> -<table> -<tr> -<th> -Name -</th> -<th> -Chain of responsibility -</th> -</tr> -<tr> -<td> -Intent -</td> -<td> -avoid coupling sender of request to receiver by giving more than one object a chance to handle request <br> chain receiving objects and pass request along chain until an object handles it (sequential) -</td> -</tr> -<tr> -<td> -Solution -</td> -<td> -<img src="img/chain-of-responsibility-diagram.png" alt="Chain of responsibility diagram" /> -</td> -</tr> -<tr> -<td> -Consequences -</td> -<td> -Reduced coupling between objects (every object needs to know its successor) <br> handler(s) are not known a priori and a request might be unhandled <br> you can change responsibilities by changing chain at runtime -</td> -</tr> -</table> - -<p> -Implementation -</p> - -<pre java> -public class Task { - private Coordinate coords; - private RequestEnum request; - - // basic getters and setters - public Coordinate getcoords() { ... } - public setCoords(Coordinate coords) { ... } - - public RequestEnum getRequest() { ... } - public setRequest(RequestEnum request) { ... } -} - -public enum RequestEnum { - PICTURE, MAP; -} - -public class Coordinate { - private float lat, lon; - - // basic getters and setters - public float getLat() { ... }; - public setLat(float lat) { ... }; - public float getLon() { ... }; - public setLon(float lon) { ... }; -} - -public abstract class TaskHandler { - TaskHandler successor; - publicc void setSuccessor(TaskHandler successor) { - this.successor = successor; - } - public abstract void handleRequest(Task task); -} - -public class CameraRover extends TaskHandler { - public void handleRequest(Task task) { - if (task.request == RequestEnum.PICTURE) { - // take a picture - } - else { - // pass on to successor - if (successor != null) { - successor.handleRequest(request); - } - } - } -} - -public class Main { - public static TaskHandler setUpChain() { - MapRover mapper = new MapRover(); - CameraRover photographer1 = new CameraRover(); - CameraRover photographer2 = new CameraRover(); - CameraRover photographer3 = new CameraRover(); - - return mapper; - } - public static void main(Striing[] args) { - TaskHandler chain = setUpChain; - - chain.handleRequest(...); - } -} -</pre> - -</body> -</html> diff --git a/content/softdesign-notes/img/adapter-diagram-1.png b/content/softdesign-notes/oo-design-patterns/adapter-diagram-1.png Binary files differ. diff --git a/content/softdesign-notes/img/adapter-diagram-2.png b/content/softdesign-notes/oo-design-patterns/adapter-diagram-2.png Binary files differ. diff --git a/content/softdesign-notes/img/chain-of-responsibility-diagram.png b/content/softdesign-notes/oo-design-patterns/chain-of-responsibility-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/factory-method-diagram.png b/content/softdesign-notes/oo-design-patterns/factory-method-diagram.png Binary files differ. diff --git a/content/softdesign-notes/oo-design-patterns/index.md b/content/softdesign-notes/oo-design-patterns/index.md @@ -0,0 +1,261 @@ ++++ +title = 'Object-oriented design patterns in UML' ++++ +## Object-oriented design patterns in UML +design pattern: a reusable form of solution to a common design problem (like a 'template') + +not a finished design, cannot be transformed directly into source code + +not prescriptive, so don't memorize them. it's important to understand when and why they're needed. + +speaking of, they're not always needed. don't over-complicate shit, you'll end up with a dumpster fire that nobody can maintain. + +essential parts of a design pattern +* Pattern name + * provides common vocab for software designers +* Intent + * What does the design pattern do? + * What is its rationale and intent? + * What design issue/problem does it address? +* Solution + * the basic elements providing solution to the problem (structure, participants, collaborations) +* Consequences + * results and trade offs by applying the pattern + +### Creational +how objects can be created (maintainability, control, extensibility) + +we study the singleton and factory method. then there are also abstract factory, object pool, and prototype. + +#### Singleton +<table> +<tr><th>Name</th><th>Singleton</th></tr> +<tr><td>Intent</td><td>To ensure that only one instance of a class is allowed in a system. <br>Controlled access to a single object is needed</td></tr> +<tr><td>Solution</td><td><img src="./singleton-solution-diagram.png">Singleton solution diagram</td></tr> +<tr><td>Consequences</td><td>Controlled access to sole instance <br> Reduced name space (fewer 'global' variables) <br> permits variable number of instances</td></tr> +</table> + +Implementation + +```java +public class SingleObject { + // private constructor, cannot be instantiated from outside + private SingleObject(){} + + // create the one single instance + private static SingleObject instance = new SingleObject(); + + // get the only instance + public static SingleObject getInstance() { + return instance; + } + + public void showMessage() { + System.out.println("Hello world!"); + } +``` + +#### Factory method +<table> +<tr><th>Name</th><th>Factory method</th></tr> +<tr><td>Intent</td><td>to abstract process of object creation so that type of created object can be determined at run time <br> to make design more customizable in terms of which objects can be created <br> avoiding the `new` operator because you don't want to hard code the class to be instantiated</td></tr> +<tr><td>Solution</td><td><img src="factory-method-diagram.png">Factory method diagram</td></tr> +<tr><td>Consequences</td><td>end up with dedicated class to create instances of objects <br> can pass arguments to the class to control the features of the objects</td></tr> +</table> + +Implementation + +```java +public class ShapeFactory { + public Shape getShape(String shapeTYpe) { + if (shapeType == null) { + return null; + } + if (shapeType.equalsIgnoreCase("CIRCLE")) { + return new Circle(); + } + else if (shapeType.equalsIgnoreCase("RECTANGLE")) { + return new Rectangle(); + } + else if (shapeType.equalsIgnoreCase("SQUARE")) { + return new Square(); + } + + return null; + } +} +``` + +### Structural +how to form larger structures (management of complexity, efficiency) + +adapter is studied in this course. also have proxy, bridge, decorator, facade, flyweight, composite, private class data. + +#### Adapter +<table> +<tr><th>Name</th><th>Adapter</th></tr> +<tr><td>Intent</td><td>to convert interface of class into another interface <br> to let two or more classes with incompatible interfaces work together <br> to wrap an existing class with a new one <br> to have a kinda homogeneous interface that masks diversity of some set of various objects</td></tr> +<tr><td>Solution</td><td><img src="adapter-diagram-1.png">Adapter diagram 1 <img src="adapter-diagram-2.png">Adapter diagram 2</td></tr> +<tr><td>Consequences</td><td>single class is responsible to join functionalities of independent/incompatible classes</td></tr> +</table> + +Implementation + +```java +public class Wrapper { + // the wrapped object + private LegacyComponent legacyComponent; + + // constructor + public Wrapper (LegacyComponent instance) { + this.legacyComponent = instance; + } + + // call to wrapped method + public int doThis() { + int result = 0; + float value = this.legacyComponent.doThat(); + // magic the value into an integer somehow, then + return result; + } +} +``` + +### Behavioral +how responsibilities can be assigned to objects (objects decoupling, flexibility, better communication) + +we study observer and chain of responsibility. there are also command, interpreter, iterator, mediator, memento, null object, state, strategy, template method, and visitor. + +#### Observer +<table> +<tr><th>Name</th><th>Observer</th></tr> +<tr><td>Intent</td><td>to let some object(s) be notified of state changes in other objects in the system <br> when on object changes state, all dependents are notified and updated automatically</td></tr> +<tr><td>Solution</td><td><img src="observer-diagram.png">Observer diagram</td></tr> +<tr><td>Consequences</td><td>supports broadcast communication <br> state changes in object(s) should trigger behavior in other objects <br> you can reuse objects without reusing their observers and v-v. <br> you can remove observers without changing the subjects</td></tr> +</table> + +Implementation + +```java +public abstract class Observer { + protected Subject subject; + public abstract void update(); +} + +class MappingRover extends Observer { + // specify observed subject in constructor + public MappingRover(Subject subject) P + this.subject = subject; + subject.attach(this); + } + + // observers "pull" information + public void update() { + if (this.subject.getState() == 0) { + // map the environment + } + else { + // "come back home", whatever that means + } + } +} +public abstract class Subject { + private List<Observer> observers = new ArrayList<Observer>(); + private int state; + + public int getState() { ... } + public void setState(int state) { ... } // and notify all observers + public void attach(Observer observer) { ... } // add to observers list + public void detach(Observer observer) { ... } //remove from observers list + + public void notifyAllObservers() { ... } // run the update function for each observer in list +} + +public static void main(String[] args) { + CentralStation cs = new CentralStation(); + cs.setState(0); + + MappingRover rover1 = new MappingRover(cs); + CameraRover rover2 = new CameraRover(cs); + CameraRover rover3 = new CameraRover(cs); + + cs.setState(1); +} +``` + +#### Chain of responsibility +<table> +</tr><th>Name</th><th>Chain of responsibility</th></tr> +</tr><td>Intent</td><td>avoid coupling sender of request to receiver by giving more than one object a chance to handle request <br> chain receiving objects and pass request along chain until an object handles it (sequential)</td></tr> +</tr><td>Solution</td><td><img src="chain-of-responsibility-diagram.png">Chain of responsibility diagram</td></tr> +</tr><td>Consequences</td><td>Reduced coupling between objects (every object needs to know its successor) <br> handler(s) are not known a priori and a request might be unhandled <br> you can change responsibilities by changing chain at runtime</td></tr> +</table> + +Implementation + +```java +public class Task { + private Coordinate coords; + private RequestEnum request; + + // basic getters and setters + public Coordinate getcoords() { ... } + public setCoords(Coordinate coords) { ... } + + public RequestEnum getRequest() { ... } + public setRequest(RequestEnum request) { ... } +} + +public enum RequestEnum { + PICTURE, MAP; +} + +public class Coordinate { + private float lat, lon; + + // basic getters and setters + public float getLat() { ... }; + public setLat(float lat) { ... }; + public float getLon() { ... }; + public setLon(float lon) { ... }; +} + +public abstract class TaskHandler { + TaskHandler successor; + publicc void setSuccessor(TaskHandler successor) { + this.successor = successor; + } + public abstract void handleRequest(Task task); +} + +public class CameraRover extends TaskHandler { + public void handleRequest(Task task) { + if (task.request == RequestEnum.PICTURE) { + // take a picture + } + else { + // pass on to successor + if (successor != null) { + successor.handleRequest(request); + } + } + } +} + +public class Main { + public static TaskHandler setUpChain() { + MapRover mapper = new MapRover(); + CameraRover photographer1 = new CameraRover(); + CameraRover photographer2 = new CameraRover(); + CameraRover photographer3 = new CameraRover(); + + return mapper; + } + public static void main(Striing[] args) { + TaskHandler chain = setUpChain; + + chain.handleRequest(...); + } +} +``` + diff --git a/content/softdesign-notes/img/observer-diagram.png b/content/softdesign-notes/oo-design-patterns/observer-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/singleton-solution-diagram.png b/content/softdesign-notes/oo-design-patterns/singleton-solution-diagram.png Binary files differ. diff --git a/content/softdesign-notes/philosophy-of-software-design.html b/content/softdesign-notes/philosophy-of-software-design.html @@ -1,105 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>philosophy-of-software-design</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Philosophy of Software Design"><h1 id="Philosophy of Software Design">Philosophy of Software Design</h1></div> -<div id="Philosophy of Software Design-Summary of Design Principles"><h2 id="Summary of Design Principles">Summary of Design Principles</h2></div> -<ul> -<li> -Complexity is incremental, even small things make a difference - -<li> -Working code isn't enough, don't introduce complexity just to finish faster - -<li> -Make continual small investments to improve system design - -<li> -Modules should be deep (provide powerful functionality, yet have simple interfaces) - -<li> -Interfaces should be designed to make most common usage as simple as possible - -<li> -simple interace > simple implementation (for a module) - -<li> -General-purpose modules are deeper - -<li> -Separate general-purpose and special-purpose code - -<li> -Different layers should have different abstractions. If two adjacent layers have similar abstractions, there's probably a probem with class decomposition. - -<li> -Pull complexity downward, make life as easy as possible for the user - -<li> -Define errors (and special cases) out of existence (when they pop up) - -<li> -Design it twice, consider multiple options for each major design decision - -<li> -Comments should describe things that are not obvious from the code - -<li> -Software should be designed for ease of reading, not ease of writing - -<li> -Increments of software development should be abstractions, not features. It's ok to put off an abstraction until it's needed by a feature, but once it's needed, take the time to design it cleanly. - -</ul> - -<div id="Philosophy of Software Design-Summary of red flags"><h2 id="Summary of red flags">Summary of red flags</h2></div> -<ul> -<li> -Shallow module: one whose interface is complicated relative to the functionality it provides - -<li> -Information leakage: when the same knowledge is used in multiple places (e.g. two different classes both understand format of a particular type of file) - -<li> -Temporal decomposition: execution order is reflected in the code structure, which can lead to information leakage - -<li> -Overexposure: if API for commonly used features forces users to learn about other features that are rarely used, it increases cognotive load on the users - -<li> -Repetition: if the same piece of code appears multiple times, you probably haven't found the right abstraction - -<li> -Special-general mixture: when a general-purpose mechanism contains code specialised for a particular use of that mechanism, which makes it more complicated and creates information leakage - -<li> -Conjoined methods: it should be possible to understand each method independently, and if you can't, that's a red flag - -<li> -Comment repeats code: if information in a comment is already obvious from the code, that comment is useless - -<li> -Implementation documentation contaminates interface: when interface documentation describes implementation details that aren't needed to use what's being documented - -<li> -Vague name: if variable/method name is broad enough to refer to different things, it doesn't convey much info to the developer - -<li> -Hard to pick name: if it's hard to find a simple name for variable/method that creates a clear image of the underlying object, the underlying object may not have a clean design - -<li> -Hard to describe: comment describing method/variable should be simple and complete. If that's hard, there may be a problem with what you're describing - -<li> -Nonobvious code: if meaning and behavior of code can't be understood when skimming, it's a red flag. - -</ul> - -</body> -</html> diff --git a/content/softdesign-notes/philosophy-of-software-design.md b/content/softdesign-notes/philosophy-of-software-design.md @@ -0,0 +1,35 @@ ++++ +title = 'Philosophy of Software Design' ++++ +# Philosophy of Software Design +## Summary of Design Principles +- Complexity is incremental, even small things make a difference +- Working code isn't enough, don't introduce complexity just to finish faster +- Make continual small investments to improve system design +- Modules should be deep (provide powerful functionality, yet have simple interfaces) +- Interfaces should be designed to make most common usage as simple as possible +- simple interace > simple implementation (for a module) +- General-purpose modules are deeper +- Separate general-purpose and special-purpose code +- Different layers should have different abstractions. If two adjacent layers have similar abstractions, there's probably a probem with class decomposition. +- Pull complexity downward, make life as easy as possible for the user +- Define errors (and special cases) out of existence (when they pop up) +- Design it twice, consider multiple options for each major design decision +- Comments should describe things that are not obvious from the code +- Software should be designed for ease of reading, not ease of writing +- Increments of software development should be abstractions, not features. It's ok to put off an abstraction until it's needed by a feature, but once it's needed, take the time to design it cleanly. + +## Summary of red flags +- Shallow module: one whose interface is complicated relative to the functionality it provides +- Information leakage: when the same knowledge is used in multiple places (e.g. two different classes both understand format of a particular type of file) +- Temporal decomposition: execution order is reflected in the code structure, which can lead to information leakage +- Overexposure: if API for commonly used features forces users to learn about other features that are rarely used, it increases cognotive load on the users +- Repetition: if the same piece of code appears multiple times, you probably haven't found the right abstraction +- Special-general mixture: when a general-purpose mechanism contains code specialised for a particular use of that mechanism, which makes it more complicated and creates information leakage +- Conjoined methods: it should be possible to understand each method independently, and if you can't, that's a red flag +- Comment repeats code: if information in a comment is already obvious from the code, that comment is useless +- Implementation documentation contaminates interface: when interface documentation describes implementation details that aren't needed to use what's being documented +- Vague name: if variable/method name is broad enough to refer to different things, it doesn't convey much info to the developer +- Hard to pick name: if it's hard to find a simple name for variable/method that creates a clear image of the underlying object, the underlying object may not have a clean design +- Hard to describe: comment describing method/variable should be simple and complete. If that's hard, there may be a problem with what you're describing +- Nonobvious code: if meaning and behavior of code can't be understood when skimming, it's a red flag. diff --git a/content/softdesign-notes/requirements-engineering.html b/content/softdesign-notes/requirements-engineering.html @@ -1,466 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>requirements-engineering</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Requirements engineering with UML"><h2 id="Requirements engineering with UML">Requirements engineering with UML</h2></div> - -<div id="Requirements engineering with UML-What is UML?"><h3 id="What is UML?">What is UML?</h3></div> -<p> -A unified modeling language, the defacto standard for software design. -</p> - -<p> -pros: -</p> -<ul> -<li> -not tied to a development process - -<li> -can be used across the whole life cycle - -<li> -general purpose, can model all sorts of shit - -<li> -has different representations (graphical, but also text) - -</ul> - -<p> -main characteristics: -</p> -<ul> -<li> -comprehensive: can describe all parts of a system - -<li> -scalable: "zoom in" and add more details if you want - -<li> -originally intended for descriptive models - -<li> -now also supports prescriptive models - -</ul> - -<p> -formal modeling language — its core concepts have a well-defined meaning -</p> - -<p> -UML model is represented graphically with diagrams -</p> - -<p> -The different types: -</p> - -<p> -<img src="img/uml-diagrams.png" alt="Diagram of diagrams" /> -</p> - -<p> -The ones we will use: -</p> -<ul> -<li> -use case diagram: to specify the basic functionality of a software system (requirements) - -<li> -class diagram: to define data structures within the system - -<li> -state machine diagram: to define intra-object behavior - -<li> -sequence diagram: to specify inter-object behavior and communication - -</ul> - -<p> -a UML <em>model</em> contains everything related to the system. a <em>diagram</em> is just a "window" on the model (shows some parts, but not necessarily everything). -</p> - -<div id="Requirements engineering with UML-Requirements engineering"><h3 id="Requirements engineering">Requirements engineering</h3></div> -<p> -the process of establishing: -</p> -<ul> -<li> -features that a system should and will have - -<li> -constraints under which it operates and is developed - -</ul> - -<p> -requirement can range between: -</p> -<ul> -<li> -high-level abstract statement of a feature - -<li> -detailed mathematical functional specification - -</ul> - -<p> -functional (what) vs non-functional (how) requirements -</p> -<ul> -<li> -functional: services the system should provide, how it should react to inputs, how it should behave in specific situations, opt. what it shouldn't do. - -<ul> -<li> -precise — ambiguous requirements may be interpreted in different ways by developers and users - -<li> -complete — they should include descriptions of <em>all</em> facilities required - -<li> -consistent — there should be no conflicts or contradictions in descriptions of system facilities - -<li> -verifiable — requirements should be directly mapped to parts of system - -</ul> -<li> -non-functional: constraints on services/functions offered by the system, often apply to system as a whole instead of individual features/services - -<ul> -<li> -system properties and constraints (e.g. reliability, response time, storage requirements) - -<li> -may be more critical than functional, like safety requirements - -<li> -may affect overall architecture of a system instead of individual components (like organization to minimize communications between robots) - -<li> -different types: - -</ul> -</ul> -<blockquote> -<img src="img/non-func-requirements.png" alt="Non-functional requirement types" /> -</blockquote> - -<p> -in UML: use case diagrams for functional requirements. -</p> - -<p> -How to write requirements specifications: -</p> - -<table> -<tr> -<th> -<span id="Requirements engineering with UML-Requirements engineering-Notation"></span><strong id="Notation">Notation</strong> -</th> -<th> -<span id="Requirements engineering with UML-Requirements engineering-Description"></span><strong id="Description">Description</strong> -</th> -</tr> -<tr> -<td> -Natural language -</td> -<td> -Use numbered sentences in natural language. Each sentence is one requirement. -</td> -</tr> -<tr> -<td> -Structured natural language. -</td> -<td> -Requirements are written in natural language on standard form/template. Each field gives info about an aspect of the requirement. -</td> -</tr> -<tr> -<td> -Design description languages -</td> -<td> -Use language like programming language, but with more abstract features specifying requirements by defining an operational model of the system. -</td> -</tr> -<tr> -<td> -Graphical notations -</td> -<td> -Graphical models with text annotations. e.g. UML use case and sequence diagrams. -</td> -</tr> -<tr> -<td> -Mathematical specifications -</td> -<td> -Based on math concepts like finite-state machines or sets. Most customers don't understand this so not often used. -</td> -</tr> -</table> - -<div id="Requirements engineering with UML-Requirements engineering-Natural language specification"><h4 id="Natural language specification">Natural language specification</h4></div> -<p> -requirements are written as natural language sentences. used because it's expressive, intuitive, universal, easily understood by customers. -</p> - -<p> -guidelines: -</p> -<ul> -<li> -invent a standard format, use it for all requirements. - -<li> -use language in a consistent way ("shall" for mandatory requirements, "should" for desirable requirements) - -<li> -highlight text to identify important parts of requirement - -<li> -avoid use of computer jargon - -<li> -include explanation (rationale) of why a requirement is needed - -</ul> - -<div id="Requirements engineering with UML-Requirements engineering-Use case diagrams"><h4 id="Use case diagrams">Use case diagrams</h4></div> -<p> -express expectations of customers/stakeholders. -</p> - -<p> -answers questions: -</p> -<ul> -<li> -what is being described? (the system) - -<li> -who interacts with the system? (the actors) - -<li> -what can the actors do? (use cases) - -</ul> - -<p> -use case: -</p> -<ul> -<li> -describes functionality expected from system under development - -<li> -set of all use cases describes functionality that a system shall provide. - -<li> -notations: - -</ul> -<blockquote> -<img src="img/use-case-notations.png" alt="Use case notations" /> -</blockquote> - -<p> -actors: -</p> -<ul> -<li> -interact with the system by using use cases, or by being used by use cases. - -<li> -represent roles that users adopt (users can have multiple roles) - -<li> -not part of the system, so outside of system boundaries. - -<li> -human or non-human - -<li> -primary/secondary: - -<ul> -<li> -if primary, has main benefit of execution of use case. - -<li> -if secondary, receives no direct benefit. - -</ul> -<li> -active or passive - -<ul> -<li> -active: initiates execution of the use case - -<li> -passive: provides functionality for the execution of the use case - -</ul> -</ul> -<blockquote> -<img src="img/actor-notations.png" alt="Actor notations" /> -</blockquote> - -<p> -relationships between use cases and actors: -</p> -<ul> -<li> -actors are connected with use cases via associations (solid lines) - -<li> -every actors has to communicate with at least one use case - -<li> -association is always binary, multiplicities can be specified - -</ul> -<blockquote> -<img src="img/usecase-actor-rel.png" alt="Relationships between actors and use cases" /> -</blockquote> - -<p> -relationships between use cases: -</p> -<ul> -<li> -«include» - -<ul> -<li> -behavior of one use case ('included') <em>is always</em> integrated in the behavior of another use case ('base') - -</ul> -</ul> -<blockquote> -<img src="img/usecase-include-rel.png" alt="Include relationship" /> -</blockquote> -<ul> -<li> -«extend» - -<ul> -<li> -behavior of one use case ('extending') <em>may be</em> integrated in behavior of another use case ('base') - -<li> -both use cases can also be executed independently of each other - -<li> -extension points are written directly in the use case. you can specify multiple extension points. - -</ul> -</ul> -<blockquote> -<img src="img/use-case-extensions.png" alt="Extensions in use cases" /> -</blockquote> -<ul> -<li> -generalization of use cases - -<ul> -<li> -if use case A generalizes use case B, then B inherits behavior of A and may extend/overwrite it. B also inherits all relationships form A. - -<li> -A may be labeled {abstract} — cannot be executed directly, only B is executable - -</ul> -</ul> -<blockquote> -<img src="img/usecase-generalisation.png" alt="Generalisation" /> -</blockquote> - -<p> -relationships between actors -</p> -<ul> -<li> -generalization - -<ul> -<li> -actor A inherits from actor B. e.g. A can communicate with X and Y, B can only communicate with Y. - -<li> -abstract actors are possible - -</ul> -</ul> -<blockquote> -<img src="img/actor-generalization.png" alt="Actor generalization" /> -</blockquote> - -<p> -Description of use cases: -</p> -<ul> -<li> -Name - -<li> -Short description - -<li> -Precondition: prerequisite for successful execution - -<li> -Postcondition: system state after successful execution - -<li> -Error situations: errors relevant to problem domain - -<li> -System state on occurrence of an error - -<li> -Actors that communicate with the use case - -<li> -Trigger: events which initiate the use case - -<li> -Standard process: individual steps to be taken - -<li> -Alternative processes: deviations from the standard process - -</ul> - -<p> -Remember, it's an abstraction. Many small use cases with the same objective should be grouped. Don't decompose functionality into use cases. -</p> - -<div id="Requirements engineering with UML-Summary of notation"><h3 id="Summary of notation">Summary of notation</h3></div> -<p> -<img src="img/requirement-notation-p1.png" alt="Requirements notation" /> -</p> - -<p> -<img src="img/requirement-notation-p2.png" alt="Requirements notation" /> -</p> - -</body> -</html> diff --git a/content/softdesign-notes/img/actor-generalization.png b/content/softdesign-notes/requirements-engineering/actor-generalization.png Binary files differ. diff --git a/content/softdesign-notes/img/actor-notations.png b/content/softdesign-notes/requirements-engineering/actor-notations.png Binary files differ. diff --git a/content/softdesign-notes/requirements-engineering/index.md b/content/softdesign-notes/requirements-engineering/index.md @@ -0,0 +1,160 @@ ++++ +title = 'Requirements engineering with UML' ++++ +## Requirements engineering with UML + +### What is UML? +A unified modeling language, the defacto standard for software design. + +pros: +* not tied to a development process +* can be used across the whole life cycle +* general purpose, can model all sorts of shit +* has different representations (graphical, but also text) + +main characteristics: +* comprehensive: can describe all parts of a system +* scalable: "zoom in" and add more details if you want +* originally intended for descriptive models +* now also supports prescriptive models + +formal modeling language — its core concepts have a well-defined meaning + +UML model is represented graphically with diagrams + +The different types: + + + +The ones we will use: +* use case diagram: to specify the basic functionality of a software system (requirements) +* class diagram: to define data structures within the system +* state machine diagram: to define intra-object behavior +* sequence diagram: to specify inter-object behavior and communication + +a UML _model_ contains everything related to the system. a _diagram_ is just a "window" on the model (shows some parts, but not necessarily everything). + +### Requirements engineering +the process of establishing: +* features that a system should and will have +* constraints under which it operates and is developed + +requirement can range between: +* high-level abstract statement of a feature +* detailed mathematical functional specification + +functional (what) vs non-functional (how) requirements +* functional: services the system should provide, how it should react to inputs, how it should behave in specific situations, opt. what it shouldn't do. + * precise — ambiguous requirements may be interpreted in different ways by developers and users + * complete — they should include descriptions of _all_ facilities required + * consistent — there should be no conflicts or contradictions in descriptions of system facilities + * verifiable — requirements should be directly mapped to parts of system +* non-functional: constraints on services/functions offered by the system, often apply to system as a whole instead of individual features/services + * system properties and constraints (e.g. reliability, response time, storage requirements) + * may be more critical than functional, like safety requirements + * may affect overall architecture of a system instead of individual components (like organization to minimize communications between robots) + * different types: + +  + +in UML: use case diagrams for functional requirements. + +How to write requirements specifications: + +| *Notation* | *Description* | +|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| +| Natural language | Use numbered sentences in natural language. Each sentence is one requirement. | +| Structured natural language. | Requirements are written in natural language on standard form/template. Each field gives info about an aspect of the requirement. | +| Design description languages | Use language like programming language, but with more abstract features specifying requirements by defining an operational model of the system. | +| Graphical notations | Graphical models with text annotations. e.g. UML use case and sequence diagrams. | +| Mathematical specifications | Based on math concepts like finite-state machines or sets. Most customers don't understand this so not often used. | + +#### Natural language specification +requirements are written as natural language sentences. used because it's expressive, intuitive, universal, easily understood by customers. + +guidelines: +* invent a standard format, use it for all requirements. +* use language in a consistent way ("shall" for mandatory requirements, "should" for desirable requirements) +* highlight text to identify important parts of requirement +* avoid use of computer jargon +* include explanation (rationale) of why a requirement is needed + +#### Use case diagrams +express expectations of customers/stakeholders. + +answers questions: +* what is being described? (the system) +* who interacts with the system? (the actors) +* what can the actors do? (use cases) + +use case: +* describes functionality expected from system under development +* set of all use cases describes functionality that a system shall provide. +* notations: + + + +actors: +* interact with the system by using use cases, or by being used by use cases. +* represent roles that users adopt (users can have multiple roles) +* not part of the system, so outside of system boundaries. +* human or non-human +* primary/secondary: + * if primary, has main benefit of execution of use case. + * if secondary, receives no direct benefit. +* active or passive + * active: initiates execution of the use case + * passive: provides functionality for the execution of the use case + + + +relationships between use cases and actors: +* actors are connected with use cases via associations (solid lines) +* every actors has to communicate with at least one use case +* association is always binary, multiplicities can be specified + + + +relationships between use cases: +* «include» + * behavior of one use case ('included') _is always_ integrated in the behavior of another use case ('base') + +  +* «extend» + * behavior of one use case ('extending') _may be_ integrated in behavior of another use case ('base') + * both use cases can also be executed independently of each other + * extension points are written directly in the use case. you can specify multiple extension points. + +  +* generalization of use cases + * if use case A generalizes use case B, then B inherits behavior of A and may extend/overwrite it. B also inherits all relationships form A. + * A may be labeled {abstract} — cannot be executed directly, only B is executable + +  + +relationships between actors +* generalization + * actor A inherits from actor B. e.g. A can communicate with X and Y, B can only communicate with Y. + * abstract actors are possible + +  + +Description of use cases: +* Name +* Short description +* Precondition: prerequisite for successful execution +* Postcondition: system state after successful execution +* Error situations: errors relevant to problem domain +* System state on occurrence of an error +* Actors that communicate with the use case +* Trigger: events which initiate the use case +* Standard process: individual steps to be taken +* Alternative processes: deviations from the standard process + +Remember, it's an abstraction. Many small use cases with the same objective should be grouped. Don't decompose functionality into use cases. + +### Summary of notation + + + + diff --git a/content/softdesign-notes/img/non-func-requirements.png b/content/softdesign-notes/requirements-engineering/non-func-requirements.png Binary files differ. diff --git a/content/softdesign-notes/img/requirement-notation-p1.png b/content/softdesign-notes/requirements-engineering/requirement-notation-p1.png Binary files differ. diff --git a/content/softdesign-notes/img/requirement-notation-p2.png b/content/softdesign-notes/requirements-engineering/requirement-notation-p2.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-diagrams.png b/content/softdesign-notes/requirements-engineering/uml-diagrams.png Binary files differ. diff --git a/content/softdesign-notes/img/use-case-extensions.png b/content/softdesign-notes/requirements-engineering/use-case-extensions.png Binary files differ. diff --git a/content/softdesign-notes/img/use-case-notations.png b/content/softdesign-notes/requirements-engineering/use-case-notations.png Binary files differ. diff --git a/content/softdesign-notes/img/usecase-actor-rel.png b/content/softdesign-notes/requirements-engineering/usecase-actor-rel.png Binary files differ. diff --git a/content/softdesign-notes/img/usecase-generalisation.png b/content/softdesign-notes/requirements-engineering/usecase-generalisation.png Binary files differ. diff --git a/content/softdesign-notes/img/usecase-include-rel.png b/content/softdesign-notes/requirements-engineering/usecase-include-rel.png Binary files differ. diff --git a/content/softdesign-notes/sequence-diagrams.html b/content/softdesign-notes/sequence-diagrams.html @@ -1,537 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>sequence-diagrams</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Sequence Diagrams"><h2 id="Sequence Diagrams">Sequence Diagrams</h2></div> -<div id="Sequence Diagrams-Introduction"><h3 id="Introduction">Introduction</h3></div> -<p> -it's a way to model interactions between objects -</p> - -<p> -interaction specifies how messages and data are exchanged between objects -</p> - -<p> -interaction partners: human (lecturer, admin) or non-human (server, printer, software) -</p> - -<p> -interactions: conversation between people, message exchange between human and software, communication protocols, sequence of method calls in program, etc. -</p> - -<div id="Sequence Diagrams-Basics"><h3 id="Basics">Basics</h3></div> -<div id="Sequence Diagrams-Basics-Interactions, interaction partners"><h4 id="Interactions, interaction partners">Interactions, interaction partners</h4></div> -<p> -a sequence diagram is 2D: -</p> -<ul> -<li> -horizontal axis: involved interaction partners - -<li> -vertical axis: chronological order of interaction - -</ul> - -<p> -interaction: sequence of event specifications -</p> - -<p> -<img src="img/sequence-diagram-example.png" alt="Sequence diagram example" /> -</p> - -<p> -interaction partners are lifelines: -</p> -<ul> -<li> -head of lifeline is rectangle containing <code>object:Class</code> - -<li> -body of lifeline is vertical dashed line representing lifetime of associated object - -</ul> - -<div id="Sequence Diagrams-Basics-Messages"><h4 id="Messages">Messages</h4></div> -<p> -message is defined via send and receive events -</p> - -<p> -execution specification (optional): -</p> -<ul> -<li> -continuous bar - -<li> -used to visualize when interaction partner executes a behavior - -</ul> - -<p> -<img src="img/exchanging-messages-example-on-diagram.png" alt="Exchanging messages example on diagram" /> -</p> - -<p> -rules: -</p> - -<p> -<img src="img/exchanging-messages-rules.png" alt="Exchanging messages rules" /> -</p> - -<p> -synchronous message: -</p> -<ul> -<li> -sender waits until it has received response message before continuing - -<li> -syntax: <code>msg(par₁, par₂)</code> - -<ul> -<li> -<code>msg</code>: name of message - -<li> -<code>par</code>: parameters - -</ul> -<li> -notation: <img src="img/synchronous-message.png" alt="Synchronous message" /> - -</ul> - -<p> -asynchronous message: -</p> -<ul> -<li> -sender continues without waiting for response msg - -<li> -syntax: <code>msg(par₁, par₂)</code> - -<li> -notation: <img src="img/asynchronous-message.png" alt="asynchronous message" /> - -</ul> - -<p> -response message: -</p> -<ul> -<li> -can be omitted if content and location are obvious - -<li> -syntax: <code>att = msg(par₁, par₂): val</code> - -<ul> -<li> -<code>att</code>: return value assigned to variable (optional) - -<li> -<code>msg</code>: name of message - -<li> -<code>par</code>: parameters - -<li> -<code>val</code>: return value - -</ul> -<li> -notation: <img src="img/response-message.png" alt="response message" /> - -</ul> - -<p> -object creation: -</p> -<ul> -<li> -dashed arrow, arrowhead pointing to head of lifeline of object that's being created - -<li> -keyword <code>new</code> - -<li> -notation: <img src="img/object-creation-.png" alt="Object creation" /> - -</ul> - -<p> -object destruction: -</p> -<ul> -<li> -object is deleted - -<li> -large cross at end of lifeline - -<li> -notation: <img src="img/object-destruction-.png" alt="Object destruction" /> - -</ul> - -<p> -found message: -</p> -<ul> -<li> -sender unknown/not relevant - -<li> -notation: <img src="img/found-message.png" alt="Found message" /> - -</ul> - -<p> -lost message: -</p> -<ul> -<li> -receiver unknown/not relevant - -<li> -notation: <img src="img/lost-message.png" alt="Lost message" /> - -</ul> - -<p> -Time-consuming message: -</p> -<ul> -<li> -message with duration - -<li> -usually messages transmitted instantly (by assumption); not in this case - -<li> -notation: <img src="img/time-consuming-message.png" alt="Time-consuming message" /> - -</ul> - -<div id="Sequence Diagrams-Combined fragments"><h3 id="Combined fragments">Combined fragments</h3></div> -<p> -model various control structures, have 12 predefined operators. -</p> - -<p> -Example: -</p> - -<p> -<img src="img/combined-fragment-example.png" alt="Combined fragment example" /> -</p> - -<div id="Sequence Diagrams-Combined fragments-Branches & loops"><h4 id="Branches & loops">Branches & loops</h4></div> -<p> -<code>alt</code>: -</p> -<ul> -<li> -alternative sequence - -<li> -like a switch statement, with guards selecting the path to be executed - -<li> -guards modeled in square brackets, default true - -<li> -guards have to be disjoint so that behavior is deterministic! - -</ul> -<blockquote> -<img src="img/alt-fragment.png" alt="Alt fragment" /> -</blockquote> - -<p> -<code>opt</code>: -</p> -<ul> -<li> -optional sequence - -<li> -like an if without an else - -<li> -actual execution depends on guard - -<li> -exactly one operand - -</ul> -<blockquote> -<img src="img/opt-fragment.png" alt="Opt fragment" /> -</blockquote> - -<p> -<code>loop</code>: -</p> -<ul> -<li> -repeated sequence - -<li> -min/max number of iterations - <code>(min..max)</code> or <code>(min, max)</code>. default <code>(*)</code>, no upper limit. - -<li> -guard evaluated when min number of iterations took place, checked on each iteration. loop quits if false. - -</ul> -<blockquote> -<img src="img/loop-fragment.png" alt="Loop fragment" /> -</blockquote> - -<p> -<code>break</code>: -</p> -<ul> -<li> -exception handling - -<li> -one operand with a guard. if true: - -<ul> -<li> -interactions within operand are executed - -<li> -remaining operations of <em>surrounding</em> fragment don't run - -<li> -interaction continues at next higher level fragment (so like you skip a level) - -</ul> -</ul> -<blockquote> -<img src="img/break-fragment.png" alt="Break fragment" /> -</blockquote> - -<div id="Sequence Diagrams-Combined fragments-Concurrency and order"><h4 id="Concurrency and order">Concurrency and order</h4></div> -<p> -<code>seq</code>: -</p> -<ul> -<li> -weak sequencing, default order of events - -<li> -can't skip around on the same lifeline - -</ul> -<blockquote> -<img src="img/seq-fragment.png" alt="Seq fragment" /> -</blockquote> - -<p> -<code>strict</code>: -</p> -<ul> -<li> -strict order - -<li> -fixed sequence of events across lifelines - -<li> -order of events on different lifelines between different operands is significant - -<li> -messages in operand higher up on vertical axis are <em>always</em> exchanged before the ones that are lower - -</ul> -<blockquote> -<img src="img/strict-fragment.png" alt="Strict fragment" /> -</blockquote> - -<p> -<code>par</code>: -</p> -<ul> -<li> -concurrent interaction - -<li> -relax chronological order between messages in different operands - -<li> -restrictions in each operand have to be respected - -<li> -order of different operands is irrelevant - -</ul> -<blockquote> -<img src="img/par-fragment-.png" alt="Par fragment" /> -</blockquote> - -<p> -<code>critical</code>: -</p> -<ul> -<li> -atomic interaction - -<li> -make sure that certain parts of interaction aren't interrupted by unexpected events - -<li> -<em>always</em> has to be in that order - -</ul> -<blockquote> -<img src="img/critical-fragment.png" alt="Critical fragment" /> -</blockquote> - -<div id="Sequence Diagrams-Combined fragments-Filters and assertions"><h4 id="Filters and assertions">Filters and assertions</h4></div> -<p> -<code>ignore</code>: -</p> -<ul> -<li> -irrelevant interaction - -<li> -messages can occur at runtime but don't have other significance - -<li> -one operand, irrelevant messages in curly brackets after keyword <code>ignore</code> - -</ul> -<blockquote> -<img src="img/ignore-fragment.png" alt="Ignore fragment" /> -</blockquote> - -<p> -<code>consider</code>: -</p> -<ul> -<li> -relevant interaction with a particular importance - -<li> -one operand. "dual" to ignore fragment - -<li> -considered messages in curly brackets - -<li> -and yes, you can use <code>ignore</code> instead of <code>consider</code> and vice-versa - -</ul> -<blockquote> -<img src="img/consider-fragment.png" alt="Consider fragment" /> -</blockquote> - -<p> -<code>assert</code>: -</p> -<ul> -<li> -asserted interaction - -<li> -mandatory interactions. the model is complete. can't have any deviations. - -</ul> -<blockquote> -<img src="img/assert-fragment.png" alt="Assert fragment" /> -</blockquote> - -<p> -<code>neg</code>: -</p> -<ul> -<li> -invalid interaction - -<li> -describe situations that must not occur - -<li> -depicting relevant but <em>incorrect</em> sequences - -</ul> - -<p> -<img src="img/neg-fragment.png" alt="Neg fragment" /> -</p> - -<div id="Sequence Diagrams-Further language elements"><h3 id="Further language elements">Further language elements</h3></div> -<p> -time constraints: -</p> -<ul> -<li> -point in time for event occurrence: <code>after(5sec)</code>, <code>at(12.00)</code> - -<li> -time period between two events: <code>{lower..upper}</code> - -<li> -<code>now</code>: current time - -<li> -duration: calculation of duration of message transmission - -</ul> - -<p> -Interaction reference: -</p> -<ul> -<li> -integrates one sequence diagram in another sequence diagram - -<li> -define with <code>sd name</code> in the corner, then use the name in the diagram with <code>ref</code> in the corner - -</ul> - -<p> -Gate: -</p> -<ul> -<li> -allows to send and receive messages beyond boundaries of interaction fragment - -</ul> - -<p> -state invariant: -</p> -<ul> -<li> -asserts certain condition has to be true at certain time - -<li> -if state invariant is not true, either model or implementation is wrong - -<li> -notations: - -</ul> -<blockquote> -<img src="img/state-invariant-diagram.png" alt="State invariant diagram" /> -</blockquote> - -</body> -</html> diff --git a/content/softdesign-notes/img/alt-fragment.png b/content/softdesign-notes/sequence-diagrams/alt-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/assert-fragment.png b/content/softdesign-notes/sequence-diagrams/assert-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/asynchronous-message.png b/content/softdesign-notes/sequence-diagrams/asynchronous-message.png Binary files differ. diff --git a/content/softdesign-notes/img/break-fragment.png b/content/softdesign-notes/sequence-diagrams/break-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/combined-fragment-example.png b/content/softdesign-notes/sequence-diagrams/combined-fragment-example.png Binary files differ. diff --git a/content/softdesign-notes/img/consider-fragment.png b/content/softdesign-notes/sequence-diagrams/consider-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/critical-fragment.png b/content/softdesign-notes/sequence-diagrams/critical-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/exchanging-messages-example-on-diagram.png b/content/softdesign-notes/sequence-diagrams/exchanging-messages-example-on-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/exchanging-messages-rules.png b/content/softdesign-notes/sequence-diagrams/exchanging-messages-rules.png Binary files differ. diff --git a/content/softdesign-notes/img/found-message.png b/content/softdesign-notes/sequence-diagrams/found-message.png Binary files differ. diff --git a/content/softdesign-notes/img/ignore-fragment.png b/content/softdesign-notes/sequence-diagrams/ignore-fragment.png Binary files differ. diff --git a/content/softdesign-notes/sequence-diagrams/index.md b/content/softdesign-notes/sequence-diagrams/index.md @@ -0,0 +1,203 @@ ++++ +title = 'Sequence Diagrams' ++++ +## Sequence Diagrams +### Introduction +it's a way to model interactions between objects + +interaction specifies how messages and data are exchanged between objects + +interaction partners: human (lecturer, admin) or non-human (server, printer, software) + +interactions: conversation between people, message exchange between human and software, communication protocols, sequence of method calls in program, etc. + +### Basics +#### Interactions, interaction partners +a sequence diagram is 2D: +* horizontal axis: involved interaction partners +* vertical axis: chronological order of interaction + +interaction: sequence of event specifications + + + +interaction partners are lifelines: +* head of lifeline is rectangle containing `object:Class` +* body of lifeline is vertical dashed line representing lifetime of associated object + +#### Messages +message is defined via send and receive events + +execution specification (optional): +* continuous bar +* used to visualize when interaction partner executes a behavior + + + +rules: + + + +synchronous message: +* sender waits until it has received response message before continuing +* syntax: `msg(par₁, par₂)` + * `msg`: name of message + * `par`: parameters +* notation:  + +asynchronous message: +* sender continues without waiting for response msg +* syntax: `msg(par₁, par₂)` +* notation:  + +response message: +* can be omitted if content and location are obvious +* syntax: `att = msg(par₁, par₂): val` + * `att`: return value assigned to variable (optional) + * `msg`: name of message + * `par`: parameters + * `val`: return value +* notation:  + +object creation: +* dashed arrow, arrowhead pointing to head of lifeline of object that's being created +* keyword `new` +* notation:  + +object destruction: +* object is deleted +* large cross at end of lifeline +* notation:  + +found message: +* sender unknown/not relevant +* notation:  + +lost message: +* receiver unknown/not relevant +* notation:  + +Time-consuming message: +* message with duration +* usually messages transmitted instantly (by assumption); not in this case +* notation:  + +### Combined fragments +model various control structures, have 12 predefined operators. + +Example: + + + +#### Branches & loops +`alt`: +* alternative sequence +* like a switch statement, with guards selecting the path to be executed +* guards modeled in square brackets, default true +* guards have to be disjoint so that behavior is deterministic! + + + +`opt`: +* optional sequence +* like an if without an else +* actual execution depends on guard +* exactly one operand + + + +`loop`: +* repeated sequence +* min/max number of iterations - `(min..max)` or `(min, max)`. default `(*)`, no upper limit. +* guard evaluated when min number of iterations took place, checked on each iteration. loop quits if false. + + + +`break`: +* exception handling +* one operand with a guard. if true: + * interactions within operand are executed + * remaining operations of _surrounding_ fragment don't run + * interaction continues at next higher level fragment (so like you skip a level) + + + +#### Concurrency and order +`seq`: +* weak sequencing, default order of events +* can't skip around on the same lifeline + + + +`strict`: +* strict order +* fixed sequence of events across lifelines +* order of events on different lifelines between different operands is significant +* messages in operand higher up on vertical axis are _always_ exchanged before the ones that are lower + + + +`par`: +* concurrent interaction +* relax chronological order between messages in different operands +* restrictions in each operand have to be respected +* order of different operands is irrelevant + + + +`critical`: +* atomic interaction +* make sure that certain parts of interaction aren't interrupted by unexpected events +* _always_ has to be in that order + + + +#### Filters and assertions +`ignore`: +* irrelevant interaction +* messages can occur at runtime but don't have other significance +* one operand, irrelevant messages in curly brackets after keyword `ignore` + + + +`consider`: +* relevant interaction with a particular importance +* one operand. "dual" to ignore fragment +* considered messages in curly brackets +* and yes, you can use `ignore` instead of `consider` and vice-versa + + + +`assert`: +* asserted interaction +* mandatory interactions. the model is complete. can't have any deviations. + + + +`neg`: +* invalid interaction +* describe situations that must not occur +* depicting relevant but _incorrect_ sequences + + + +### Further language elements +time constraints: +* point in time for event occurrence: `after(5sec)`, `at(12.00)` +* time period between two events: `{lower..upper}` +* `now`: current time +* duration: calculation of duration of message transmission + +Interaction reference: +* integrates one sequence diagram in another sequence diagram +* define with `sd name` in the corner, then use the name in the diagram with `ref` in the corner + +Gate: +* allows to send and receive messages beyond boundaries of interaction fragment + +state invariant: +* asserts certain condition has to be true at certain time +* if state invariant is not true, either model or implementation is wrong +* notations: + + diff --git a/content/softdesign-notes/img/loop-fragment.png b/content/softdesign-notes/sequence-diagrams/loop-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/lost-message.png b/content/softdesign-notes/sequence-diagrams/lost-message.png Binary files differ. diff --git a/content/softdesign-notes/img/neg-fragment.png b/content/softdesign-notes/sequence-diagrams/neg-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/object-creation-.png b/content/softdesign-notes/sequence-diagrams/object-creation-.png Binary files differ. diff --git a/content/softdesign-notes/img/object-destruction-.png b/content/softdesign-notes/sequence-diagrams/object-destruction-.png Binary files differ. diff --git a/content/softdesign-notes/img/opt-fragment.png b/content/softdesign-notes/sequence-diagrams/opt-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/par-fragment-.png b/content/softdesign-notes/sequence-diagrams/par-fragment-.png Binary files differ. diff --git a/content/softdesign-notes/img/response-message.png b/content/softdesign-notes/sequence-diagrams/response-message.png Binary files differ. diff --git a/content/softdesign-notes/img/seq-fragment.png b/content/softdesign-notes/sequence-diagrams/seq-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/sequence-diagram-example.png b/content/softdesign-notes/sequence-diagrams/sequence-diagram-example.png Binary files differ. diff --git a/content/softdesign-notes/img/state-invariant-diagram.png b/content/softdesign-notes/sequence-diagrams/state-invariant-diagram.png Binary files differ. diff --git a/content/softdesign-notes/img/strict-fragment.png b/content/softdesign-notes/sequence-diagrams/strict-fragment.png Binary files differ. diff --git a/content/softdesign-notes/img/synchronous-message.png b/content/softdesign-notes/sequence-diagrams/synchronous-message.png Binary files differ. diff --git a/content/softdesign-notes/img/time-consuming-message.png b/content/softdesign-notes/sequence-diagrams/time-consuming-message.png Binary files differ. diff --git a/content/softdesign-notes/software-abstraction-modeling.html b/content/softdesign-notes/software-abstraction-modeling.html @@ -1,92 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>software-abstraction-modeling</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Software abstraction & modeling"><h2 id="Software abstraction & modeling">Software abstraction & modeling</h2></div> -<p> -software engineering: the application of engineering to software. a programmer writes a complete program, a software engineer creates a component. -</p> - -<p> -engineers abstract away from details that can be <em>safely</em> ignored. -</p> - -<p> -model: simplified/partial representation of reality, defined to accomplish a task or reach an agreement -</p> - -<p> -abstraction: generalizing – setting aside specific and individual features -</p> - -<p> -software design: creating models representing an abstract view of the system -</p> - -<div id="Software abstraction & modeling-Models"><h3 id="Models">Models</h3></div> -<p> -what is a model? -</p> -<ul> -<li> -mapping feature: a model is based on an original - -<li> -reduction feature: a model only reflects a relevant selection of the original's properties - -<li> -pragmatic feature: a model needs to be usable in place of an original with respect to some purpose - -</ul> - -<p> -consumer and intent influence the abstraction level of a model -</p> - -<p> -descriptive models: -</p> -<ul> -<li> -a subject is described by the model - -<li> -sketches and throw-away models – short life time, used to better understand the reality - -<li> -models of ideas and vision about the system to be developed – to exploit model for having feedback before actually implementing the system - -<li> -models extracted from a running system or code – e.g. to visualize all calls between Java classes - -</ul> - -<p> -prescriptive models: -</p> -<ul> -<li> -a model prescribes the subject - -<li> -the subject does not yet exist - -<li> -the models guide the development of the system - -<li> -most common consumers are code generators - -<li> -often used for development, so their importance may decay when the system is implemented - -</ul> - -</body> -</html> diff --git a/content/softdesign-notes/software-abstraction-modeling.md b/content/softdesign-notes/software-abstraction-modeling.md @@ -0,0 +1,35 @@ ++++ +title = 'Software abstraction & modeling' ++++ +## Software abstraction & modeling +software engineering: the application of engineering to software. a programmer writes a complete program, a software engineer creates a component. + +engineers abstract away from details that can be _safely_ ignored. + +model: simplified/partial representation of reality, defined to accomplish a task or reach an agreement + +abstraction: generalizing – setting aside specific and individual features + +software design: creating models representing an abstract view of the system + +### Models +what is a model? +* mapping feature: a model is based on an original +* reduction feature: a model only reflects a relevant selection of the original's properties +* pragmatic feature: a model needs to be usable in place of an original with respect to some purpose + +consumer and intent influence the abstraction level of a model + +descriptive models: +* a subject is described by the model +* sketches and throw-away models – short life time, used to better understand the reality +* models of ideas and vision about the system to be developed – to exploit model for having feedback before actually implementing the system +* models extracted from a running system or code – e.g. to visualize all calls between Java classes + +prescriptive models: +* a model prescribes the subject +* the subject does not yet exist +* the models guide the development of the system +* most common consumers are code generators +* often used for development, so their importance may decay when the system is implemented + diff --git a/content/softdesign-notes/software-development-process.html b/content/softdesign-notes/software-development-process.html @@ -1,201 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>software-development-process</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Software development process"><h2 id="Software development process">Software development process</h2></div> - -<p> -main activities: -</p> -<ul> -<li> -requirements engineering - -<ul> -<li> -specifies the main functionalities of the system - -<li> -defines the qualities to be met - -</ul> -<li> -design - -<ul> -<li> -give shape to a system via models - -<li> -not a clear-cut sequential process - -</ul> -<li> -implementation and testing - -<ul> -<li> -involves actual development of the system - -<li> -component testing – test individual components independently - -<li> -system testing – test the system as a whole (including emergent properties like overall performance) - -<li> -acceptance testing – test with customer data to see if the system meets the customer's needs - -</ul> -<li> -evolution - -<ul> -<li> -software is inherently flexible and can change - -</ul> -</ul> - -<div id="Software development process-Waterfall development process"><h3 id="Waterfall development process">Waterfall development process</h3></div> - -<p> -<img src="img/waterfall-dev.png" alt="Waterfall dev process image" /> -</p> - -<p> -exists in many variants, all with sequential flow. it's document-driven. -</p> - -<p> -issues: poor agility (when do you know how far you are in the project?), poor quality (cuts if you run out of time), high risk (finding issues in test phase) -</p> - -<p> -critical evaluation: -</p> -<ul> -<li> -positive: - -<ul> -<li> -precise planning and management – standard-oriented - -<li> -postpone implementation to after understanding objectives - -<li> -good documentation - -</ul> -<li> -negative: - -<ul> -<li> -hard to get all requirements once and for all (users might not even know what they want) - -<li> -rigid - -<li> -no feedback from the customer - -<li> -no parallelism, all phases are blocking (because sequential) - -<li> -a single delivery date at the end - -</ul> -</ul> - -<div id="Software development process-Agile development process"><h3 id="Agile development process">Agile development process</h3></div> -<p> -iterative development processes with: -</p> -<ul> -<li> -frequent releases of the product - -<li> -continuous interaction between dev team and customer - -<li> -reduced product documentation - -<li> -continuous and systematic assessment of produced value and risks - -</ul> - -<p> -agile in practice: -</p> -<ul> -<li> -make a list - -<li> -estimate - -<li> -set priorities - -<li> -start executing - -<li> -update the plan at run time - -</ul> - -<p> -critical evaluation: -</p> -<ul> -<li> -positive: - -<ul> -<li> -acceptance of change – less risky - -<li> -frequent and short iterations - -<li> -emphasis on working code - -<li> -associates a test with every piece of functionality - -<li> -continuous integration and delivery - -</ul> -<li> -negative: - -<ul> -<li> -feature-based development & ignorance of dependencies - -<li> -no strong quality plan - -<li> -less focus on architecture of system (in fact, dismisses everything that isn't shippable) - -</ul> -</ul> - -</body> -</html> diff --git a/content/softdesign-notes/software-development-process/index.md b/content/softdesign-notes/software-development-process/index.md @@ -0,0 +1,66 @@ ++++ +title = 'Software development process' ++++ +## Software development process + +main activities: +* requirements engineering + * specifies the main functionalities of the system + * defines the qualities to be met +* design + * give shape to a system via models + * not a clear-cut sequential process +* implementation and testing + * involves actual development of the system + * component testing – test individual components independently + * system testing – test the system as a whole (including emergent properties like overall performance) + * acceptance testing – test with customer data to see if the system meets the customer's needs +* evolution + * software is inherently flexible and can change + +### Waterfall development process + + + +exists in many variants, all with sequential flow. it's document-driven. + +issues: poor agility (when do you know how far you are in the project?), poor quality (cuts if you run out of time), high risk (finding issues in test phase) + +critical evaluation: +* positive: + * precise planning and management – standard-oriented + * postpone implementation to after understanding objectives + * good documentation +* negative: + * hard to get all requirements once and for all (users might not even know what they want) + * rigid + * no feedback from the customer + * no parallelism, all phases are blocking (because sequential) + * a single delivery date at the end + +### Agile development process +iterative development processes with: +* frequent releases of the product +* continuous interaction between dev team and customer +* reduced product documentation +* continuous and systematic assessment of produced value and risks + +agile in practice: +* make a list +* estimate +* set priorities +* start executing +* update the plan at run time + +critical evaluation: +* positive: + * acceptance of change – less risky + * frequent and short iterations + * emphasis on working code + * associates a test with every piece of functionality + * continuous integration and delivery +* negative: + * feature-based development & ignorance of dependencies + * no strong quality plan + * less focus on architecture of system (in fact, dismisses everything that isn't shippable) + diff --git a/content/softdesign-notes/img/waterfall-dev.png b/content/softdesign-notes/software-development-process/waterfall-dev.png Binary files differ. diff --git a/content/softdesign-notes/src/img b/content/softdesign-notes/src/img @@ -1 +0,0 @@ -../img/- \ No newline at end of file diff --git a/content/softdesign-notes/src/index.wiki b/content/softdesign-notes/src/index.wiki @@ -1,58 +0,0 @@ -%% vim: spell spelllang=en_us spellcapcheck= relativenumber: -= Software Design = -[[/software-design.apkg|Here]] is my [[https://apps.ankiweb.net|Anki]] deck that I'm using to prepare for the exam. - -- [[/software-abstraction-modeling#Software abstraction & modeling|Software abstraction & modeling]] - - [[/software-abstraction-modeling#Software abstraction & modeling#Models|Models]] -- [[/software-development-process#Software development process|Software development process]] - - [[/software-development-process#Software development process#Waterfall development process|Waterfall development process]] - - [[/software-development-process#Software development process#Agile development process|Agile development process]] -- [[/requirements-engineering#Requirements engineering with UML|Requirements engineering with UML]] - - [[/requirements-engineering#Requirements engineering with UML#What is UML?|What is UML?]] - - [[/requirements-engineering#Requirements engineering with UML#Requirements engineering|Requirements engineering]] - - [[/requirements-engineering#Requirements engineering with UML#Requirements engineering#Natural language specification|Natural language specification]] - - [[/requirements-engineering#Requirements engineering with UML#Requirements engineering#Use case diagrams|Use case diagrams]] - - [[/requirements-engineering#Requirements engineering with UML#Summary of notation|Summary of notation]] -- [[/structure-modeling#Structure modeling with UML|Structure modeling with UML]] - - [[/structure-modeling#Structure modeling with UML#Class|Class]] - - [[/structure-modeling#Structure modeling with UML#Class#Attribute syntax|Attribute syntax]] - - [[/structure-modeling#Structure modeling with UML#Class#Operation syntax|Operation syntax]] - - [[/structure-modeling#Structure modeling with UML#Class#Class variable and class operation|Class variable and class operation]] - - [[/structure-modeling#Structure modeling with UML#Relationships|Relationships]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Binary association|Binary association]] - - [[/structure-modeling#Structure modeling with UML#Relationships#n-ary association|n-ary association]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Association class|Association class]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Aggregation|Aggregation]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Aggregation#Shared aggregation|Shared aggregation]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Aggregation#Composition|Composition]] - - [[/structure-modeling#Structure modeling with UML#Relationships#Generalization|Generalization]] - - [[/structure-modeling#Structure modeling with UML#Creating a class diagram|Creating a class diagram]] -- [[/oo-design-patterns#Object-oriented design patterns in UML|Object-oriented design patterns in UML]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Creational|Creational]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Creational#Singleton|Singleton]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Creational#Factory method|Factory method]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Structural|Structural]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Structural#Adapter|Adapter]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Behavioral|Behavioral]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Behavioral#Observer|Observer]] - - [[/oo-design-patterns#Object-oriented design patterns in UML#Behavioral#Chain of responsibility|Chain of responsibility]] -- [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines|Modeling behavior with UML State Machines]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#Introduction|Introduction]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#States|States]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#Transitions|Transitions]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#Types of events|Types of events]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#Types of states|Types of states]] - - [[/modeling-behavior-state-machines#Modeling behavior with UML State Machines#Entry and exit points|Entry and exit points]] -- [[/sequence-diagrams#Sequence Diagrams|Sequence Diagrams]] - - [[/sequence-diagrams#Sequence Diagrams#Introduction|Introduction]] - - [[/sequence-diagrams#Sequence Diagrams#Basics|Basics]] - - [[/sequence-diagrams#Sequence Diagrams#Basics#Interactions, interaction partners|Interactions, interaction partners]] - - [[/sequence-diagrams#Sequence Diagrams#Basics#Messages|Messages]] - - [[/sequence-diagrams#Sequence Diagrams#Combined fragments|Combined fragments]] - - [[/sequence-diagrams#Sequence Diagrams#Combined fragments#Branches & loops|Branches & loops]] - - [[/sequence-diagrams#Sequence Diagrams#Combined fragments#Concurrency and order|Concurrency and order]] - - [[/sequence-diagrams#Sequence Diagrams#Combined fragments#Filters and assertions|Filters and assertions]] - - [[/sequence-diagrams#Sequence Diagrams#Further language elements|Further language elements]] -- [[/philosophy-of-software-design#Philosophy of Software Design|Philosophy of Software Design]] - - [[/philosophy-of-software-design#Philosophy of Software Design#Summary of Design Principles|Summary of Design Principles]] - - [[/philosophy-of-software-design#Philosophy of Software Design#Summary of red flags|Summary of red flags]] diff --git a/content/softdesign-notes/src/modeling-behavior-state-machines.wiki b/content/softdesign-notes/src/modeling-behavior-state-machines.wiki @@ -1,143 +0,0 @@ -== Modeling behavior with UML State Machines == -=== Introduction === -every object has finite set of states during life. - -state machine diagram is used to: - * model possible states of system/object - * show how state transitions occur as consequence of events - * show behavior of system in each state - -{{file:img/simple-example.png|Simple example}} - -=== States === -states are the nodes of state machine - -when a state is active: - * object is in that state - * all internal activities in that state can be executed: - * `entry/Activity` - when object enters the state - * `do/Activity` - while object remains in this state - * `exit/Activity` - when object exits the state - -=== Transitions === -change from one state to another - -{{file:img/transition-diagram.png|Transition diagram}} - -Syntax of transitions: - - {{file:img/syntax-of-transitions.png|Syntax of transitions}} - - * Event (trigger) - * can trigger state transition - * Guard (condition) - * boolean expression - * if event occurs, guard is checked - * if guard is true: - 1. all activities in current state are terminated - 2. exit activity is executed - 3. transition happens - * Activity (effect) - * sequence of actions that happen during transition - -Types: - * internal: - - {{file:img/internal-state-transition.png|Internal state transition}} - - * if `event1` happens, object stays in `state1` and `Activity3` runs - - * external: - - {{file:img/external-state-transition.png|External state transition}} - - * if `event1` happens: - * object leaves `state1`, `Activity2` runs - * `Activity3` runs - * object enters `state1` and `Activity1` runs - -Timing of transitions: - -{{file:img/table-of-transition-timing.png|Table of transition timing}} - -=== Types of events === -* *Signal event:* receipt of a signal (`rightmousedown`, `sendSMS(message)`) -* *Call event:* operation call (`occupy(user, lectureHall)`, `register(exam)`) -* *Time event:* time-based state transition (relative or absolute time) -* *Any receive event:* when any event occurs that doesn't trigger another transition from the active state -* *Completion event:* automatic when everything is completed in the current state -* *Change event:* permanently checking when a condition becomes true - -A change event is permanently checked. A guard is only checked when the event occurs. - -=== Types of states === -Initial state: - * "start" of the diagram - * pseudo-state, system can't remain in this state - * no incoming edges - * outgoing edges have to be mutually exclusive and at least one target must be reachable. no events allowed. - * system immediately switches from initial state. - * notation: {{file:img/initial-state-notation.png|Initial state notation}} - -Final state: - * real state - * end of sequence of states - * can remain in this state forever - * notation: {{file:img/final-state-notation.png|Final state notation}} - -Terminate node: - * pseudo-state - * terminates state machine - * modeled object is deleted - * notation: {{file:img/terminate-node-notation.png|Terminate node notation}} - -Decision node: - * pseudo-state - * used for alternative transitions - * notation: {{file:img/decision-node-notation.png|Decision node notation}} - -Parallelization node: - * pseudo-state - * splits control flow into multiple concurrent flows - * 1 incoming edge, >1 outgoing edges - * notation: {{file:img/parallelization-node-notation.png|Parallelization node notation}} - -Synchronization node: - * pseudo-state - * merges multiple concurrent flows - * >1 incoming edge, 1 outgoing edge - * notation: {{file:img/synchronization-node-notation.png|Synchronization node notation}} - -Composite state: - * contains substates, with only one of them active at any time - * arbitrary nesting depth - * higher level events take priority - - {{file:img/composite-state-diagram.png|Composite state diagram}} - -Orthogonal state: - * composite state divided into two or more regions, separated by dashed line - * one state of each region is always active at some point (concurrent substates) - * final state has to be reached in all regions to trigger completion - - {{file:img/orthogonal-state-diagram.png|Orthogonal state diagram}} - -Submachine state (SMS) - * to reuse parts of state machine diagrams in other ones - * as soon as submachine state is activated, behavior of submachine is executed (subroutine) - * notation: `state:submachineState` - - {{file:img/submachine-state-diagram.png|Submachine state diagram}} - -History state: - * remembers the last active substate of a composite state - * activates 'old' substate and all entry activities run sequentially from outside to inside of composite state - * exactly one outgoing edge of history state points to a substate. used if the composite state was never active, or it was exited via final state. - * shallow history state restores state on the same level of the composite state (`H`) - * deep history state restores last active substate over _all levels_ (`H*`) - -=== Entry and exit points === -Encapsulation mechanism: a composite state shall be entered/exited via a state other than initial and final states. - -external transition must/need not know structure of composite state. - diff --git a/content/softdesign-notes/src/oo-design-patterns.wiki b/content/softdesign-notes/src/oo-design-patterns.wiki @@ -1,253 +0,0 @@ -== Object-oriented design patterns in UML == -design pattern: a reusable form of solution to a common design problem (like a 'template') - -not a finished design, cannot be transformed directly into source code - -not prescriptive, so don't memorize them. it's important to understand when and why they're needed. - -speaking of, they're not always needed. don't over-complicate shit, you'll end up with a dumpster fire that nobody can maintain. - -essential parts of a design pattern - * Pattern name - * provides common vocab for software designers - * Intent - * What does the design pattern do? - * What is its rationale and intent? - * What design issue/problem does it address? - * Solution - * the basic elements providing solution to the problem (structure, participants, collaborations) - * Consequences - * results and trade offs by applying the pattern - -=== Creational === -how objects can be created (maintainability, control, extensibility) - -we study the singleton and factory method. then there are also abstract factory, object pool, and prototype. - -==== Singleton ==== -| Name | Singleton | -|--------------|---------------------------------------------------------------------------------------------------------------------------------| -| Intent | To ensure that only one instance of a class is allowed in a system. <br>Controlled access to a single object is needed | -| Solution | {{file:img/singleton-solution-diagram.png|Singleton solution diagram}} | -| Consequences | Controlled access to sole instance <br> Reduced name space (fewer 'global' variables) <br> permits variable number of instances | - -Implementation - -{{{java -public class SingleObject { - // private constructor, cannot be instantiated from outside - private SingleObject(){} - - // create the one single instance - private static SingleObject instance = new SingleObject(); - - // get the only instance - public static SingleObject getInstance() { - return instance; - } - - public void showMessage() { - System.out.println("Hello world!"); - } -}}} - -==== Factory method ==== -| Name | Factory method | -|--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Intent | to abstract process of object creation so that type of created object can be determined at run time <br> to make design more customizable in terms of which objects can be created <br> avoiding the `new` operator because you don't want to hard code the class to be instantiated | -| Solution | {{file:img/factory-method-diagram.png|Factory method diagram}} | -| Consequences | end up with dedicated class to create instances of objects <br> can pass arguments to the class to control the features of the objects | - -Implementation - -{{{java -public class ShapeFactory { - public Shape getShape(String shapeTYpe) { - if (shapeType == null) { - return null; - } - if (shapeType.equalsIgnoreCase("CIRCLE")) { - return new Circle(); - } - else if (shapeType.equalsIgnoreCase("RECTANGLE")) { - return new Rectangle(); - } - else if (shapeType.equalsIgnoreCase("SQUARE")) { - return new Square(); - } - - return null; - } -} -}}} - -=== Structural === -how to form larger structures (management of complexity, efficiency) - -adapter is studied in this course. also have proxy, bridge, decorator, facade, flyweight, composite, private class data. - -==== Adapter ==== -| Name | Adapter | -|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Intent | to convert interface of class into another interface <br> to let two or more classes with incompatible interfaces work together <br> to wrap an existing class with a new one <br> to have a kinda homogeneous interface that masks diversity of some set of various objects | -| Solution | {{file:img/adapter-diagram-1.png|Adapter diagram 1}} {{file:img/adapter-diagram-2.png|Adapter diagram 2}} | -| Consequences | single class is responsible to join functionalities of independent/incompatible classes | - -Implementation - -{{{java -public class Wrapper { - // the wrapped object - private LegacyComponent legacyComponent; - - // constructor - public Wrapper (LegacyComponent instance) { - this.legacyComponent = instance; - } - - // call to wrapped method - public int doThis() { - int result = 0; - float value = this.legacyComponent.doThat(); - // magic the value into an integer somehow, then - return result; - } -} -}}} - -=== Behavioral === -how responsibilities can be assigned to objects (objects decoupling, flexibility, better communication) - -we study observer and chain of responsibility. there are also command, interpreter, iterator, mediator, memento, null object, state, strategy, template method, and visitor. - -==== Observer ==== -| Name | Observer | -|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Intent | to let some object(s) be notified of state changes in other objects in the system <br> when on object changes state, all dependents are notified and updated automatically | -| Solution | {{file:img/observer-diagram.png|Observer diagram}} | -| Consequences | supports broadcast communication <br> state changes in object(s) should trigger behavior in other objects <br> you can reuse objects without reusing their observers and v-v. <br> you can remove observers without changing the subjects | - -Implementation - -{{{java -public abstract class Observer { - protected Subject subject; - public abstract void update(); -} - -class MappingRover extends Observer { - // specify observed subject in constructor - public MappingRover(Subject subject) P - this.subject = subject; - subject.attach(this); - } - - // observers "pull" information - public void update() { - if (this.subject.getState() == 0) { - // map the environment - } - else { - // "come back home", whatever that means - } - } -} -public abstract class Subject { - private List<Observer> observers = new ArrayList<Observer>(); - private int state; - - public int getState() { ... } - public void setState(int state) { ... } // and notify all observers - public void attach(Observer observer) { ... } // add to observers list - public void detach(Observer observer) { ... } //remove from observers list - - public void notifyAllObservers() { ... } // run the update function for each observer in list -} - -public static void main(String[] args) { - CentralStation cs = new CentralStation(); - cs.setState(0); - - MappingRover rover1 = new MappingRover(cs); - CameraRover rover2 = new CameraRover(cs); - CameraRover rover3 = new CameraRover(cs); - - cs.setState(1); -} -}}} - -==== Chain of responsibility ==== -| Name | Chain of responsibility | -|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Intent | avoid coupling sender of request to receiver by giving more than one object a chance to handle request <br> chain receiving objects and pass request along chain until an object handles it (sequential) | -| Solution | {{file:img/chain-of-responsibility-diagram.png|Chain of responsibility diagram}} | -| Consequences | Reduced coupling between objects (every object needs to know its successor) <br> handler(s) are not known a priori and a request might be unhandled <br> you can change responsibilities by changing chain at runtime | - -Implementation - -{{{java -public class Task { - private Coordinate coords; - private RequestEnum request; - - // basic getters and setters - public Coordinate getcoords() { ... } - public setCoords(Coordinate coords) { ... } - - public RequestEnum getRequest() { ... } - public setRequest(RequestEnum request) { ... } -} - -public enum RequestEnum { - PICTURE, MAP; -} - -public class Coordinate { - private float lat, lon; - - // basic getters and setters - public float getLat() { ... }; - public setLat(float lat) { ... }; - public float getLon() { ... }; - public setLon(float lon) { ... }; -} - -public abstract class TaskHandler { - TaskHandler successor; - publicc void setSuccessor(TaskHandler successor) { - this.successor = successor; - } - public abstract void handleRequest(Task task); -} - -public class CameraRover extends TaskHandler { - public void handleRequest(Task task) { - if (task.request == RequestEnum.PICTURE) { - // take a picture - } - else { - // pass on to successor - if (successor != null) { - successor.handleRequest(request); - } - } - } -} - -public class Main { - public static TaskHandler setUpChain() { - MapRover mapper = new MapRover(); - CameraRover photographer1 = new CameraRover(); - CameraRover photographer2 = new CameraRover(); - CameraRover photographer3 = new CameraRover(); - - return mapper; - } - public static void main(Striing[] args) { - TaskHandler chain = setUpChain; - - chain.handleRequest(...); - } -} -}}} - diff --git a/content/softdesign-notes/src/philosophy-of-software-design.wiki b/content/softdesign-notes/src/philosophy-of-software-design.wiki @@ -1,32 +0,0 @@ -= Philosophy of Software Design = -== Summary of Design Principles == -- Complexity is incremental, even small things make a difference -- Working code isn't enough, don't introduce complexity just to finish faster -- Make continual small investments to improve system design -- Modules should be deep (provide powerful functionality, yet have simple interfaces) -- Interfaces should be designed to make most common usage as simple as possible -- simple interace > simple implementation (for a module) -- General-purpose modules are deeper -- Separate general-purpose and special-purpose code -- Different layers should have different abstractions. If two adjacent layers have similar abstractions, there's probably a probem with class decomposition. -- Pull complexity downward, make life as easy as possible for the user -- Define errors (and special cases) out of existence (when they pop up) -- Design it twice, consider multiple options for each major design decision -- Comments should describe things that are not obvious from the code -- Software should be designed for ease of reading, not ease of writing -- Increments of software development should be abstractions, not features. It's ok to put off an abstraction until it's needed by a feature, but once it's needed, take the time to design it cleanly. - -== Summary of red flags == -- Shallow module: one whose interface is complicated relative to the functionality it provides -- Information leakage: when the same knowledge is used in multiple places (e.g. two different classes both understand format of a particular type of file) -- Temporal decomposition: execution order is reflected in the code structure, which can lead to information leakage -- Overexposure: if API for commonly used features forces users to learn about other features that are rarely used, it increases cognotive load on the users -- Repetition: if the same piece of code appears multiple times, you probably haven't found the right abstraction -- Special-general mixture: when a general-purpose mechanism contains code specialised for a particular use of that mechanism, which makes it more complicated and creates information leakage -- Conjoined methods: it should be possible to understand each method independently, and if you can't, that's a red flag -- Comment repeats code: if information in a comment is already obvious from the code, that comment is useless -- Implementation documentation contaminates interface: when interface documentation describes implementation details that aren't needed to use what's being documented -- Vague name: if variable/method name is broad enough to refer to different things, it doesn't convey much info to the developer -- Hard to pick name: if it's hard to find a simple name for variable/method that creates a clear image of the underlying object, the underlying object may not have a clean design -- Hard to describe: comment describing method/variable should be simple and complete. If that's hard, there may be a problem with what you're describing -- Nonobvious code: if meaning and behavior of code can't be understood when skimming, it's a red flag. diff --git a/content/softdesign-notes/src/requirements-engineering.wiki b/content/softdesign-notes/src/requirements-engineering.wiki @@ -1,157 +0,0 @@ -== Requirements engineering with UML == - -=== What is UML? === -A unified modeling language, the defacto standard for software design. - -pros: - * not tied to a development process - * can be used across the whole life cycle - * general purpose, can model all sorts of shit - * has different representations (graphical, but also text) - -main characteristics: - * comprehensive: can describe all parts of a system - * scalable: "zoom in" and add more details if you want - * originally intended for descriptive models - * now also supports prescriptive models - -formal modeling language — its core concepts have a well-defined meaning - -UML model is represented graphically with diagrams - -The different types: - -{{file:img/uml-diagrams.png|Diagram of diagrams}} - -The ones we will use: - * use case diagram: to specify the basic functionality of a software system (requirements) - * class diagram: to define data structures within the system - * state machine diagram: to define intra-object behavior - * sequence diagram: to specify inter-object behavior and communication - -a UML _model_ contains everything related to the system. a _diagram_ is just a "window" on the model (shows some parts, but not necessarily everything). - -=== Requirements engineering === -the process of establishing: - * features that a system should and will have - * constraints under which it operates and is developed - -requirement can range between: - * high-level abstract statement of a feature - * detailed mathematical functional specification - -functional (what) vs non-functional (how) requirements - * functional: services the system should provide, how it should react to inputs, how it should behave in specific situations, opt. what it shouldn't do. - * precise — ambiguous requirements may be interpreted in different ways by developers and users - * complete — they should include descriptions of _all_ facilities required - * consistent — there should be no conflicts or contradictions in descriptions of system facilities - * verifiable — requirements should be directly mapped to parts of system - * non-functional: constraints on services/functions offered by the system, often apply to system as a whole instead of individual features/services - * system properties and constraints (e.g. reliability, response time, storage requirements) - * may be more critical than functional, like safety requirements - * may affect overall architecture of a system instead of individual components (like organization to minimize communications between robots) - * different types: - - {{file:img/non-func-requirements.png|Non-functional requirement types}} - -in UML: use case diagrams for functional requirements. - -How to write requirements specifications: - -| *Notation* | *Description* | -|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| -| Natural language | Use numbered sentences in natural language. Each sentence is one requirement. | -| Structured natural language. | Requirements are written in natural language on standard form/template. Each field gives info about an aspect of the requirement. | -| Design description languages | Use language like programming language, but with more abstract features specifying requirements by defining an operational model of the system. | -| Graphical notations | Graphical models with text annotations. e.g. UML use case and sequence diagrams. | -| Mathematical specifications | Based on math concepts like finite-state machines or sets. Most customers don't understand this so not often used. | - -==== Natural language specification ==== -requirements are written as natural language sentences. used because it's expressive, intuitive, universal, easily understood by customers. - -guidelines: - * invent a standard format, use it for all requirements. - * use language in a consistent way ("shall" for mandatory requirements, "should" for desirable requirements) - * highlight text to identify important parts of requirement - * avoid use of computer jargon - * include explanation (rationale) of why a requirement is needed - -==== Use case diagrams ==== -express expectations of customers/stakeholders. - -answers questions: - * what is being described? (the system) - * who interacts with the system? (the actors) - * what can the actors do? (use cases) - -use case: - * describes functionality expected from system under development - * set of all use cases describes functionality that a system shall provide. - * notations: - - {{file:img/use-case-notations.png|Use case notations}} - -actors: - * interact with the system by using use cases, or by being used by use cases. - * represent roles that users adopt (users can have multiple roles) - * not part of the system, so outside of system boundaries. - * human or non-human - * primary/secondary: - * if primary, has main benefit of execution of use case. - * if secondary, receives no direct benefit. - * active or passive - * active: initiates execution of the use case - * passive: provides functionality for the execution of the use case - - {{file:img/actor-notations.png|Actor notations}} - -relationships between use cases and actors: - * actors are connected with use cases via associations (solid lines) - * every actors has to communicate with at least one use case - * association is always binary, multiplicities can be specified - - {{file:img/usecase-actor-rel.png|Relationships between actors and use cases}} - -relationships between use cases: - * «include» - * behavior of one use case ('included') _is always_ integrated in the behavior of another use case ('base') - - {{file:img/usecase-include-rel.png|Include relationship}} - * «extend» - * behavior of one use case ('extending') _may be_ integrated in behavior of another use case ('base') - * both use cases can also be executed independently of each other - * extension points are written directly in the use case. you can specify multiple extension points. - - {{file:img/use-case-extensions.png|Extensions in use cases}} - * generalization of use cases - * if use case A generalizes use case B, then B inherits behavior of A and may extend/overwrite it. B also inherits all relationships form A. - * A may be labeled {abstract} — cannot be executed directly, only B is executable - - {{file:img/usecase-generalisation.png|Generalisation}} - -relationships between actors - * generalization - * actor A inherits from actor B. e.g. A can communicate with X and Y, B can only communicate with Y. - * abstract actors are possible - - {{file:img/actor-generalization.png|Actor generalization}} - -Description of use cases: - * Name - * Short description - * Precondition: prerequisite for successful execution - * Postcondition: system state after successful execution - * Error situations: errors relevant to problem domain - * System state on occurrence of an error - * Actors that communicate with the use case - * Trigger: events which initiate the use case - * Standard process: individual steps to be taken - * Alternative processes: deviations from the standard process - -Remember, it's an abstraction. Many small use cases with the same objective should be grouped. Don't decompose functionality into use cases. - -=== Summary of notation === -{{file:img/requirement-notation-p1.png|Requirements notation}} - -{{file:img/requirement-notation-p2.png|Requirements notation}} - diff --git a/content/softdesign-notes/src/sequence-diagrams.wiki b/content/softdesign-notes/src/sequence-diagrams.wiki @@ -1,200 +0,0 @@ -== Sequence Diagrams == -=== Introduction === -it's a way to model interactions between objects - -interaction specifies how messages and data are exchanged between objects - -interaction partners: human (lecturer, admin) or non-human (server, printer, software) - -interactions: conversation between people, message exchange between human and software, communication protocols, sequence of method calls in program, etc. - -=== Basics === -==== Interactions, interaction partners ==== -a sequence diagram is 2D: - * horizontal axis: involved interaction partners - * vertical axis: chronological order of interaction - -interaction: sequence of event specifications - -{{file:img/sequence-diagram-example.png|Sequence diagram example}} - -interaction partners are lifelines: - * head of lifeline is rectangle containing `object:Class` - * body of lifeline is vertical dashed line representing lifetime of associated object - -==== Messages ==== -message is defined via send and receive events - -execution specification (optional): - * continuous bar - * used to visualize when interaction partner executes a behavior - -{{file:img/exchanging-messages-example-on-diagram.png|Exchanging messages example on diagram}} - -rules: - -{{file:img/exchanging-messages-rules.png|Exchanging messages rules}} - -synchronous message: - * sender waits until it has received response message before continuing - * syntax: `msg(par₁, par₂)` - * `msg`: name of message - * `par`: parameters - * notation: {{file:img/synchronous-message.png|Synchronous message}} - -asynchronous message: - * sender continues without waiting for response msg - * syntax: `msg(par₁, par₂)` - * notation: {{file:img/asynchronous-message.png|asynchronous message}} - -response message: - * can be omitted if content and location are obvious - * syntax: `att = msg(par₁, par₂): val` - * `att`: return value assigned to variable (optional) - * `msg`: name of message - * `par`: parameters - * `val`: return value - * notation: {{file:img/response-message.png|response message}} - -object creation: - * dashed arrow, arrowhead pointing to head of lifeline of object that's being created - * keyword `new` - * notation: {{file:img/object-creation-.png|Object creation}} - -object destruction: - * object is deleted - * large cross at end of lifeline - * notation: {{file:img/object-destruction-.png|Object destruction}} - -found message: - * sender unknown/not relevant - * notation: {{file:img/found-message.png|Found message}} - -lost message: - * receiver unknown/not relevant - * notation: {{file:img/lost-message.png|Lost message}} - -Time-consuming message: - * message with duration - * usually messages transmitted instantly (by assumption); not in this case - * notation: {{file:img/time-consuming-message.png|Time-consuming message}} - -=== Combined fragments === -model various control structures, have 12 predefined operators. - -Example: - -{{file:img/combined-fragment-example.png|Combined fragment example}} - -==== Branches & loops ==== -`alt`: - * alternative sequence - * like a switch statement, with guards selecting the path to be executed - * guards modeled in square brackets, default true - * guards have to be disjoint so that behavior is deterministic! - - {{file:img/alt-fragment.png|Alt fragment}} - -`opt`: - * optional sequence - * like an if without an else - * actual execution depends on guard - * exactly one operand - - {{file:img/opt-fragment.png|Opt fragment}} - -`loop`: - * repeated sequence - * min/max number of iterations - `(min..max)` or `(min, max)`. default `(*)`, no upper limit. - * guard evaluated when min number of iterations took place, checked on each iteration. loop quits if false. - - {{file:img/loop-fragment.png|Loop fragment}} - -`break`: - * exception handling - * one operand with a guard. if true: - * interactions within operand are executed - * remaining operations of _surrounding_ fragment don't run - * interaction continues at next higher level fragment (so like you skip a level) - - {{file:img/break-fragment.png|Break fragment}} - -==== Concurrency and order ==== -`seq`: - * weak sequencing, default order of events - * can't skip around on the same lifeline - - {{file:img/seq-fragment.png|Seq fragment}} - -`strict`: - * strict order - * fixed sequence of events across lifelines - * order of events on different lifelines between different operands is significant - * messages in operand higher up on vertical axis are _always_ exchanged before the ones that are lower - - {{file:img/strict-fragment.png|Strict fragment}} - -`par`: - * concurrent interaction - * relax chronological order between messages in different operands - * restrictions in each operand have to be respected - * order of different operands is irrelevant - - {{file:img/par-fragment-.png|Par fragment}} - -`critical`: - * atomic interaction - * make sure that certain parts of interaction aren't interrupted by unexpected events - * _always_ has to be in that order - - {{file:img/critical-fragment.png|Critical fragment}} - -==== Filters and assertions ==== -`ignore`: - * irrelevant interaction - * messages can occur at runtime but don't have other significance - * one operand, irrelevant messages in curly brackets after keyword `ignore` - - {{file:img/ignore-fragment.png|Ignore fragment}} - -`consider`: - * relevant interaction with a particular importance - * one operand. "dual" to ignore fragment - * considered messages in curly brackets - * and yes, you can use `ignore` instead of `consider` and vice-versa - - {{file:img/consider-fragment.png|Consider fragment}} - -`assert`: - * asserted interaction - * mandatory interactions. the model is complete. can't have any deviations. - - {{file:img/assert-fragment.png|Assert fragment}} - -`neg`: - * invalid interaction - * describe situations that must not occur - * depicting relevant but _incorrect_ sequences - -{{file:img/neg-fragment.png|Neg fragment}} - -=== Further language elements === -time constraints: - * point in time for event occurrence: `after(5sec)`, `at(12.00)` - * time period between two events: `{lower..upper}` - * `now`: current time - * duration: calculation of duration of message transmission - -Interaction reference: - * integrates one sequence diagram in another sequence diagram - * define with `sd name` in the corner, then use the name in the diagram with `ref` in the corner - -Gate: - * allows to send and receive messages beyond boundaries of interaction fragment - -state invariant: - * asserts certain condition has to be true at certain time - * if state invariant is not true, either model or implementation is wrong - * notations: - - {{file:img/state-invariant-diagram.png|State invariant diagram}} diff --git a/content/softdesign-notes/src/software-abstraction-modeling.wiki b/content/softdesign-notes/src/software-abstraction-modeling.wiki @@ -1,32 +0,0 @@ -== Software abstraction & modeling == -software engineering: the application of engineering to software. a programmer writes a complete program, a software engineer creates a component. - -engineers abstract away from details that can be _safely_ ignored. - -model: simplified/partial representation of reality, defined to accomplish a task or reach an agreement - -abstraction: generalizing – setting aside specific and individual features - -software design: creating models representing an abstract view of the system - -=== Models === -what is a model? - * mapping feature: a model is based on an original - * reduction feature: a model only reflects a relevant selection of the original's properties - * pragmatic feature: a model needs to be usable in place of an original with respect to some purpose - -consumer and intent influence the abstraction level of a model - -descriptive models: - * a subject is described by the model - * sketches and throw-away models – short life time, used to better understand the reality - * models of ideas and vision about the system to be developed – to exploit model for having feedback before actually implementing the system - * models extracted from a running system or code – e.g. to visualize all calls between Java classes - -prescriptive models: - * a model prescribes the subject - * the subject does not yet exist - * the models guide the development of the system - * most common consumers are code generators - * often used for development, so their importance may decay when the system is implemented - diff --git a/content/softdesign-notes/src/software-development-process.wiki b/content/softdesign-notes/src/software-development-process.wiki @@ -1,63 +0,0 @@ -== Software development process == - -main activities: - * requirements engineering - * specifies the main functionalities of the system - * defines the qualities to be met - * design - * give shape to a system via models - * not a clear-cut sequential process - * implementation and testing - * involves actual development of the system - * component testing – test individual components independently - * system testing – test the system as a whole (including emergent properties like overall performance) - * acceptance testing – test with customer data to see if the system meets the customer's needs - * evolution - * software is inherently flexible and can change - -=== Waterfall development process === - -{{file:img/waterfall-dev.png|Waterfall dev process image}} - -exists in many variants, all with sequential flow. it's document-driven. - -issues: poor agility (when do you know how far you are in the project?), poor quality (cuts if you run out of time), high risk (finding issues in test phase) - -critical evaluation: - * positive: - * precise planning and management – standard-oriented - * postpone implementation to after understanding objectives - * good documentation - * negative: - * hard to get all requirements once and for all (users might not even know what they want) - * rigid - * no feedback from the customer - * no parallelism, all phases are blocking (because sequential) - * a single delivery date at the end - -=== Agile development process === -iterative development processes with: - * frequent releases of the product - * continuous interaction between dev team and customer - * reduced product documentation - * continuous and systematic assessment of produced value and risks - -agile in practice: - * make a list - * estimate - * set priorities - * start executing - * update the plan at run time - -critical evaluation: - * positive: - * acceptance of change – less risky - * frequent and short iterations - * emphasis on working code - * associates a test with every piece of functionality - * continuous integration and delivery - * negative: - * feature-based development & ignorance of dependencies - * no strong quality plan - * less focus on architecture of system (in fact, dismisses everything that isn't shippable) - diff --git a/content/softdesign-notes/src/structure-modeling.wiki b/content/softdesign-notes/src/structure-modeling.wiki @@ -1,170 +0,0 @@ -== Structure modeling with UML == - -=== Class === - -a construction plan for a set of similar objects of a system - -{{file:img/uml-class.png|UML Class Diagram}} - -==== Attribute syntax ==== - -{{file:img/uml-attribute-syntax.png|UML Attribute Syntax}} - -Visibility: who is permitted to access the attribute - * `+` public, everybody - * `-` private, only the object itself - * `#` protected, class itself and subclasses - * `~` package, classes that are in the same package - -`/` means that attribute value is derived from other attributes - -Type: - * primitive data type - * pre-defined: Boolean, Integer, UnlimitedNatural, String - * User-defined: «primitive» - * composite: «datatype» - * enumerations: «enumeration» - - {{file:img/uml-data-types.png|UML Data Types}} - -Multiplicity: number of values an attribute may contain (as [min..max], max can be `*` meaning no limit) - -`= Default`: the default value that's used if the user doesn't explicitly set a value - -properties: - * `[readOnly]` - value can't be changed - * `[unique]` - no duplicates allowed - * `[non-unique]` - duplicates allowed - * `[ordered]` - fixed order of values - * `[unordered]` - no fixed order of values - -==== Operation syntax ==== - -{{file:img/uml-operation-syntax.png|UML operation syntax}} - -Similar to attributes. - -parameter: - * direction - * `in`: input parameter (value is expected) - * `out`: output parameter (adopts a new value after execution of operation) - * `inout`: combined input/output - -{{file:img/uml-operation-parameter-notation.png|UML operation parameter notation}} - -type: type of return value - -==== Class variable and class operation ==== -Class variable (static): defined only once per class, shared by all instances - -Class operation (static): can be used without creating an instance - -To distinguish class variables/operations, underline them. - -=== Relationships === - -==== Binary association ==== -Connects instances of two classes with one another. - -{{file:img/uml-class-binary-association.png|UML Class Binary association}} - -Properties: - * Navigability: an object knows its partner objects, can access their visible attributes and operations (open arrow head, if not then cross). If undefined, bidirectional is assumed. - * Multiplicity: number of objects that can be associated with exactly one object of the opposite side (e.g. one-to-one, one-to-many...) - * Role: how an object is involved in an association relationship - * `xor` constraint: cannot be associated with both at the same time - -in Java: - -{{{ -class Professor {...} - -class Student { - public Professor[] lecturer; -} -}}} - -==== n-ary association ==== -More than two objects involved in the relationship, no navigation directions. - -{{file:img/uml-class-ternary-association.png|UML Class Ternary Association}} - -==== Association class ==== -Assign attributes to relationship between classes instead of to a class. - -{{file:img/uml-class-association-class.png|UML Class Association class}} - -Needed for n:m associations. - -Association class vs regular class: - -{{file:img/uml-class-association-vs-regular.png|UML Class Association vs regular}} - -Can be unique or non-unique. - -==== Aggregation ==== -Shows that class is part of another class. - -Properties: - * transitive: if B is part of A and C is part of B, C is also part of A - * asymmetric: not possible for A to be part of B and B to be part of A at the same time - -===== Shared aggregation ===== -expresses weak belonging of the parts to a whole (parts also exist independently of the whole). one element can be part of multiple other elements at the same time. - -Example: - -{{file:img/uml-class-shared-aggregation-example.png|UML Class shared aggregation example}} - -===== Composition ===== -existence dependency between composite object and its parts. one part can be contained in max one composite object at a point in time. if the composite object is deleted, so are its parts. - -A `Tire` can exist without a `Car`. A `Tire` belongs to max one `Car`: - -{{file:img/uml-class-composition-example.png|UML Class composition example}} - -==== Generalization ==== -stuff from a superclass is passed to its subclass (attributes, operations, associations, aggregations) - -every instance of a subclass is simultaneously an indirect instance of the superclass. subclass inherits all characteristics except private ones. generalizations are transitive. a class may have multiple superclasses/subclasses. - -{{file:img/uml-class-generalisation.png|UML Class generalisation}} - -abstract class ensures that there are no direct instances of the superclass. - -{{file:img/uml-class-abstract.png|UML Class abstract}} - -=== Creating a class diagram === -nouns often indicate classes. adjectives indicate attribute values. verbs indicate operations. - -in general, tend towards having deep classes. push complexity as low as possible in the class diagram hierarchy. - -focus on: - * responsibility of each class (private is default, `getter` and `setter` methods) - * knowledge needed by each class (tend toward generality, don't focus on order of tasks) - * usability of operations of each class (exposed APIs should be as easy and intuitive as possible - -generalization: "there is difference between research and administrative employees. some research associates hold courses, so they are lecturers." - -{{file:img/uml-natural-text-generalization.png|UML Natural text generalization}} - -composition: "a university consists of multiple faculties which are composed of various institutes." - -{{file:img/uml-natural-text-composition.png|UML Natural text composition}} - -binary association: "each faculty is led by a dean, who is an employee of the university" - -{{file:img/uml-natural-text-binary-association.png|UML Natural text binary association}} - -shared aggregation: "research associates are assigned to at least one institute" - -{{file:img/uml-natural-text-shared-aggregation.png|UML Natural text shared aggregation}} - -association class: "research associates can be involved in projects for a certain number of hours" - -{{file:img/uml-natural-text-association-class.png|UML Natural text association class}} - -generalization: "some research associates hold courses. then they are called lecturers." - -{{file:img/uml-natural-text-inheritance.png|UML Natural text inheritance}} - diff --git a/content/softdesign-notes/structure-modeling.html b/content/softdesign-notes/structure-modeling.html @@ -1,369 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> -<link rel="Stylesheet" type="text/css" href="style.css"> -<title>structure-modeling</title> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -</head> -<body> - -<div id="Structure modeling with UML"><h2 id="Structure modeling with UML">Structure modeling with UML</h2></div> - -<div id="Structure modeling with UML-Class"><h3 id="Class">Class</h3></div> - -<p> -a construction plan for a set of similar objects of a system -</p> - -<p> -<img src="img/uml-class.png" alt="UML Class Diagram" /> -</p> - -<div id="Structure modeling with UML-Class-Attribute syntax"><h4 id="Attribute syntax">Attribute syntax</h4></div> - -<p> -<img src="img/uml-attribute-syntax.png" alt="UML Attribute Syntax" /> -</p> - -<p> -Visibility: who is permitted to access the attribute -</p> -<ul> -<li> -<code>+</code> public, everybody - -<li> -<code>-</code> private, only the object itself - -<li> -<code>#</code> protected, class itself and subclasses - -<li> -<code>~</code> package, classes that are in the same package - -</ul> - -<p> -<code>/</code> means that attribute value is derived from other attributes -</p> - -<p> -Type: -</p> -<ul> -<li> -primitive data type - -<ul> -<li> -pre-defined: Boolean, Integer, UnlimitedNatural, String - -<li> -User-defined: «primitive» - -<li> -composite: «datatype» - -</ul> -<li> -enumerations: «enumeration» - -</ul> -<blockquote> -<img src="img/uml-data-types.png" alt="UML Data Types" /> -</blockquote> - -<p> -Multiplicity: number of values an attribute may contain (as [min..max], max can be <code>*</code> meaning no limit) -</p> - -<p> -<code>= Default</code>: the default value that's used if the user doesn't explicitly set a value -</p> - -<p> -properties: -</p> -<ul> -<li> -<code>[readOnly]</code> - value can't be changed - -<li> -<code>[unique]</code> - no duplicates allowed - -<li> -<code>[non-unique]</code> - duplicates allowed - -<li> -<code>[ordered]</code> - fixed order of values - -<li> -<code>[unordered]</code> - no fixed order of values - -</ul> - -<div id="Structure modeling with UML-Class-Operation syntax"><h4 id="Operation syntax">Operation syntax</h4></div> - -<p> -<img src="img/uml-operation-syntax.png" alt="UML operation syntax" /> -</p> - -<p> -Similar to attributes. -</p> - -<p> -parameter: -</p> -<ul> -<li> -direction - -<ul> -<li> -<code>in</code>: input parameter (value is expected) - -<li> -<code>out</code>: output parameter (adopts a new value after execution of operation) - -<li> -<code>inout</code>: combined input/output - -</ul> -</ul> - -<p> -<img src="img/uml-operation-parameter-notation.png" alt="UML operation parameter notation" /> -</p> - -<p> -type: type of return value -</p> - -<div id="Structure modeling with UML-Class-Class variable and class operation"><h4 id="Class variable and class operation">Class variable and class operation</h4></div> -<p> -Class variable (static): defined only once per class, shared by all instances -</p> - -<p> -Class operation (static): can be used without creating an instance -</p> - -<p> -To distinguish class variables/operations, underline them. -</p> - -<div id="Structure modeling with UML-Relationships"><h3 id="Relationships">Relationships</h3></div> - -<div id="Structure modeling with UML-Relationships-Binary association"><h4 id="Binary association">Binary association</h4></div> -<p> -Connects instances of two classes with one another. -</p> - -<p> -<img src="img/uml-class-binary-association.png" alt="UML Class Binary association" /> -</p> - -<p> -Properties: -</p> -<ul> -<li> -Navigability: an object knows its partner objects, can access their visible attributes and operations (open arrow head, if not then cross). If undefined, bidirectional is assumed. - -<li> -Multiplicity: number of objects that can be associated with exactly one object of the opposite side (e.g. one-to-one, one-to-many...) - -<li> -Role: how an object is involved in an association relationship - -<li> -<code>xor</code> constraint: cannot be associated with both at the same time - -</ul> - -<p> -in Java: -</p> - -<pre> -class Professor {...} - -class Student { - public Professor[] lecturer; -} -</pre> - -<div id="Structure modeling with UML-Relationships-n-ary association"><h4 id="n-ary association">n-ary association</h4></div> -<p> -More than two objects involved in the relationship, no navigation directions. -</p> - -<p> -<img src="img/uml-class-ternary-association.png" alt="UML Class Ternary Association" /> -</p> - -<div id="Structure modeling with UML-Relationships-Association class"><h4 id="Association class">Association class</h4></div> -<p> -Assign attributes to relationship between classes instead of to a class. -</p> - -<p> -<img src="img/uml-class-association-class.png" alt="UML Class Association class" /> -</p> - -<p> -Needed for n:m associations. -</p> - -<p> -Association class vs regular class: -</p> - -<p> -<img src="img/uml-class-association-vs-regular.png" alt="UML Class Association vs regular" /> -</p> - -<p> -Can be unique or non-unique. -</p> - -<div id="Structure modeling with UML-Relationships-Aggregation"><h4 id="Aggregation">Aggregation</h4></div> -<p> -Shows that class is part of another class. -</p> - -<p> -Properties: -</p> -<ul> -<li> -transitive: if B is part of A and C is part of B, C is also part of A - -<li> -asymmetric: not possible for A to be part of B and B to be part of A at the same time - -</ul> - -<div id="Structure modeling with UML-Relationships-Aggregation-Shared aggregation"><h5 id="Shared aggregation">Shared aggregation</h5></div> -<p> -expresses weak belonging of the parts to a whole (parts also exist independently of the whole). one element can be part of multiple other elements at the same time. -</p> - -<p> -Example: -</p> - -<p> -<img src="img/uml-class-shared-aggregation-example.png" alt="UML Class shared aggregation example" /> -</p> - -<div id="Structure modeling with UML-Relationships-Aggregation-Composition"><h5 id="Composition">Composition</h5></div> -<p> -existence dependency between composite object and its parts. one part can be contained in max one composite object at a point in time. if the composite object is deleted, so are its parts. -</p> - -<p> -A <code>Tire</code> can exist without a <code>Car</code>. A <code>Tire</code> belongs to max one <code>Car</code>: -</p> - -<p> -<img src="img/uml-class-composition-example.png" alt="UML Class composition example" /> -</p> - -<div id="Structure modeling with UML-Relationships-Generalization"><h4 id="Generalization">Generalization</h4></div> -<p> -stuff from a superclass is passed to its subclass (attributes, operations, associations, aggregations) -</p> - -<p> -every instance of a subclass is simultaneously an indirect instance of the superclass. subclass inherits all characteristics except private ones. generalizations are transitive. a class may have multiple superclasses/subclasses. -</p> - -<p> -<img src="img/uml-class-generalisation.png" alt="UML Class generalisation" /> -</p> - -<p> -abstract class ensures that there are no direct instances of the superclass. -</p> - -<p> -<img src="img/uml-class-abstract.png" alt="UML Class abstract" /> -</p> - -<div id="Structure modeling with UML-Creating a class diagram"><h3 id="Creating a class diagram">Creating a class diagram</h3></div> -<p> -nouns often indicate classes. adjectives indicate attribute values. verbs indicate operations. -</p> - -<p> -in general, tend towards having deep classes. push complexity as low as possible in the class diagram hierarchy. -</p> - -<p> -focus on: -</p> -<ul> -<li> -responsibility of each class (private is default, <code>getter</code> and <code>setter</code> methods) - -<li> -knowledge needed by each class (tend toward generality, don't focus on order of tasks) - -<li> -usability of operations of each class (exposed APIs should be as easy and intuitive as possible - -</ul> - -<p> -generalization: "there is difference between research and administrative employees. some research associates hold courses, so they are lecturers." -</p> - -<p> -<img src="img/uml-natural-text-generalization.png" alt="UML Natural text generalization" /> -</p> - -<p> -composition: "a university consists of multiple faculties which are composed of various institutes." -</p> - -<p> -<img src="img/uml-natural-text-composition.png" alt="UML Natural text composition" /> -</p> - -<p> -binary association: "each faculty is led by a dean, who is an employee of the university" -</p> - -<p> -<img src="img/uml-natural-text-binary-association.png" alt="UML Natural text binary association" /> -</p> - -<p> -shared aggregation: "research associates are assigned to at least one institute" -</p> - -<p> -<img src="img/uml-natural-text-shared-aggregation.png" alt="UML Natural text shared aggregation" /> -</p> - -<p> -association class: "research associates can be involved in projects for a certain number of hours" -</p> - -<p> -<img src="img/uml-natural-text-association-class.png" alt="UML Natural text association class" /> -</p> - -<p> -generalization: "some research associates hold courses. then they are called lecturers." -</p> - -<p> -<img src="img/uml-natural-text-inheritance.png" alt="UML Natural text inheritance" /> -</p> - -</body> -</html> diff --git a/content/softdesign-notes/structure-modeling/index.md b/content/softdesign-notes/structure-modeling/index.md @@ -0,0 +1,173 @@ ++++ +title = 'Structure modeling with UML' ++++ +## Structure modeling with UML + +### Class + +a construction plan for a set of similar objects of a system + + + +#### Attribute syntax + + + +Visibility: who is permitted to access the attribute +* `+` public, everybody +* `-` private, only the object itself +* `#` protected, class itself and subclasses +* `~` package, classes that are in the same package + +`/` means that attribute value is derived from other attributes + +Type: +* primitive data type + * pre-defined: Boolean, Integer, UnlimitedNatural, String + * User-defined: «primitive» + * composite: «datatype» +* enumerations: «enumeration» + + + +Multiplicity: number of values an attribute may contain (as [min..max], max can be `*` meaning no limit) + +`= Default`: the default value that's used if the user doesn't explicitly set a value + +properties: +* `[readOnly]` - value can't be changed +* `[unique]` - no duplicates allowed +* `[non-unique]` - duplicates allowed +* `[ordered]` - fixed order of values +* `[unordered]` - no fixed order of values + +#### Operation syntax + + + +Similar to attributes. + +parameter: +* direction + * `in`: input parameter (value is expected) + * `out`: output parameter (adopts a new value after execution of operation) + * `inout`: combined input/output + + + +type: type of return value + +#### Class variable and class operation +Class variable (static): defined only once per class, shared by all instances + +Class operation (static): can be used without creating an instance + +To distinguish class variables/operations, underline them. + +### Relationships + +#### Binary association +Connects instances of two classes with one another. + + + +Properties: +* Navigability: an object knows its partner objects, can access their visible attributes and operations (open arrow head, if not then cross). If undefined, bidirectional is assumed. +* Multiplicity: number of objects that can be associated with exactly one object of the opposite side (e.g. one-to-one, one-to-many...) +* Role: how an object is involved in an association relationship +* `xor` constraint: cannot be associated with both at the same time + +in Java: + +```java +class Professor {...} + +class Student { + public Professor[] lecturer; +} +``` + +#### n-ary association +More than two objects involved in the relationship, no navigation directions. + + + +#### Association class +Assign attributes to relationship between classes instead of to a class. + + + +Needed for n:m associations. + +Association class vs regular class: + + + +Can be unique or non-unique. + +#### Aggregation +Shows that class is part of another class. + +Properties: +* transitive: if B is part of A and C is part of B, C is also part of A +* asymmetric: not possible for A to be part of B and B to be part of A at the same time + +##### Shared aggregation +expresses weak belonging of the parts to a whole (parts also exist independently of the whole). one element can be part of multiple other elements at the same time. + +Example: + + + +##### Composition +existence dependency between composite object and its parts. one part can be contained in max one composite object at a point in time. if the composite object is deleted, so are its parts. + +A `Tire` can exist without a `Car`. A `Tire` belongs to max one `Car`: + + + +#### Generalization +stuff from a superclass is passed to its subclass (attributes, operations, associations, aggregations) + +every instance of a subclass is simultaneously an indirect instance of the superclass. subclass inherits all characteristics except private ones. generalizations are transitive. a class may have multiple superclasses/subclasses. + + + +abstract class ensures that there are no direct instances of the superclass. + + + +### Creating a class diagram +nouns often indicate classes. adjectives indicate attribute values. verbs indicate operations. + +in general, tend towards having deep classes. push complexity as low as possible in the class diagram hierarchy. + +focus on: +* responsibility of each class (private is default, `getter` and `setter` methods) +* knowledge needed by each class (tend toward generality, don't focus on order of tasks) +* usability of operations of each class (exposed APIs should be as easy and intuitive as possible + +generalization: "there is difference between research and administrative employees. some research associates hold courses, so they are lecturers." + + + +composition: "a university consists of multiple faculties which are composed of various institutes." + + + +binary association: "each faculty is led by a dean, who is an employee of the university" + + + +shared aggregation: "research associates are assigned to at least one institute" + + + +association class: "research associates can be involved in projects for a certain number of hours" + + + +generalization: "some research associates hold courses. then they are called lecturers." + + + diff --git a/content/softdesign-notes/img/uml-attribute-syntax.png b/content/softdesign-notes/structure-modeling/uml-attribute-syntax.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-abstract.png b/content/softdesign-notes/structure-modeling/uml-class-abstract.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-association-class.png b/content/softdesign-notes/structure-modeling/uml-class-association-class.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-association-vs-regular.png b/content/softdesign-notes/structure-modeling/uml-class-association-vs-regular.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-binary-association.png b/content/softdesign-notes/structure-modeling/uml-class-binary-association.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-composition-example.png b/content/softdesign-notes/structure-modeling/uml-class-composition-example.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-generalisation.png b/content/softdesign-notes/structure-modeling/uml-class-generalisation.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-shared-aggregation-example.png b/content/softdesign-notes/structure-modeling/uml-class-shared-aggregation-example.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class-ternary-association.png b/content/softdesign-notes/structure-modeling/uml-class-ternary-association.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-class.png b/content/softdesign-notes/structure-modeling/uml-class.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-data-types.png b/content/softdesign-notes/structure-modeling/uml-data-types.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-association-class.png b/content/softdesign-notes/structure-modeling/uml-natural-text-association-class.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-binary-association.png b/content/softdesign-notes/structure-modeling/uml-natural-text-binary-association.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-composition.png b/content/softdesign-notes/structure-modeling/uml-natural-text-composition.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-generalization.png b/content/softdesign-notes/structure-modeling/uml-natural-text-generalization.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-inheritance.png b/content/softdesign-notes/structure-modeling/uml-natural-text-inheritance.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-natural-text-shared-aggregation.png b/content/softdesign-notes/structure-modeling/uml-natural-text-shared-aggregation.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-operation-parameter-notation.png b/content/softdesign-notes/structure-modeling/uml-operation-parameter-notation.png Binary files differ. diff --git a/content/softdesign-notes/img/uml-operation-syntax.png b/content/softdesign-notes/structure-modeling/uml-operation-syntax.png Binary files differ. diff --git a/content/softdesign-notes/style.css b/content/softdesign-notes/style.css @@ -1,38 +0,0 @@ -@charset 'UTF-8'; -@font-face{font-family:'FontAwesome';src:url('font/fontawesome-webfont.eot?v=4.0.1');src:url('font/fontawesome-webfont.eot?#iefix&v=4.0.1') format('embedded-opentype'),url('font/fontawesome-webfont.woff?v=4.0.1') format('woff'),url('font/fontawesome-webfont.ttf?v=4.0.1') format('truetype'),url('font/fontawesome-webfont.svg?v=4.0.1#fontawesomeregular') format('svg');font-weight:normal;font-style:normal} - -body { - margin: 0px; - padding: 1em; - background: #f3f2ed; - font-family: 'Lato', sans-serif; - font-size: 12pt; - font-weight: 300; - color: #8A8A8A; - padding-left: 50px; -} -h1 { - margin: 0px; - padding: 0px; - font-weight: 300; - text-align: center; -} -ul.toc li { - margin: 8px 0; -} -h3.name { - font-style: italic; - text-align: center; - font-weight: 300; - font-size: 20px; -} -a { - color: #D1551F; - } -a:hover { - color: #AF440F; -} - strong { - font-weight: 700; - color: #2A2A2A; - }
