Software Architecture (2017/18)

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: 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
  • 04.10.2017: Course organization & overview
  • 11.10.2017: KU course organization & CLI tutorial
  • 18.10.2017: OO design principles + software architecture analysis and design
  • 25.10.2017: Conceptual architecture
  • 08.11.2017: Execution architecture + Implementation architecture
  • 15.11.2017: Quality attributes
  • 22.11.2017: Web tutorials
  • 29.11.2017: Service architectures
  • 06.12.2017: Architectural styles I
  • 13.12.2018: Architectural styles II
  • 10.01.2018: Distributed architectures
  • 17.01.2018: Wrap-Up & Examples
  • 24.01.2018: Examination

Online resources

  • Terminology used in the course: Glossary

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: 24.01.2018. 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)

Method and grading

All students are required to register for the KU in TUGOnline until 6.10.2017, 23:59.

There will be two tutorials held within the lecture, the first on the 11.10.2017 for organisational background and a second on web development on the 22.11.2017.

In this term there are two study assistants who support, supervise, and grade students in their practical work. The study assistants are Jan Schlacher and Lorenz Leitner. Please, feel free to contact your study assistants at sa.tugraz@gmail.com for any questions that arise during this course. Please include SA[TUT] in the subject of your e-mail.

The goal of the practical part of the course is to apply the theoretical findings that are discussed in the lecture in a 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/sa2017-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 (or mobile device), where each group should demonstrate their running applications at the submission interview.

What your code should have (quality attributes):

  • Readability
  • Reusability
  • Maintainability
  • Performance
  • Usability, ...

The exercise is split into four separate tasks with 2 milestones - thus the time line is:

  • Group registration until: 01.11.2017 (23:59)
  • First deadline is 01.12.2017 (23:59), where the first two tasks need to be completed (Unix-Pipeline, standalone GUI application/mobile app).
  • Second deadline is 05.01.2017 (23:59) for the tasks static and dynamic Web application

There are a total of 80 points to achieve. Based on the the answers given at the submission interview, points can be deducted from the points gained from the implementation. The submission interviews will be held on:

  1. 06.12.2017 and 07.12.2017 for the first submission.
  2. 10.01.2018 and 11.01.2018 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 is to implement a database based application, using different software architecture styles. The data for the application is taken from OpenStreetMap and should be filtered for stops of public transport in Graz, along with food sources like restaurants or cafes. The user should be able to add tracks to the database, e.g. for a new tram line. Additionally, restaurants and similiar establishments should be queryable through proximity to a selected stop.

The tasks are:

  1. Pipeline Architecture (Unix command line)
  2. GUI Application or Mobile App (standalone)
  3. Static Web Application
  4. Dynamic Web Application

The dataset: http://kti.tugraz.at/staff/rkern/courses/sa/data/austria-latest.osm.bz2
Taken from: http://download.geofabrik.de/europe.html

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

  • Download OpenStreetMap-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 stop-nodes (tram and bus), e.g. ./osmfilter austria-latest.osm --keep="railway=tram_stop" -o=tram_stop.osm. Play around with OpenStreetMap a bit to see what you have to filter for.
  • Filter for stops just within Graz. To do this, you can use this .poly file: (Graz.poly)
  • Use osmconvert for converting it to csv-data ./osmconvert all_stop.osm --all-to-nodes --csv="@id @lon @lat name" --csv-headline You have to save the at least the id, longitude, latitude and name of the entries, as you will need those in the next tasks (but you are free to use as many metadata as you wish).
  • Use standard linux-console-programs (awk, sed, grep, ....) in order to filter out stops that do not have a name (i.e. the name is empty), if there are any.
  • Load the content to a database which understands standard sql-queries (for example: mysql)
  • Use the same data-set as for the first pipeline. Write a Unix command pipeline (no bash-script, see later example) that solves following tasks:
  • Use osmfilter in order to keep the following types of restaurants (Tag: amenity):
    • bar
    • biergarten
    • cafe
    • fast-food
    • pub
    • restaurant
    Play around with OpenStreetMap a bit to see what you have to filter for.
  • Make sure that you also save the web address of the restaurant, if it has one.
  • Filter for restaurants just within Graz. To do this, you can use this .poly file: (Graz.poly)
  • Use osmconvert for converting it to csv-data. You have to save at least the id, longitude, latitude and name of the entries, as you will need those in the next tasks (but you are free to use as many metadata as you wish).
  • Use standard linux-console-programs (awk, sed, grep, ....) in order to filter out restaurants that do not have a name (i.e. the name is empty), if there are any.
  • Load the content to a database which understands standard sql-queries (for example: mysql)

The creation of the database and table(s) also needs to happen in one of the two pipelines. Furthermore, the pipelines must not fail if the database or the tables 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. You may specify the order in which your two pipelines need to be executed (i.e the one that is executed first creates the database). The decision about the behaviour concerning overwriting or appending of already existing entries is up to you. You may either overwrite or append.

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

