Provided proper ALT caption for all images.

chapters/angulardart/index.md

@@ -9,7 +9,7 @@ chapter: true
 *Delft University of Technology*
 
 
-![](images/angulardart_logo.png "AngularDart")
+![Angular Dart Logo](images/angulardart_logo.png "AngularDart")
 <!-- -->
 
 **Abstract**
@@ -174,7 +174,7 @@ His blog is a good addition on the explanation above and focuses on creating mod
 The overall tendency is that the main modules in `/lib` are loosely decoupled, with only the Core module binding all the modules together.
 In the image below, the different modules and the dependencies between them are illustrated by a network analysis graph: Larger modules have more imcoming dependencies whilst small modules rely on such dependencies.
 
-![](images/module _graph_analysis.png)
+![Module dependency graph analysis of /lib](images/module _graph_analysis.png)
 _Module dependency graph analysis of /lib_
 
 AngularDart is written with a Dependency Injection (DI) framework, used for the decoupling of classes, allowing for re-usability. 
@@ -254,7 +254,7 @@ Connectors are the pieces of code of the architecture that link the elements, or
 #### External entities
 AngularDart has "other systems, software programs, hardware devices or other entities with which the system interacts" (Rozanski and Woods, p. 272), or external entities. These can be extracted from the Context view image below.
 
-![](images/Context_view_with_logos.png)
+![PIETJE PUK](images/Context_view_with_logos.png)
 _Context view with logos_
 
 * HTML: AngularDart extends the HTML with several directives, as discussed earlier, such as "ng-class". By using this directive, AngularDart attaches to that DOM element a specified behavior, or it can transform that DOM element (and its children).
@@ -279,12 +279,12 @@ Version 2 will also add support for Web Components, which are a collection of fo
 
 Angular 2.0 will be built using TypeScript from Microsoft. However, because no browser supports TypeScript natively yet, it will be transpiled (a source-to-source compiler, that *trans*lates code to another programming language) to EcmaScript 5. TypeScript differs from EcmaScript 5 by the addition of types to the language (type annotations, compile-time type checking and type inference). This also counts for classes, interfaces, modules and more. TypeScript is a superset of EcmaScript 5, which means that any current JavaScript program is a valid TypeScript program. However, Angular 2.0 does not offer any backwards compatibility to version 1.
 
-![](images/angular2_transpile_architecture.png)
+![Angular 2 Transpile Architecture](images/angular2_transpile_architecture.png)
 _Angular 2 Transpile Architecture_
 
 In the image above you can see the way the Angular 2 is built. Since the development started on version 2 of Angular, both teams of the JavaScript and Dart version are combined into one team. Version 2 uses the facada pattern, which uses abstracted functions to improve readability of the library and the make a coherent API that is easy to use. Also, the most important reason that these facades are necessary is for the differences between JavaScript and Dart APIs. The transpiler uses these facades to compile the correct API for both languages. Traceur is the component responsible for tranpsiling the code to EcmaScript 5 and Dart. 
 
-![](images/angular2_team.png)
+![The team of Angular 2](images/angular2_team.png)
 _The team of Angular 2_
 
 This compiler actually adds an extra option to develop Angular apps. Besides EcmaScript 5, EcmaScript 6, TypeScript and Dart, it is also possible to write Angular apps using the Traceur compiler in EcmaScript 6 and having it transpile to any number of the just mentioned languages. 
@@ -442,7 +442,7 @@ An application called `cloc` is used to count the number of lines of code and th
 
 <br />
 
-![](images/ratio_loc_comments.png)
+![Ratio Comment / LOC](images/ratio_loc_comments.png)
 _Ratio Comment / LOC_
 
 **Total volume of documentation (word count)**
@@ -479,7 +479,7 @@ Finally, general checking metrics are needed to define whether the goal, namely
 
 This metric is performed and obtained from GitHub, with the results depicted in the following graph:
 
-![](images/number_of_contributors.png)
+![Number of contributors](images/number_of_contributors.png)
 _Number of contributors_
 
 The number of contributors reached a peak in November 2014, and has steadily declined. This might be just because of start of the AngularJs 2.0, the new framework.

chapters/diaspora/index.md

@@ -7,7 +7,7 @@ chapter: true
 
 # Diaspora
 
-![](images/Diaspora.png)
+![Diaspora Logo](images/Diaspora.png)
 <!-- -->
 
 **Simon Bijl, Tejaswini Dandi, Selman Ercan, Revathi MC**<br/>
