Software Architecture (2019/20)

VO/KU (706.706/706.707)

This course highlights the importance of developing a software architecture for complex software systems. The course focuses on investigating properties of proven software architectures and involves students in applying those architectures in a software project.

The knowledge about various software architectures have evolved from numerous software engineering projects over past 40+ years. "Successful" software architectures have been iteratively developed across multiple software projects. Those architectures have emerged from the experience of many software engineers involved in these projects.

In this course we will investigate and apply such exemplary software architectures.

Slides from the last years are available: 2018, 2017, 2016, 2015, 2014, 2013, 2012

Content

Course topics include:

  • Definitions of systems, software systems, and complexity
  • Definition of software architecture
  • Analysis and design of software architecture
  • Architectural views
  • Conceptual, execution, and implementation view on software architecture
  • Architectural prototype in an OO programming language
  • Architectural styles
  • Real-world examples: Web and service architectures, big distributed architectures,...

Theoretical Goals

In this course the students will learn about:

  • Importance of developing a software architecture
  • A particular notation for describing a software architecture
  • Different views on software architecture
  • Proven software architectures
  • Software quality attributes
  • Successful systems and their software architectures
  • Architectural patterns
  • Heterogeneity of software architectures

Practical Goals

At the end of this course the students will know how to:

  • Analyse the requirements to obtain a conceptual architecture
  • Design an execution and an implementation architecture
  • Address both functional and non-functional requirements
  • Design and implement an OO architectural prototype by following a set of OO design principles
  • Document all the steps

The lectures take place Wednesday, 15:45 - 17:45, HS i9

Online resources

Online resources

Method, grading

Examination in SA is a written one. The students get 25 multiple choice questions, plus 3 open questions which they need to answer in 90 minutes.

For each multiple choice question there are 4 answers offered. For some questions only a single answer is correct. Alternatively, there are questions with two correct answers. The number of correct answers is always indicated. In case that there is a single correct answer the students obtain 2 points for answering correctly. In case where two answers are correct the students obtain 1 point for each of the correct answers, totalling 2 points if both of the correct answers are chosen. Thus, the total number of points is 50 (multiple choice) + 30 (open).

The students get 5 questions for 5 selected topics, plus 3 open questions. For every student the questions are randomly selected from the topic question pool. There are around 20 questions in each topic question pool. Thus, every student gets a different set of questions.

Topics

The question topics are:

  • SA definition
  • Quality attributes
  • SA analysis, design, and conceptual architecture
  • Execution and implementation architecture
  • OO design principles
  • Architecture patterns & styles
  • Service architectures
  • Distributed architectures

The grading scheme is as follows:

  • 0-40 points: 5
  • 41-50 points: 4
  • 51-60 points: 3
  • 61-70 points: 2
  • 71-80 points: 1

Examination date

The examination date is always the last course date in January: 29.01.2020. The students need to register for the examination in TUGOnline.

Sample Questions

Example 1: What is a blob in a conceptual architecture?

  1. It is an object that keeps references to all other objects in the system.
  2. A blob is a component that have too much responsibilities. It is a result of being too lazy dividing the system into components.
  3. A couple of components with single responsibility but all interconnected. In fact these components are interrelated and can be put into a single component.
  4. It is an abstract base class used as a root of a class hierarchy.

1 answer is correct (2 points)

Example 2: Is something wrong with the following code snippet?

