WebHome
- Education Page
- Manual
- Schedule
- Organisation
- Projects
- Literature
- Other Material
- Submitted Material
- News
Center
Master Program
Course Manual 20082009

Swa
%TOC%

---++ Goal of this course

---+++ High level goals

The goal of this course is to teach the students the following, either explicitly or implicitly:

   * Academic skills: writing, evaluation, comparing alternative solutions, reflection on solutions and own behavior, teamwork, judging work done by others.

   * Course specific skills: modeling, describing an architecture by means of written documents, making a planning, detecting and handling contradictory demands (of stakeholders).

   * Concrete acquired knowledge: standard architectures, quality models (ISO 9126/QUINT), enterpise application architecture patterns, architecture description languages and models (IEEEP1471, UML, and others), assessing an architecture.

#ConcreteCriteria
---+++ Concrete criteria

More specifically, the required/trained/judged skills for this course are the following:

   * *Being able to see what information is missing* : You have to be able to point out where you had to make an assumption for the design of an architecture for the case study. Wherever the description of the case study does not offer enough starting points you have to make an assumption about the requirements or facts.
   
   * *Being able to differentiate between problem and solution* : You have to be able to describe the problem (case study, assumptions, analysis) without describing the solution.
   
   * *Modeling* : You have to be able to construct models for the various viewpoints. You must then show the coherence between these viewpoints and show the consistency between models.
   
   * *Documenting* : The description of the architecture contains viewpoints specifically targeted to stakeholders. You have to be able to prove how a viewpoint satisfies the wishes and necessities of a stakeholder. 
   
   * *Use of architecture patterns* : For each architecture pattern you did use, you have to show what considerations let to the use of the pattern, which alternatives were considered, and whey these alternatives were not chosen.
   

---++ Structure of this course

The exact timing and schedule can be found at the overview of the logistics. Here, the overall structure and intentions of the course are explained.

A consultant is supposed to advise a client on the architecture of a to be developed system. In the description of such an architecture not only should be incorporated what this system should do, but also how the system is structured in order to comply to the wishes and demands of the client. In order to be able to validate the feasability of the proposed system and to validate the wishes of the client you have to delve into the technical aspects of the future system without getting lost in the technicalities and thereby losing the overview.

Lectures form an important part of the course. However, even more important is your own insight, creativity, your way of gathering information and shaping an architecture. A description of the [[CourseAssignments][case study]] is available as a starting point for information gathering. Later on some modifications and/or additions to the case study can be expected. With respect to this aspect the course Software Architecture resembles Software Project. This course focuses more on the architecture and consultancy (i.e. giving the advice), whereas Software Project the experience of making something as a group, for a client, is more important.

A good architecture is characterised by easy adaptability when the requirements are changed. For this reason part of the peer review consists of impact analysis, that is, analysing the impact of a change request.

---++ The role of the customer

A client determines what is important for his/her company. However, a client often is a company where several stakeholders are employed. These stakeholders determine which requirements are important, but these stakeholders also have their own vision of what the requirements should be. For example, a technical specialist and someone from the marketing department may have a different look upon hardware requirements. It is your job to bring order in this potential chaos of conflicting demands and wishes.

---++ What has to be done

During the course you will work together, as part of a team. You will gather requirements for the client, construct an architecture document which also includes an implementation proposal and its feasibility. More concretely, this means you will write an "architecture document". This document contains a description of the proposed system. You will also present your solution to the client and colleague teams. Finally, you will assess the architecture document of a colleague team and present your findings (of its feasibility) to the client and the colleague team.

---+++ How cooperation will take place

A team has 5 members, from which only will be deviated if it cannot be avoided. It is the responsibility of the team as a whole to point out which part of the architecture document has been produced by who. This information will be used for individual judgement (more on judgement later on). However, the focus of this course is not on the cooperation (as was the case with Software Project), but on the result of this cooperation (architecture document, presentation, review).

---++ Deliverables

There is a multiple choice test on the content of the lectures in week 50. The results of this test will contribute for 1/3 to the final grade, the project will contribute for 2/3.

---+++ Multiple choice test

The test will last for 2 hours and consists of questions with 5 alternatives each. The material to be studied for this test is the material that has been presented in the lectures, as demonstrated by the transparencies on the lectures page. The material in the book has to be studied only to the extent it is covered in the lectures: the book's other, and main, role is as a reference source for your own architecture designs.

