: Software architecture project: work topics and instructions

General

Agree on the topic with the person in charge before you start working on it. In addition to the topics below (1-3), you can suggest your own topic (see Topic 4).

During the project, you should produce a report of 10-15 pages. It is preferred that you hand in your report as a pdf, but you can also write it in Open Office or MS Word, which are available on department computers. You can send in program code in a separate package (zip) or print them out as an attachment to the report. There are no detailed requirements for the layout of the report, but it must have headings and be organised into chapters and sub-chapters. All the sections mentioned in the topic sentences must be easy to find in the report. If you wish, you can use document templates from e.g. the BSc thesis course (however, you do not need to write a summary). The sources you have used for the work must be evident in the report, and they must be referenced in the text. The language and presentation should be normal, i.e. a clear and easy-to-read exposition. UML is recommended for the architecture diagrams, but you can also use free-form drawings, as long as the meaning of any symbols used are explained.

Do not forget to write your name and student number on the cover page of the report. Naturally, plagiarism (including re-using your own seminar presentations or other similar work) is forbidden.

 

Topic 2015/1: <Some> web application framework

To do <some> web application framework. An application framework can be a server-side framework that supports the implementation of the web application, or a client-side framework (such as a JavaScript framework to implement a client connection in a browser). The work should describe the style or ideas for the architecture, on which the framework solution is based, it should document the basic structure and function of the framework, it should describe the specialisation principle and variation points, as well as analyse the strengths and weaknesses of the applications produced with the framework.

The work should produce a document consisting of three sections. The first section describes the basic ideas of the architecture styles in the framework, including the features specified for the application components derived from the style framework.

The second section documents the general architecture of the framework and its main variation points. The goal is to give an overview of the framework structure and how the framework is specialised according to application. You can use an application from one of your sources, or your own sample, for support. For description methods, you may choose e.g. a class diagram to explain the structure and sequence diagrams to describe the main events of the operations. Use e.g. stereotypes in the diagrams to show which parts of the architecture belong to the framework and which parts relate to the application. The configuration files often hold a significant role in the structure of web application frameworks, so you should pay attention to them in this description. The application frameworks are based on some architecture style and usually implement many design models on the software level. You should note the design models that are central to understanding the structure.

The description should remain on the architecture level and avoid too much detail. As far as the framework goes, you should only describe the classes that are interesting to the creator of the application, and one or two from each category of example application classes or sub-classes. To understand the operations, it is enough to describe 1-2 cases that bring forth the functional principles. For the web application, the main points are e.g. how the user reacts to input, managing the status and control of the application, producing the pages shown to users, and the connection to data contents.

In the third section, evaluate the framework and the architecture implemented with it. The evaluation should highlight advantages and disadvantages (e.g. from the source literature). In addition to the general evaluation, write a small number of (quality) scenarios to test some quality feature – both expected ones and ones that define the limits of the system (see the lecture material on evaluation of architectures and ATAM). The quality feature that is tested could be availability and trustworthiness, or variability and re-usability. Describe the goals in the scenarios briefly in words. Give a rough estimate of necessary competence and workload on the scale L(ow) / M(edium) / H(igh) (see ATAM).

<Some> can be one of the following:

 

Topic 2015/2: an application framework that supports crossword and grid games

The assignment is to design a Java application framework for the implementation of crosswords and grid games. In addition, analyse the expected re-usability of the framework.

