Finally, we verify and validate the requirements summed up in Table4.1. Please
4.36
note that this table also contains the requirements that will be defined in the second part of this thesis. According to the chosen agile software development process model, we cannot completely pass-through the traditional process phases, such as requirement elicitation, analysis, and validation [Pae+03]. That is because some of the already defined requirements (e.g., architectural requirements) are intended to be abstract and become tangible as soon as they pass the various iterations of the agile bottom-up development process (cf. Figure3.4). Despite this, the pre- sented requirements can be considered as robust because they were proposed and developed by external domain experts with a lot of experience. However, we will check four general points according to Boehm’s guidelines to verify and validate software requirements [Boe84] – (i) completeness, (ii) consistency, (iii) feasibility, and (iv) testability – to certify that the defined requirements offer an acceptable initial description of the system to be implemented. We have to remember that the requirements concern two levels. First, from a bottom-up perspective, we have to consider the requirements that refer to the output of the model-driven devel- opment infrastructure, which is a mobile application. Second, the model-driven development infrastructure itself must satisfy several requirements. Therefore, modeling and tooling requirements refer to the infrastructure, whereas architecture requirements refer to the resulting mobile application.
TABLE4.1: Requirements of the MDD framework for mobile applications
Part Require-
ment No. Aspect Requirement name
I 4.1.1 Modeling Detailed Data Modeling
I 4.1.2 Modeling Abstract and Detailed Behavior Modeling
I 4.1.3 Modeling Abstract Graphical User Interface Modeling
I 4.1.4 Modeling Well-Formedness of the App Model
I 4.1.5 Modeling Model Quality Assurance
I 4.2.1 Architecture Data-Driven Mobile Applications
I 4.2.2 Architecture Single User System with Back-End Access
I 4.3.1 Tooling Graphical Model Editor
I 4.3.2 Tooling Code Generator
II 10.1.1 Architecture Support of User Roles (User Context)
II 10.1.2 Architecture Heterogeneous Device Support (Device Context)
II 10.1.3 Architecture Interoperable, Multi-User Systems
II 10.1.4 Architecture Online and Offline Capability (System Context)
II 10.2.1 Modeling Declaration of Online- and Offline-Capable Data
II 10.3.1 Modeling Provider Model Editor
II 10.3.2 Tooling Simulation System
Completeness: Boehm stated that a specification is complete if all parts of a system
4.37
4.4. Discussion 53 The initial presentation of the model-driven development process (cf. Section2.1
and2.2) indicates all parts of a model-driven development system. Hence, we can say that the requirements cover all the parts mentioned therein. Each part is covered by several requirements, which implies a complete presentation of the requirements according to the component itself.
Consistency: Consistency has two dimensions. First, internal consistency needs the 4.38
requirements not to be contradictory to each other. So far, this is not critical because there is only a small set of requirements. However, while using an iterative approach and adding more requirements in a following iteration, we must always consider the existing requirements. Second, external consistency needs the requirements to correctly fit to the referenced specifications, standards, and technologies. For example, the required freehand-editing mode of the graphical model editor must be compatible with the chosen meta-tools for creating graphical editors. Otherwise, the external consistency is violated.
Feasibility: Boehm gave a wide definition of feasibility. He did not only consider the 4.39
feasibility of the software system, but also its feasibility in terms of maintainability and changeability. This is as relevant as ever since the domain of mobile applications is very volatile and fast-moving. An agile bottom-up development process deals with the feasibility criterion very well, because it matches the fast-changing domain and the maintainability of the resulting system.
Furthermore, Boehm stated that the requirements should be evaluated on the basis 4.40
of the human-, resource-, and program engineering factors. The human engineering factor asks whether the specified system provides a satisfactory way for the users to perform their tasks. Unfortunately, there is little knowledge about how to evaluate the design of a model-driven development infrastructure upfront. Hence, the intention is to deliver the model-driven development infrastructure, especially the graphical model editor, as soon as possible, and refine the requirements based on user feedback, if needed. The resource engineering factor is a classical cost factor [BP88] and must be considered while defining the requirements. The last factor, program engineering, concerns portability and maintainability. Since we build on an existing framework (Eclipse Modeling Framework – EMF [Ste+09]), we can positively evaluate the program engineering factor because the chosen platform is well-known and used widely in industry and academia.
Testability: We have to admit that the presented requirements are not specific enough 4.41
for the derivation of test cases that are appropriate for a pass/fail acceptance test. Besides, they are not complete according to the chosen iterative approach. Despite, every contribution is evaluated separately. Due to the different kinds of contributions, the evaluation methods must be chosen carefully, i.e., the testability and the test approaches might differ. For example, the evaluation of the domain- specific modeling language involves, among other techniques, user interviews and observations because human interaction plays a role when domain-specific modeling languages and the corresponding model editors are developed. On the other hand, accurate code generation from different (randomly created) app models can be tested automatically using unit tests.
55
Chapter 5
Domain Analysis (Model-Driven
Development and SE of Mobile
Applications)
The term domain analysis was defined by Neighbors [Nei80] as “the activity of 5.1
identifying the objects and operations of a class of similar systems in a particular problem domain.” Our problem domain deals with mobile applications and their development. Hence, we should not only consider the features of mobile applica- tions but also the features of existing and future development environments (e.g., a model-driven development environment).
Figure5.1shows the input and output artifacts of a general domain analysis activity. 5.2
In the course of this work, we will use most sources of domain knowledge, namely technical literature, existing implementations (reference applications), expert advice, and current requirements for our domain analysis. Based on this analysis, we develop several novel contributions. The output of a domain analysis activity consists of one or more domain models of different types. Domain models might be taxonomies, standards, functional models, and domain languages. These products of the domain analysis can again serve as an input of a domain analysis, indicated by the cycle in Figure5.1. Hence, domain analysis is an iterative process, which will be applied again in the second part of this thesis to extract and implement further features of the desired domain (cf. Chapter11).
Based on the different domain analysis approaches listed by Frakes and Kang 5.3
[FK05]1, we select the feature-oriented domain analysis (FODA) approach proposed by Kang et al. [Kan+90]. The feature-oriented domain analysis approach consists of the following steps: (i) context analysis, (ii) domain modeling, and (iii) architecture modeling. To develop a model-driven development infrastructure, especially at first a domain-specific modeling language, we focus only on the domain modeling step and ignore the other steps. One result of the domain modeling step is a feature model lending the name to the feature-oriented domain analysis. Feature models represent the mobile end-user’s perspective of the capabilities of the mobile applications in a domain or the mobile application developer’s perspective of available architectures and development techniques. A feature model is very useful to develop the domain- specific modeling language at a later time. The feature model will be developed during the following feature analysis.
According to Kang et al. [Kan+90], the feature analysis has the following five 5.4
steps: (1) collecting sources of domain knowledge (Section5.1), (2) identifying features (Section5.2), (3) abstracting and classifying the identified features as a model (Section5.3), (4) defining the features, and (5) validating the model (Section
5.5). We join the steps (2) and (4) because feature identification and definition are strongly related.
domain
analysis
sources of domain knowledge technical literature existing im- plementations customer surveys expert advice current and future requirements taxonomies standards functional models domain languages Domain modelsdomain analysis methods management procedures
problem domain experts
domain analyst
domain engineer
FIGURE5.1: Domain analysis with input and output artifacts (taken from [PD90])
5.1
Sources of Domain Knowledge
As Figure5.1shows, taxonomies might be an output of a domain analysis. Since
5.5
the literature already provides several taxonomies related to mobile applications (e.g., [Nic+07] [KEG12] [Emm+13] [Abo+14]), to software engineering of mobile applications/ubiquitous computing (e.g., [Abo+99], [Mod+06], [Lup+09], [Jeo+07],
[Mad+02]), and to model-driven development and model transformation (e.g.,
[MG06], [Deg+14]), we could use them as an input for a feature-oriented domain
analysis. Using the literature as a source of domain knowledge will simplify the validation of the feature model later because scientific literature is an external source of knowledge and quite robust against a subjective bias. However, some features are proposed by us independently from the existing literature. Thus, the resulting feature model will reflect more than the state-of-the-art features.