@@ -49,7 +49,7 @@ In this chapter, we discuss the context, architecture and development of the Dia
 
 In 2010 the project was funded as a Kickstarter project, collecting over $200,000. Since 2012 the project is fully based on volunteer work. The image below gives a rough timeline of the project.
 
-![](images/History.PNG)
+![_Figure 1: Project History of Diaspora_](images/History.PNG)
 _Figure 1: Project History of Diaspora_
 
 
@@ -61,7 +61,7 @@ In this section, the organisation and analysis of major stakeholders involved in
 
 Some of the stakeholder categories identified in Rozanski and Woods are included in this section. As the project currently involves less contributors, few of the stakeholders have multiple roles in the project. 
 
-![](images/Stakeholder.png)
+![_Figure 2: Stakeholder Analysis of Diaspora_](images/Stakeholder.png)
 _Figure 2: Stakeholder Analysis of Diaspora_
 
 The Diaspora Foundation, which is part of the Free Software Support Network (FSSN), manages the Diaspora software development. Eben Moglen and the Software Freedom Law Center in turn run the FSSN. The FSSN provides resources to Diaspora development and manages Diaspora's branding, trademark, copyrights, finances and legal assets. Administrators who maintain the system once it has been deployed are called *podmins*, and the system administrators. Users of the network of nodes, mainly different individuals and organisations, can host a pod on their own server. 