The framework is supposed to make it easier to create game applications that are based on filling out grids with letters or numbers. Some examples of such games are sudoku (see http://www.websudoku.com), crosswords (see http://www.crossword-puzzles.co.uk) and calculations (see http://www.edhelper.com/puzzles.htm). What these games have in common is a game area consisting of rows and columns forming squares that may contain either hints for solving the game (numbers, letters, words or pictures), or the squares may be empty for the input of the user. The user fills in the input squares in the grid one at a time, and the game program checks that each input follows the rules of the game. When all the squares have been filled according to the rules, the game (or assignment) is done. For a correct solution, a result based on the rules of the game is calculated; it can be e.g. a number of points according to the time spent on playing the game and the corrections made to the input during the game. The games should be implemented as Java applications in a J2SE environment.

The following features and services are required of the framework:

In the first stage of the work, the assignment is to design a Java API consisting of classes and interfaces, including their public features (methods and data fields), for the framework. Describe the API with the help of a class diagram and related textual description. In addition to describing the program structure, outline how it works. Further, describe the variation points of the framework, and how it is supposed to be specialised (especially how to deal with the start of the game and correct solutions, how the input control and counting of points for each game is to be defined, ...). Explain all the classes and interfaces, applied design models, and architecture styles of the framework. To your framework documentation, add a short description of how a simple game of sudoku can be derived from the framework. Use a couple of core scenarios to explain how it works, such as cases (a) the user enters an incorrect input in a square and when (b) the user finishes the task and the game application checks the solution and calculates the correct number of points.

In the second section, you are asked to evaluate the framework of the architecture.  Focus on variability and re-usability in your analysis. Study the following scenarios:

  1.     A simple crossword puzzle is implemented with the framework.
  2.     Using the framework to implement a version of Sudoku, where you can specify the interface and graphic layout for each game separately.
  3.     Using the framework to implement a version of Sudoku, where you can save the current number of points at any stage of the game, and continue from that stage later.
  4.     We want to use the framework to produce game situations or applications that generate problems (e.g. applications for creating Sudoku or crosswords).

Analyse each scenario in words and evaluate the level of difficulty of the implementation roughly as in ATAM, i.e. give a rough estimate of necessary competence and workload on the scale L(ow) / M(edium) / (H(igh).

 

Topic 2015/3: software framework for graphics editors

The object of this work is some software framework (e.g. GEF for Eclipse). The work should describe the style of the architecture, on which the framework solution is based, it should document the basic structure and function of the framework, it should describe the specialisation principle and variation points, as well as analyse the strengths and weaknesses of the applications produced with the framework.

The work should produce a document consisting of three sections. The first section describes the basic ideas of the architecture styles in the framework, including the features specified for the application components derived from the style framework.

The second section documents the general architecture of the framework and its main variation points. The goal is to give an overview of the framework structure and how the framework is specialised according to application. You can use an application from one of your sources for support. For description methods, you may choose e.g. a class diagram to explain the structure and sequence diagrams to describe the main events of the operations.

Use e.g. stereotypes in the diagrams to show which parts of the architecture belong to the framework and which parts relate to the application. The application frameworks are based on some architecture style and usually implement many design models on the software level. You should note the design models that are central to understanding the structure. The description should remain on the architecture level and avoid too much detail. As far as the framework goes, you should only describe the classes that are interesting to the creator of the application, and one or two from each category of example application classes or sub-classes. To understand the operations, it is enough to describe 1-2 cases that bring forth the functional principles.

In the third section, evaluate the framework and the architecture implemented with it. The evaluation should highlight good and bad aspects. In addition to the general evaluation, write a small number of (quality) scenarios to test some quality feature – both expected ones and ones that define the limits of the system (see the lecture material on evaluation of architectures and ATAM). The quality feature that is tested could be availability and trustworthiness, or variability and re-usability. Describe the goals in the scenarios briefly in words. Give a rough estimate of necessary competence and workload on the scale L(ow) / M(edium) / H(igh) (see ATAM).

 

Topic 2015/4: <your own topic>

Your topic could be, for example, a description of some part of the architecture of a framework or platform that you are interested in. It is best to limit your topic so that it can be sensibly discussed in a 10-15-page report. The topic must be discussed from an architectural viewpoint, i.e. identify the architecture styles and patterns, specialising points and principles (in the framework), and evaluate the architecture solutions with the help of quality scenarios. You can use the structure of Topic 1 as a basis for this report.

You can also do an assignment where some other theme from the course is applied and deepened, such as architecture modelling. You could analyse and explain, with the help of examples, how you would apply one of the canonical models of software architecture that we studied during the course to the architecture of an existing software.

You can also write an experience-based report on the role/significance/achievements/difficulties of architecture work on the basis of your work experience. In the latter case, it is vital to reflect the things we discussed during the course onto your practical experiences and critically evaluate the significance of architecture development. You can also pick out some more detailed topics from the course, which you can discuss by way of concrete examples. Please note, though, that you may not discuss e.g. things that your employer has labelled as confidential without permission from your employer (these project reports are not published, but the person in charge of the course will not be signing any non-disclosure agreements [NDA]).

You must agree on your own topic with the person in charge of the course before starting your work. Please send a description of your topic and a preliminary disposition of the final report by email to the person in charge of the course to reach an agreement.