Task 2 (GUI Application or Mobile App, architectural sketch): Write an application to interactively work with the data stored in the database from Task 1. The overall goal is a very simple route planer that can tell the user how to get from one stop to another. The restaurant data is not required for this task.

Before you start planning your application, take a look at the additional task: As part of Task 2 you have to create an architectural sketch depicting your planned architecture for Task 3 and 4. Planning Task 3 and 4 in advance gives you the opportunity to implement Task 2 in a way that allows you to reuse some components for the following tasks. As Task 4 requires MVC, don't just describe MVC but focus on more detailed aspects. Submit your sketch as a PDF-File with a maximum of 2 pages in A4 format, preferably containing diagrams and text.

List of required features:

  • Browse and filter stops by name, longitude and latitude (above/below lat°, above/below lon°). All three filters have to be combinable, but need to work independently as well.
  • Connection check between two stops:
    Given two stop names, check if there exists a line that directly connects these stops. If at least one such line exists, display all lines connecting the two stops directly (no change of lines).
  • Create new lines:
    Create a new line that connects 2 to n existing stops.

You can either create a standalone GUI (whatever system you like, must work on one of your computers) or a mobile app (IOS/Android/..., same here).

Supplemental Files: One CSV-File which contains all routes within Graz (routes.csv) and a many-to-many mapping file between the stops and the routes (mapping.csv).

While not required, we strongly urge you to implement the database layer as an independent service. As this task and the two following all use the same data-set and expose similar options to the user, a reusable database service will speed up your development and can get you some bonus points.

Task 3 (Simple Web Application): Write a simple web application, where the interface runs in the web browser. The user should be able to browse, query (but not edit) the data. The web browser communicates with a server component via HTTP requests. Changes in the database are not required to be immediately visible. Interaction with the site requires a full page reload at all times, ajax form submit or similar is not allowed.

List of required features:

  • Browse and filter stops by name, longitude and latitude (above/below lat°, above/below lon°). Any combination of filter criteria should be possible (total of five different filter criteria, e.g. bounding box).
  • Connection check between two stops:
    Given two stop names, check if there exists a line that directly connects these stops. If at least one such line exists, display all lines connecting the two stops directly (no change of lines).
  • Create new lines:
    Create a new line that connects 2 to n existing stops.
  • Restaurant finder:
    For a given stop, display all nearby restaurants for a given distance. To achieve this, use a bounding square with configurable size. Longitude and latitude might come in handy.
    For converting distance to lon°/lat°, have a look hereThe accepted answer offers sufficient precision.
  • Additionally you need to display the website address of the restaurant. Preferably show the user a hyperlink button, so that the user only needs to click on the link which takes him directly to the website.
  • Take care of non-functional requirements, quality attributes, e.g. usability: well structured GUI

Task 4 (Dynamic Web Application): Extend the web application using dynamic loading of parts of the web page and provide the functionality to edit the data. The user here should experience a high degree of usability. Get familiar with the advantages you will encounter when you add dynamic web mechanisms.

Supposedly, your application attracts a very large number of users, so you implement a queue system for database updates. Your queue has to be processed in certain intervals. Additionally, it should be processed once it exceeds a certain length (Choose parameters that make this come into play from time to time).

List of required features:

  • All features from Task 3
  • Edit stops (name, longitude, latitude)
  • Edit lines (name and contained stops)
  • Dynamic aspects (see below)
  • Database queue (in the database service, or as independent layer between application and database (recommended))
  • MVC architecture is required.

Dynamic aspects: choose any combination of features totalling at least 10 points:

  • Suggestions when entering a stop name in the filter field (4 points)
  • Live Search (automatically display filter results as you type, like Google Instant) (2 points)
  • Inline editing for the stops table (2 points)
  • Fancy drag'n'drop selection of stops for new lines (6 points)
  • Picklist for stops of lines when creating or editing lines(without reloading, of course) (4 points)
  • Google Maps/ Open Streetmaps plugin that marks your stops and restaurants on a map (max 8 points)
    • Mark all stops on map (2 points)
    • Mark all restaurants on map (2 points)
    • Display all stops of a line and visually connect them (2 points)
    • Change position of stops and or restaurants by dragging them on the map (4 points)
    • Highlight square and contained restaurants around a selected stop (4 points)
  • Dynamic filtering (show filter results without reload) (2 points)
  • Sortable tables (without reload) (2 points)
  • WebSocket/Polling support (propagate all changes in the database to other users without them having to reload their page) (WS: 10 points, Long Polling: 8 points, Polling: 6 points)
  • Your own awesome ideas. Contact us and we will tell you if they are okay and how many points you will get. (* points)