Software Architecture (2018/19)

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: 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, 13:00 - 14:30, HS i13

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: 23.01.2019. 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 are two study assistants who support, supervise and grade students in their practical work. The study assistants are Jan Schlacher and Frederic Linn. Please feel free to contact your study assistants at sa.tugraz@gmail.com 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/sa2018-group-registration

p>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.2018 (23:59)
  • First deadline is the 2.12.2018 (23:59)
    • where the first three tasks need to be completed (Unix-Pipeline, Monolithic desktop application, conceptual sketch)
  • Second deadline is the 6.1.2019 (23:59)
    • where the last task needs to be completed (Web application)

Submission

Handing in the submission is done via a SVN repository. Please use the service provided by TU Graz (TUGRAZonline -> Dienste -> Subversion Projekte). The name format should be sa_2018_[group_number] (eg. 'sa_2018_03'). Remember the leading zero for single digit group numbers! Furthermore the tutors have to be added to the repository as readers using the following mail addresses

  • j.schlacher@student.tugraz.at
  • frederic.linn@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:

  • 06.12.2018 and 07.12.2018 for the first submission
  • 10.01.2019 and 11.01.2019 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 points of interest should be made possible for the user by providing a name and the coordinates (lon, lat). There should be an option to save the search results for later usage. Additionally the user needs to be able to add_edit_remove individual shops.

The tasks are: 1. Pipeline Architecture (Unix command line) 2. Monolithic desktop application 3. Conceptual architecture sketch 4. Web application

The dataset:

Task 1 (Unix command line - 10 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 (Monolithic desktop application - 25 points): Write an application to interactively work with the data stored in the database. The overall goal is a very simple shop finder around points of interest.

List of requirements:

  • Browse 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.
  • Save a search for later usage as a favourite by name (e.g. 'Essen am Jakominiplatz')
  • Edit/delete an existing favourite
  • Add/edit/delete a shop

Make sure that all functionality needs to be within your desktop app, 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 - 40 points): Write a web application that behaves the same as the desktop application in task 2 but this time you will need to create several microservices to accomplish the client/server communication. At least 3 different microservices running in a separate docker container are mandatory.

List of requirements:

  • All requirements from task 2
  • At least 3 docker containers
  • Create a database queue for inserting or updating data (Insert or update data only in batch sizes of 10 or every 10s, this might be an extra microservice)

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

  • Live filtering (automatically display filter results as you type) (3 points)
  • Inline editing for the shops table (3 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 either directly the coordinates or a list of names with its coordinates to choose from) (5-7 points)
  • Display the result of the filtering in a Google Maps/Open Streetmaps window (3 points)
  • Show the bounding box (2 points)
  • Use a circle instead of a bounding box to filter results (2 points)
  • Your own awesome features. Contact us and we will tell you if they are okay and how many points you will get. (* points)

Note: You will need to provide all Dockerfiles within your submission! If we cannot run your submission, we will deduct points.