@@ -73,7 +73,7 @@ The most active developer is [Mr. Jonne Haß](https://github.com/jhass) with 187
 
 The process of software architecture involves the concerns of both the internal and the external environment. In addition to the internal stakeholders, it is essential to give a definition of the environment of the system in terms of its relationships and dependencies. This need can be met by creating a context view as part of the architectural description. The figure below gives an overview of Diaspora's interactions with external entities. 
 
-![](images/Context view.png)
+![_Figure 3: Context view diagram of Diaspora_](images/Context view.png)
 _Figure 3: Context view diagram of Diaspora_
 
 As seen from the figure, the most essential external dependencies of Diaspora can be categorised into three types: background processing, development environment and decision making tools. As Diaspora relies on a lot of network communication with other servers, background processing jobs are considered essential. This is mainly taken care of by [Redis](http://redis.io/) and [Sidekiq](http://sidekiq.org/). The development environment mainly consists of [GitHub](https://github.com/Diaspora/Diaspora) and [testing](https://wiki.diasporafoundation.org/Testing_workflow) frameworks. The process followed in the development environment is mainly discussed and decided in the central platform [Loomio](https://www.loomio.org/g/EseV9p4X/Diaspora-community), which acts a voting tool.
@@ -112,7 +112,7 @@ Mandatory features are present in all products.
 Optional ones may or may not be selected.
 Among alternative features only one can be selected, while in OR-features it is possible to select one or more. Below is the feature model diagram of Diaspora.
 
-![](images/feature-model.png)
+![_Figure 4: Diaspora Feature Model_](images/feature-model.png)
 _Figure 4: Diaspora Feature Model_
 
 Most of the included features are mandatory. The OS support for development is an OR-feature; different operating systems are supported and it is possible to develop using more than one at the same time. The data storage feature is an alternative feature; various DBMSs are supported, but only one can be used at the same time. The chatting feature is optional.
@@ -121,7 +121,7 @@ Most of the included features are mandatory. The OS support for development is a
 
 In order to represent a complex system in a way that is manageable and comprehensible by a range of business and technical stakeholders, the only successful way is to attack the problem from different directions simultaneously. In this approach, the architecture definition is partitioned into a number of separate but interrelated views and perspectives, each of which describes a separate aspect of the architecture. Collectively these views describe the whole system. 
 
-![](images/Viewpoint.png)
+![_Figure 5: Viewpoint Catalog_](images/Viewpoint.png)
 _Figure 5: Viewpoint Catalog_
 
 As shown in figure 3, we made use of some of the viewpoints and perspectives defined in Rozanski and Woods in analysing the architecture of Diaspora. In this section we will analyse the Diaspora project using two viewpoints (_Development_ and _Deployment_) and one perspective (_Internationalisation_).
@@ -138,12 +138,12 @@ In general, Model (M) is the central component of the MVC Architecture. Models a
 
 The operation of this architecture is illustrated in the following figure.
 
-![](images/MVC.png)
+![_Figure 6: MVC Architecture_](images/MVC.png)
 _Figure 6: MVC Architecture_
 
 As explained earlier, Diaspora's architecture consists of modules organised as models, controllers and views. The following figure shows which modules belongs to which part of the MVC architecture.
 
-![](images/Module.png)
+![_Figure 7: Modular organisation_](images/Module.png)
 _Figure 7: Modular organisation_
 
 Redis, resque, mysql2, activerecord are the databases where Diaspora stores data and acts as models for the system. Diaspora uses [Sinatra](http://www.sinatrarb.com/) libraries for creating web applications in Ruby.
@@ -155,7 +155,7 @@ Diaspora uses JSXC in the front end of Diaspora's built-in chat feature. Diaspor
 ##### Source Code Structure
 Diaspora is a Ruby on Rails application and the module organisation conforms to the Ruby on Rails project structure described in [application structure](http://en.wikibooks.org/wiki/Ruby_on_Rails/Getting_Started/Creating_the_application#The_Application_Structure). The project documentation is provided through [wiki](https://wiki.Diasporafoundation.org/Main_Page) where every single feature is precisely explained using workflows. The documentation on recent changes in the system is provided through the `Changelog.md` file. The Diaspora application structure is shown in the figure below. 
 
-![](images/diaspora-codeline.png)
+![_Figure 8: The application structure of Diaspora_](images/diaspora-codeline.png)
 _Figure 8: The application structure of Diaspora_
 
 
@@ -222,7 +222,7 @@ This is an important model for the deployment viewpoint. This model defines:
 
 The Runtime platform Model of Diaspora is shown below:
 
-![](images/Deployment Diagram.png)
+![_Figure 9: Runtime platform Model_](images/Deployment Diagram.png)
 _Figure 9: Runtime platform Model_
 
 For every pod system few hardware requirements need to be satisfied like size of the RAM, disk space needed type of CPU recommended etc. And the software elements necessary for the pod are database technology, protocols that are needed to use for file transfer, or for security between the layers etc. The Diaspora social network is constructed of a network of pods(nodes), which are hosted by many different individuals and institutions. Each pod is operated with a copy of the Diaspora software which acts as a personal web server.
@@ -257,12 +257,12 @@ By default rails-i18n loads all locale files, pluralisation and transliteration
 
 #### Major touch points 
 
-![](images/Touch points.png)
+![_Figure 10: Major Touch points of Diaspora around the globe_](images/Touch points.png)
 _Figure 10: Major Touch points of Diaspora around the globe_
 
 This concern focuses on identifying all the major touch points (where a person interacts with the system), its scope of services and information that need to be internationalised in each of these touch points and system's region of concerns. The regions plotted in the diagram show the major touch points of the Diaspora system. The data is retrieved by taking the regions of active pod administrators, regions which have their languages translated at higher rate and regions which has its recent updates on languages. 
 
-![](images/I18n.png)
+![_Figure 11: Scope of internationalisation of Diaspora_](images/I18n.png)
 _Figure 11: Scope of internationalisation of Diaspora_
 
 The chart is plotted by taking the values on percentage of translated data and proofread data in the Diaspora system. The chart shows clearly the proportion of translated data and proofread data in different languages in the Diaspora system. It can be seen that, though some of the languages has been translated to its maximum extent, there still remains some maintainability concerns in proofreading the translated data and finalising the changes needed to the system.
@@ -286,7 +286,7 @@ In this section we evaluate the maintainability of the Diaspora project. We defi
 
 The quality profile below is plotted by evaluating the cyclomatic complexity in the Diaspora codebase, through analysing every single line of code by the risk category instead of summation or average median method. Code complexity is analysed using Saikuro, which is a Ruby cyclomatic complexity analyser. When given Ruby source code Saikuro will generate a report listing the cyclomatic complexity of each method found. Some of the Classes/Modules which is under High risk category include `AspectsController`, `ConversationsController`, `PhotosController`, `StatusMessagesController`, `UsersController` and `PeopleController`. Duplication of code attributing to high risk category can be seen in the modules `PeopleController`, `StatusMessagesController`.
 
-![](images/Complexity.png)
+![_Figure 12: Quality profile of cyclomatic complexity_](images/Complexity.png)
 _Figure 12: Quality profile of cyclomatic complexity_
 
 |**Cyclomatic Complexity**|**Risk Category**|**Percentage of code**|
@@ -302,7 +302,7 @@ _Figure 12: Quality profile of cyclomatic complexity_
 
 Below is a diagram generated by the CodeClimate plugin running on the Diaspora codebase. It shows the change in the number of classes per risk category over a period of four months, prior to the last release;`Diaspora 0.4.1.2`on October 30th, 2014.
 
-![](images/code-climate-trends.png)
+![_Figure 13: CodeClimate Maintainability trends_](images/code-climate-trends.png)
 _Figure 13: CodeClimate Maintainability trends_
 
 The first thing to note is that only the dark green area is increasing in height, meaning that most of the newly created classes and modules are in the _very low risk_ category.

chapters/docker/index.md

@@ -61,10 +61,10 @@ Normally this is done by using virtual machines, but this results in a large ove
 Docker makes it possible to create isolated environments without this overhead by running the processes in the kernel of the host OS, which eliminates the need for a guest OS.
 The figures below illustrate the difference between using a virtual machine on the one hand and using Docker on the other.
 
-![](images/variability_vm.png)
+![_Traditional Approach to Virtual Environments_](images/variability_vm.png)
 <br/>_Traditional Approach to Virtual Environments_
 
-![](images/variability_docker.png)
+![_Docker's Approach to Virtual Environments_](images/variability_docker.png)
 <br/>_Docker's Approach to Virtual Environments_
 
 To run such a container, an image is needed.
@@ -80,7 +80,7 @@ To take a closer look at the structure of the Docker project, we first identify
 The relation between those elements is depicted in Figure [_Component diagram of Docker_](#component-diagram). The subsequent table provides a small description of each element's responsibility.
 
 <div id="component-diagram"/>
-![](images/component_diagram.png)
+![_Component diagram of Docker_](images/component_diagram.png)
 _Component diagram of Docker_
 
 Element   | Responsibility
@@ -101,7 +101,7 @@ However, by using their own interface they are able to drastically reduce the nu
 The libcontainer project attracted a number of companies to support Docker, such as Microsoft, Google, IBM, Red Hat, and Canonical [[ref]](http://www.zdnet.com/article/docker-libcontainer-unifies-linux-container-powers/).
 
 <div id="virtualization-abstraction"/>
-![](images/docker-linux-interfaces.png)
+![_Virtualization abstraction_](images/docker-linux-interfaces.png)
 _Virtualization abstraction_
 
 ## Usage Principles
@@ -118,7 +118,7 @@ For example, when you have only changed the source code of your application, onl
 Intermediate layers are cached by Docker, so only the changed layer and all layers on top of that need to be rebuilt.
 
 <div id="layered-structure"/>
-![](images/docker-filesystems-multilayer.png)
+![_Layered structure of an image_](images/docker-filesystems-multilayer.png)
 _Layered structure of an image_
 
 
@@ -160,7 +160,7 @@ Maintainers are the only persons allowed to merge pull requests and can be found
 Another big group of stakeholders are the suppliers. Companies offering Docker based services have a big interest in its development. Examples of suppliers are companies that offer Infrastructure as a Service with built-in support for Docker, such as [DigitalOcean](https://www.digitalocean.com/features/one-click-apps/docker/) and [GiantSwarm](https://giantswarm.io), but also [Docker Hub](https://hub.docker.com/), offering tools for building and sharing containers.
 
 <div id="docker-pi"/>
-![](images/P_I_curve.png)
+![_The Power/Interest curve for Docker_](images/P_I_curve.png)
 _The Power/Interest curve for Docker_
 
 The [Figure above](#docker-pi) provides an overview of the power versus interest curve, which represents how much power and interest a given stakeholder has in the system.
@@ -183,7 +183,7 @@ as shown in the figure displaying the [Modular Structure of Docker](#docker-modu
 Most of the modules that had their functionality described in Figure [_Component diagram of Docker_](#component-diagram) reside in the core layer of Docker.
 
 <div id="docker-modular-view"/>
-![](images/development-view.png)
+![_Modular Structure of Docker_](images/development-view.png)
 _Modular Structure of Docker_
 
 
@@ -203,7 +203,7 @@ Finally, Docker uses both integration tests and unit tests, as indicated by the
 This layer is represented by a vertical box, because testing occurs in all layers of the system.
 
 <div id="docker-dependencies"/>
-![](images/docker_deps.png)
+![_Module Dependencies_](images/docker_deps.png)
 _Module Dependencies_
 
 Finally, the [Figure above](#docker-dependencies) shows an overview of the dependencies between the most important modules. This graph was generated by statically analyzing the source code. The colors correspond to the colors in the Figure describing the [Modular Structure of Docker](#docker-modular-view): pink nodes are core modules, yellow nodes are domain models and purple nodes are utilities.