![]() |
The evolution of POWEM is motivated (but not necessarily mandated) by the directions of evolution of the Web. |
| POWEM can be extended in at least two orthogonal directions. |
![]() |
One possible extension of the model is increasing the granularity of the quality attributes at the level Pragmatic- |
| Tier 1, and thereby adding another level (say, Tier 0) underneath it. In that case, for example, fault tolerance and | |
| availability could be two quality attributes that belong to the level Pragmatic-Tier 0. |
![]() |
Other possible extensions of the model are the use of patterns for improving higher- or lower level semiotic |
| quality concerns. |
![]() |
Other possible extensions are: |
![]() |
Patterns in Social Web Engineering. |
![]() |
Patterns in Semantic Web Engineering. |
![]() |
A pattern-oriented systematic approach for a development of mobile applications would be another future |
| prospect. However, 'recasting' POWEM for mobile applications would neither be trivial, nor automatic. The | |
| constrained environment of mobile applications is uniquely different from that of the stationary (desktop) | |
| applications, and must to be taken into consideration. |
![]() |
Anti-patterns for quality of Web applications: It is defined as a combination of two aspects: |
![]() |
First, for a recurring problem in a given context, there is a solution such that if this solution is applied, the | |
| system is placed in a state worse than it was previously. |
![]() |
Second, to improve this, the "negative" solution is re-factored to a "positive" solution. If a pattern reflects a | |
| "best practice," then an anti-pattern reflects a "lesson learned". |
![]() |
A pattern applied to an inappropriate context can compromise the benefit it offers and give the appearance | |
| of an anti-pattern. There is currently an apparent lack of stable and mature collection of anti-patterns for Web | ||
| applications. |