Ci-dessous, les différences entre deux révisions de la page.
tm:chapter4 [d-m-Y H:i] boris créée |
tm:chapter4 [d-m-Y H:i] (Version actuelle) boris |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | [[tm: | ||
+ | |||
====== Chapter 4 The Technology Behind ====== | ====== Chapter 4 The Technology Behind ====== | ||
Ligne 11: | Ligne 13: | ||
* Provide extension to further analyze a business model by comparing it to other models, applying patterns or evaluate it with a survey. | * Provide extension to further analyze a business model by comparing it to other models, applying patterns or evaluate it with a survey. | ||
- | > {{main026.gif}} | + | Figure 4.1: Overview of both prototype’s architecture |
+ | |||
+ | {{ tm: | ||
===== 4.1 Prototype 1 ===== | ===== 4.1 Prototype 1 ===== | ||
Ligne 19: | Ligne 23: | ||
The data structure has been created in [[http:// | The data structure has been created in [[http:// | ||
- | The data structure can be seen in figure | + | The data structure can be seen in figure 4.2. Product is the first name given to the layer feature before it was identified as such. Also in this version of the prototype there is a table for the building block, this allows for renaming of the blocks and provides the possibility to add new blocks for further evolutions of the model. This possibility has been replaced in the second prototype by the fact that a block is defined as an aggregation of sub classes of elements. |
- | > {{main027.gif}} | + | Figure 4.2: Prototype 1 database schema |
+ | |||
+ | {{ tm: | ||
==== 4.1.2 Comments ==== | ==== 4.1.2 Comments ==== | ||
Ligne 65: | Ligne 71: | ||
Table [[# | Table [[# | ||
- | > **Simple Profile** tableheader**Sharing** **Collaboration** tableheader Stateless Stateful tableheader User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs No sharing (only uncontrolled through using same account twice) User can share his BM with other users User can share his BM with other users User can share his BM with other users Two users editing the same document will result in unknown behavior Two users editing the same document is impossible due to a lock system Edits on a BM will be sent to all other views connecting to the same BM **Like:** Desktop application profile, computer login **Like:** - **Like:** wiki, file access **Like:** google docs, chat **Impact:** a BM belongs to a user **Impact:** a BM has many users **Impact:** a BM has many users, a user can get a lock on a BM for editing **Impact:** a BM has many users, publish/ | ||
- | > **Options** ACL user and BM relation | + | | Table 4.1: Comparison of user management systems |
+ | ^ **Simple Profile** ^ **Sharing** ^^ **Collaboration** ^ | ||
+ | ^ ^Stateless ^Stateful ^ ^ | ||
+ | |User logs in to access his BMs |User logs in to access his BMs |User logs in to access his BMs |User logs in to access his BMs | | ||
+ | |No sharing (only uncontrolled through using same account twice) |User can share his BM with other users |User can share his BM with other users |User can share his BM with other users | | ||
+ | | |Two users editing | ||
+ | |**Like:** Desktop application profile, computer login |**Like:** - |**Like:** wiki, file access |**Like:** google docs, chat | | ||
+ | |**Impact: | ||
+ | |**Use case:** used like an application, | ||
+ | | Table 4.2: Options available for sharing and collaboration systems | ||
+ | ^**Options** ^ | ||
+ | |ACL user and BM relation can be augmented with permissions (view, edit), | ||
Since the user system was only added in the last iteration of the project only the simple stateless sharing options has been chosen. The choice was more about the ability to clean up the listing of the front page, which was becoming quite long, than to offer new possibilities. But because the model had already an edit and a view mode adding different permission was an easy task and has been implemented. Comment tracking was not implemented since it would have required too much code changes. Instead, a user can simply add his name to the comment itself if he wants to identify himself. | Since the user system was only added in the last iteration of the project only the simple stateless sharing options has been chosen. The choice was more about the ability to clean up the listing of the front page, which was becoming quite long, than to offer new possibilities. But because the model had already an edit and a view mode adding different permission was an easy task and has been implemented. Comment tracking was not implemented since it would have required too much code changes. Instead, a user can simply add his name to the comment itself if he wants to identify himself. | ||
Ligne 80: | Ligne 96: | ||
==== 4.3.3 Example Roundtrip of a Query ==== | ==== 4.3.3 Example Roundtrip of a Query ==== | ||
- | For this example, let’s take the action of creating a link between two elements. The action is decomposed into different events: first there is the drag operation, then the hover and the drop who will initiate an interaction with the server. Once the server responds, this will in turn initiate some actions on the client configuring the right data to be able to display the newly created link. For a more detailed description see figure and explanation in appendix | + | For this example, let’s take the action of creating a link between two elements. The action is decomposed into different events: first there is the drag operation, then the hover and the drop who will initiate an interaction with the server. Once the server responds, this will in turn initiate some actions on the client configuring the right data to be able to display the newly created link. For a more detailed description see figure and explanation in [[tm:appendixc]]. |
===== 4.4 Problems Encountered ===== | ===== 4.4 Problems Encountered ===== | ||
Ligne 104: | Ligne 120: | ||
==== 4.5.1 Web vs Desktop ==== | ==== 4.5.1 Web vs Desktop ==== | ||
- | Web applications and desktop applications both have their advantages and disadvantages. Most of the time, the advantages of one are the disadvantages of the other. A short overview of some respective advantages is given in table [[# | + | Web applications and desktop applications both have their advantages and disadvantages. Most of the time, the advantages of one are the disadvantages of the other. A short overview of some respective advantages is given in table 4.3. It is also noteworthy that the separation between web and desktop application is blurring. There exists on the one hand technologies to bring web applications to the desktop, and on the other hand features of web applications are directly integrated into desktop applications. For example, there is respectively the possibility to use Google docs in an offline mode, or to have Microsoft Office Live directly integrated into the Microsoft Office desktop applications. |
- | > **Web [advantages]** **Desktop (standalone) [advantages]** Multiplatform Offline work Without installation Response time (no delay between client-server) Always up to date Possibility to use older versions Social sharing Interaction with the desktop (D&D) Automated backup (server-side) Privacy | + | | Table 4.3: Advantages of the Web and the Desktop over each other || |
+ | ^**Web [advantages]** | ||
+ | |Multiplatform | ||
+ | |Without installation | ||
+ | |Always up to date |Possibility to use older versions | ||
+ | |Social sharing | ||
+ | |Automated backup (server-side) | ||
==== 4.5.2 Client-Server ==== | ==== 4.5.2 Client-Server ==== | ||
Ligne 126: | Ligne 148: | ||
==== 4.7.1 Traditional Methods ==== | ==== 4.7.1 Traditional Methods ==== | ||
- | **Object serialization: | + | **Object serialization: |
+ | |||
+ | **Relational database:** provides a good way to store data, but is heavily dependent on its schema. | ||
+ | |||
+ | **Object Relational Mapping:** allows storing objects in a relational database in order to level the limitations of serialization, | ||
+ | |||
+ | **Schema evolution: | ||
==== 4.7.2 Non-conventional methods ==== | ==== 4.7.2 Non-conventional methods ==== | ||
Ligne 165: | Ligne 193: | ||
The question, if in this world of complexity, change and reuse of services, the relational database still is a good solution to guarantee data structure and persistence, | The question, if in this world of complexity, change and reuse of services, the relational database still is a good solution to guarantee data structure and persistence, | ||
+ | |||
+ | [[tm: | ||