public void driveCar(Car car) {
	if(car instanceof PersonalCar){
		((PersonalCar) car).drive();
	}else if(car instanceof SportsCar){
		((SportsCar) car).driveFast();
}
			
  1. The method should take another argument which signals the type of car being passed to the method - to avoid using instanceof operator.
  2. There is a violation of Open-Closed principle. This class can not be extended without modifying it, i.e. a new type of car will require modification of the code.
  3. Nothing is wrong. The code compiles and runs as expected.
  4. The class should provide two different methods for each type of car - to avoid using cast operator.

1 answer is correct (2 points)

Example 3: Open-closed principle states that classes should be open for extension, but closed for modification. What does it mean for a class to be open for extension?

  1. New superclasses of the class can be defined.
  2. Behaviour of the class can be extended (changed) to satisfy changing requirements.
  3. Source code of the class can be extended (changed).
  4. New instance variables for the class can be defined.

1 answer is correct (2 points)

Example 4: Which of these systems are typical examples of layered systems?

  1. Operating systems.
  2. Real-time video processing systems.
  3. Network protocol stacks.
  4. GUI event handling systems.

2 answers are correct (each correct answer 1 point)

Example 5: What is scalability of a software system?

  1. Ability of a system to vary its operational parameters without re-compiling or re-installing.
  2. Ability of a system to increase its capacity without re-compiling or re-installing.
  3. Ability of a system to be modified after deployment with ease.
  4. Ability of a system to test it.

1 answer is correct (2 points)

Example 6: You have an existing system based on a data-centric architecture (using a traditional relational database). Will this architecture will be well suited, if scalability is a strong requirement? (open question)

Example 7: A client asks for a simple web shop. How could the high-level conceptual architecture of this application look like (draw 3 - 7 components)? (open question)

There is one study assistant who support, supervise and grade students in their practical work. The study assistant is Srđan Džombić. Please feel free to contact your study assistant at dzombic@student.tugraz.at for any questions that arise during this course.

The goal for the practical part of the course is to apply the theoretical findings that are discussed in the lecture in practical settings. For that purpose the students will develop a software architecture and implement an architectural prototype for a web based system. The project is carried out in a team of 4 students. Please use this link to register the groups: http://tinyurl.com/sa2019-group-registration

The programming language, the database and the operating system can be freely chosen by the participants. The code should run on a notebook and each group should demonstrate their running applications at the submission interviews with their own computer.

Please make sure that your code is easily readable, reusable and maintainable. For illustration, your application should be usable by a elderly person, so please also think about the usability. Moreover, it should not take longer than a few seconds to get a response to a user's action.

The exercise is split into four separate tasks with two milestones - thus the timeline is:

  • Group registration until: 1.11.2019 (23:59)
  • First deadline is the 1.12.2019 (23:59)
    • where the first three tasks need to be completed (Unix-Pipeline, Single web service with API, conceptual architecture sketch)
  • Second deadline is the 19.1.2020 (23:59)
    • where the last task needs to be completed (Web application)

Submission

Handing in the submission is done via a Github repository. Before group registration you should make your private Github repository. On the group registration form you will be asked to give the link to your repository. Furthermore the tutor has to be added to the repository using his Github name or email:

  • Github name: srdjandzombic
  • Github email: dzombic@student.tugraz.at
With regards to the structure, the repository has to contain a separate folder for each task (e.g. 'task1', 'task2').

There are a total of 80 points to achieve. The overall grading is based on the implementation of the application, but there is the option of point deduction if the given answers at the submission interviews are inadequate. This will affect the whole group.

The submission interviews will be held on:

  • 05.12.2019 and 06.12.2019 for the first submission
  • 23.01.2020 and 24.01.2020 for the second submission

The grading scheme is as follows:

  • 0-40 points: 5
  • 41-50 points: 4
  • 51-60 points: 3
  • 61-70 points: 2
  • 71-80 points: 1

There needs to be a submission for each of the tasks in order to qualify for a positive grade.

The goal of the excercise is to implement a database-based application, while using different software architecture styles. The data for the application is taken from OpenStreetMap and should be filtered for shops in Graz. The user should be able to find shops by a point of interest (e.g. 'Jakominiplatz') or coordinates and a specified shop category (e.g. bakery) around a bounding box. A bounding box marks the area in which the application should search for the specified shops. The middle of the bounding box are the coordinates of the point of interest and its size should be adjustable by the user (e.g. 100m times 100m). Adding custom user own points of interest should be made possible for the signed in users by providing a name and the coordinates (lon, lat). There should be an option for users to save searches for later usage. Additionally the user needs to be able to add, edit and remove individual shops.

The tasks are: 1. Pipeline Architecture (Unix command line) 2. Single web service with API 3. Conceptual architecture sketch 4. Web application

The dataset:

Task 1 (Unix command line - 7 points): Write one Unix command pipeline to import the data-set into a database, making use of the pipe architecture and command line tools. After executing the command chain, the database should be completely populated. For this, the data will be processed, converted to CSV, filtered and then stored in the database.

Download OpenStreeMap-Data for Austria: (austria-latest.osm), write a Unix command pipeline (no bash-script, see later example) that solves following tasks:

  • Use osmfilter in order to keep ALL shop-nodes
  • Filter shops just within Graz.
    • To do this, you can use this .poly file: (Graz.poly)
  • Use osmconvert for converting it to CSV. You have to save at least the id, longitude, latitude, name and the homepage of the node (Feel free to add as many metadata as you wish to use it in your application for bonus points, e.g. opening hours).
  • Use only standard linux-console-programs (awk, sed, grep, ...) in order to filter out shops that do not have a name, if there are empty ones.
  • Load the content into a database of your choice (e.g. Postgres)

The creation of the database and table(s) also needs to happen in the pipeline. Furthermore, the pipeline must not fail if the database or the table(s) already exist. You may use a script to create the necessary database infrastructure or import the data, but the script needs to be executed from your pipeline.

Note: You may use permanent files but there must be at least two ‘|' chainings or redirect operators (‘>', ‘<‘) within the pipeline. For example: cat /proc/cpuinfo | grep -A 5 -B 5 MHz | grep 'core id' | awk NR==1