---+++ Stakeholder + quality document (part of Architecture document)

   * *Size*: as much as necessary
   * *Submission format*: see architecture document
   * *Content*: this document will be part of the architecture document. The intention of the stakeholder + quality document is to better (1) know what the system must do, therefore (2) be more able in writing a rationale and proof that it will work, and (3) give reviewers a better starting point for reviewing and knowing what you did intend.
      * A description of the stakeholders, quality requirements, prioritization of quality requirements, and possible tradeoffs to be made (as far as possible in this stage of development of the architecture).

---+++ Architecture document

   * *Size*: 8-10 pages x teamsize.
   * *Submission format*: the document must be submitted in PDF format. Other formats are not accepted. Documents are submitted via email to the teacher.
   * *Content*:
      * A description of the architecture, structured according to the IEEEP1471 framework. In this framework the interests of stakeholders are explicitly described by means of viewpoints/views. For the case study of this course at least the viewpoints from the "4+1" model have to be used, with UML as the language for expressing the models.
         * logical view. Use (e.g.) class + sequence diagrams.
         * process view. Use (e.g.) component + sequence + state diagrams.
         * physical view. Use (e.g.) deployment diagrams.
         * development view. Use (e.g.) component diagrams.
         * 'scenario view': illustrate the concepts in the other views by discussing a scenario (i.e. 1 particular use case walkthrough) and how it relates to these other views. This is a (informal and/or argumented) proof (or rationale) that the chosen architecture will be able to realise the use cases (this is the +1 from the previous 4+1).
      * Besides the previous "standard" viewpoints at least 1 other viewpoint has to be defined and a view corresponding to the viewpoint must be written. The viewpoint should correspond to a particular interest of a stakeholder and as such be an answer to a specific concern of this stakeholder. You can freely choose here, for example you can consider the cost or security of the system. This must be discussed in the viewpoint rationale and/or incorporated in the design of the architecture.
      * A (informal and/or argumented) proof (or rationale) that the chosen architecture indeed can be implemented. Here the connection is made with technology, that is, existing software/systems, previous implementations and experience, etc. in the form of literature study, usage of systems, prototyping, etc. Because alternatives exist, show which alternatives have which effect on the quality aspects (e.g. by using an impact matrix), which alternative is the 'best' and how this can be validated and measured. This is the place where the confrontation between a client's wish and technological feasibility takes place.
      * A proposition for the realisation of the system, which includes expected costs, planning and estimated required resources (personel, equipment, ...).


The contribution of each team member (that is, which part or which role (editor)) should be clearly visible and identifiable, as stated in the task allocation document.

---+++ Architecture presentation to client and colleague teams

Form: presentation, approx. 20 mins.

Content: a verbal explanation to the client of how the client's interests will be satisfied. In other words, convince the client that your solution will solve his/her problems.

---+++ Peer review

Form: presentation, approx. 20 mins.

Content: an assessment of an architecture (from a colleague team) w.r.t. to its understandability, feasibility. You will do the same as we (i.e. teaching staff) will do, namely judge an architecture document on:

   * is it written understandable? Does it explain that what is not yet known to the reader? Is it consistent (internally and/or with external facts)? Does written text and pictures give information, or is it part of an argumentation (or just contains nonsense)?

   * is the system described by the architecture going to work, or more general, are the quality aspects as described and chosen by the team satisfied as argumented by the architecture document? Are you convinced of this (if not, the client certainly will also not believe it)?

   * to check if it is going to work perform
      * impact analysis. That is, modify the requirements, e.g. by adding a new use case, and find out how much the architecture has to be adapted. Less necessary changes in general means a better architecture design.
      * risk analysis. That is, find out which parts are a risk, that is, there is something unpredictable about it. For example, the cost of it.







---++ Judgement

In judging the project part (2/3 of the final grade), the architecture document will weigh the most. *The architecture document must be judged with a passing grade. If this is not the case it is not possible to get a passing grade for the course.*

The judgement will first of all be for the team as a whole. This implies that individual contributions (or lack of it) have an effect on the judgement of the complete team's mark. Individual corrections and tuning will be based on the work partitioning explicitly declared in the architecture document.

On top of the [[#ConcreteCriteria][mentioned concrete criteria]] some additional criteria will be used:

   * argumentation of a choice is more important than the specific choice itself. Valid arguments should be used.

   * in reality, the amount of paper required to fully describe the architecture would exceed the specified limits for this course. Therefore, it is more important that all aspects of the problem are worked out in approximately the same level of detail. For example, if by giving detail on a specific technicality the connection between remaining parts of an architecture document is lost, this will have a negative influence on the judgement. In other words: breadth first instead of depth first explanation/expansion.

   * all aspects of the case study must be discussed in (e.g.) the architecture document, either in the form of the extremes "how to ..." or "cannot be done, because ..." or something in between.

Furthermore, *presence at lectures and presentations is obligatory*.