Task 2 (Single web service with API - 23 points): Write a web service with API routes for adding, modifying and deleting data stored in created database from previous task, which are accessible from e.g. terminal (with curl) or Postman. The overall goal is an accessible point to modify the database (add, edit and delete data).

List of requirements:

  • List and filter shops by category, name, around a point of interest (e.g. 100m). All 3 filters have to be combinable, but need to work independently as well. (5 points)
  • Save a search for later usage as a favourite by name (e.g. 'Essen am Jakominiplatz')(2 points)
  • Edit/delete an existing favourite (4 points)
  • Add/edit/delete a shop (6 points)
  • Add/edit/delete a POI (6 points)

Make sure that all functionality needs to be within one service, the only external service will be the database in this task.

Task 3 (Conceptual sketch - 5 points): Create a conceptual sketch depicting your planned microservices architecture for task 4. Make sure that you describe all services you will need for task 4. Submit the sketch as a PDF-File with a maximum of 2 pages in A4 format.

List of requirements:

  • At least 3 different services (each will run in a seperate docker container)

Task 4 (Web application - 45 points): Create several new microservices and GUI (frontend) to accomplish the client/server communication. At least 3 different microservices (every running in a separate docker container) are mandatory (including one service created in task 2).

List of requirements:

  • Enable user authentication: (in total 10 points)
    • users should be able to register with email, username, password and personal informations (name, surname, phone number - optional) (2 points)
    • users must confirm their email to finish registration (2 point)
    • users should be able to login (with email or username and password) and to logout (3 points)
    • users should be able to reset their password - email with 24 hours active link for reset (2 point)
    • passwords must be saved encrypted (1 point)
    • with optional own user database
  • Create mailing service communicating through message queue broker - confirmation/password reset emails should be sent over this service (8 points)
  • Extend routes in first microservice so that adding, editing, deleting and showing user's personal favourites, POIs and individual shops is only possible for authenticated user. (6 points)
  • Create GUI (frontend) for the web application (think about usability and design!) (10 points)
  • Dockerize every created microservice and frontend. Connect containers with Docker Compose (5 points) - you are able to use Docker-Compose template file from our GitHub Repo

List of dynamic requirements (choose any combination of features totalling at least 6 points):

  • Live filtering (automatically display filter results as you type) (2 point)
  • Inline editing for the shops table (2 points)
  • Use a third party API to find any place as a point of interest (e.g. type TU Graz and the third party API should return a list of names with its coordinates to choose from) (3 points)
  • Display the result of the filtering in a Google Maps/Open Streetmaps window (2 points)
  • Show the bounding box (1 point)
  • Use a circle instead of a bounding box to filter results (2 point)
  • Create logging service communicating through message queue broker - logs are saved to text file with timestamp and type and log message (4 points)
  • Your own awesome features. Contact us and we will tell you if they are okay and how many points you will get. (* points)

Notes: You will need to provide all Dockerfiles within your submission! If we cannot run your submission (with docker-compose up), we will deduct points.