Goal-Oriented Conceptual Database Design PDD
Hareune Asfour
Faculty of Science - Utrecht University
February 2013
Author Note:
A PDD description Presented in Partial Fulfillment of the Requirements for
The Master Business Informatics course Method Engineering
Abstract. This PDD description is part of the requirements for passing the Master Business Informatics
course “Method Engineering” .In this course, the students acquire the knowledge and skill to describe and
evaluate various ICT systems methodologies. Multiple papers on different methodologies are presented
to students in order for them to analyze it and to describe it efficiently .This document presents a
description in a form of a PDD model of one of the methodologies, this methodology is commonly known
as the Goal-Oriented Methodology. In order to describe this Methodology rationally, an early paper on
Goal-Oriented Conceptual Database Design (Jiang 07) is used as core reference.
Keywords: Method Engineering, Methodology, Goal-Oriented, Database Design
1. Process Description
Step 1: Identify stakeholder goals, including their quality requirements.
Input: A list of stakeholders.
Output: A list of high-level goals of the stakeholders.
Task(s): Goal identification.
Description: In this step, the objective is to pinpoint the goals of each stakeholder, and categorize
them into hard goals (accomplishable) and soft goals (very hard to accomplish).
Step 2: Generate a goal model
Input: A list of goals produced in Step 1.
Output: A goal model.
Task(s): Goals analysis.
Description: Not enough details can be extracted from the list of goals, that’s why Goal (AND/OR)
decomposition can be used to refine these goals into sub goals based on the case addressed. Systematic
methods of decomposing goals have been proposed in a variety of approaches (take goal-based
variability acquisition and analysis (Liaskos 06) as an example). For soft goals, the NFR framework
(Chung 00) offers a catalogue of refinement methods. Moreover, the contribution analysis (Bresciani
04) can be used to identify positive/negative contributions to the fulfillment of goals.
Step 3: Select a design alternative
Input: The goal model obtained in Step 2.
Output: A set of the leaf-level goals in the goal model
Task(s): Goal evaluation.
Description: The Goal model shows the possible paths to achieve the ultimate goal; these possible
paths are called design alternatives. In this step we choose the best suitable design alternative
accordingly to the preference of the stakeholders.
Step 4 Identify initial set of domain notions from goals.
Input: The design alternative chosen in step 3
Output: A list of domain notions extracted from the design alternative chosen.
Task(s): Domain knowledge extraction.
Description: this is step where the data requirements are extracted from the goals stated in the chosen
design alternative, the focus in this step is to derive the domain notions which will form later on the
database schema. Domain notions are potential notions about which data is to be stored.
Step 5 Identify and select plans.
Input: The design alternative chosen in step 3
Output: A set of plans that collectively fulfill these goals.
Task(s): Plan evaluation.
Description: the focus on this step is on generating SMART plans to fulfill the goals chosen
respectively in the alternative design.
Step 6 Expand the set of domain notions using plans.
Input: The plans in the chosen design alternative.
Output: A list of domain notions extracted from these plans.
Task(s): Process modeling, domain knowledge extraction.
Description: In this step we extend the list of domain notions from step 4 by extracting domain
notions from the plans drawn in step 5 in addition to other possible sub plans.
Step 7: Construct the domain model
Input: The expanded list of domain notions from step 6.
Output: A domain model
Task(s): Domain analysis.
Description: This is the step where the domain notions are transformed into a domain model (the
initial database schema) using a diagrammatic notation such as UML.
Step 8 Construct the conceptual schema.
Input: The domain model from Step 7.
Output: A conceptual schema.
Task(s): Schema transformation
Description: In this step, we expand the domain model through series of predefined design operations.
These design operations are part of the Goal-Oriented design strategy template of this methodology.
This template provides guidelines to tackle certain design issues by applying the design operations
provided in the template.
2. PDD
GOAL
Goal Identification
- Goal
- Category
- Preference
Idontify goals
Categorize goals
has
Software Developer
Goal model generation
Refine goals
SUB-GOAL
Identify Contributions
CONTRIBUTION
Build goal model
GOAL MODEL
Software Developer
has
Design Alternative selection
Select a design alternative
DESIGN ALTERNATIVE
Check Stakeholders preference
[else]
[Prefered]
Software Developer
has
Domain notion Identification
DOMAIN NOTION
Extract domain notions
Software Developer
Plans identification
Identify Plans
PLAN
Identify contributions
Software Developer
Domain notion expansion
Expand Domain notions
Software Developer
Domain model construction
Construct domain model
DOMAIN MODEL
Software Developer
Conceptual schema
Identify design issues
Implement design operations
Construct conceptual
schema
Software Developer
DESIGN ISSUE
has
Is used
DESIGN OPERATION
CONCEPTUAL
SCHEMA
3. Activity table
Activity(phase)
Goal Identification
Sub-Activity
Identify goals
Categorize
goals
Goal model
generation
Refine goals
Identify
contributions
Build goal
model
Design alternative
selection
Select a Design
Alternative
Check
stakeholder
preference
Domain Notion
Identification
Extract domain
notions
Plans identification
Identify Plans
Domain notion
expansion
Identify
Contributions
Expand domain
notions
Domain model
construction
Construct
domain model
Conceptual schema
Identify Design
issues
Implement
Design
operations
Construct
Conceptual
schema
Description
A list of goals are identified based on the wishes of
the stakeholders
The goals identified in activity “Identify goals” are
categorized into hard goals (accomplishable) and soft
goals (very hard to accomplish).
The goals identified in activity “Identify goals” are
refined into sub goals using (AND/OR)
decomposition
A set of contributions are identified for the refined
goals in activity “Refine goals”
A goal model is built based on the refined goals
(Activity “Refine goals”) and the contributions
(Activity “Identify contributions”)
The Goal model shows the possible paths to achieve
the ultimate goal; these possible paths are called
design alternatives, in this activity a Design
Alternative is selected
The design alternative selected in Activity “Select a
Design Alternative” is checked based on the
preference of the stakeholders. If the design
alternative selected doesn’t have a high preference
then a new Design Alternative must be selected,
otherwise it is chosen.
Domain notions are potential notions about which data
is to be stored, so in this activity, a set of domain
notions are extracted from the chosen Design
Alternative from activity “Check stakeholder
preference”
A set of plans are identified to fulfill the goals stated
in the chosen Design Alternative from Activity
“Check stakeholder preference”
A set of contributions are identified which show how
a plan can contribute in fulfilling a goal
The previous domain notion from Activity “Domain
Notion identification” are expanded by domain
notions extracted from the Plans identified in Activity
“Identify Plans”
The domain notions identified from the Activities
“Extract domain notions” and “Expand domain
notions” are used to construct a domain model
A set of Design issues are identified
Role
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
Software
Developer
A set of Design Operation are implemented for the
identified Design issues from previous (sub)activity
Software
Developer
Software
Developer
The conceptual schema is build based on the domain
model build in Activity “Construct domain model”
Software
Developer
4. Concept table
Concept
GOAL
Description
A GOAL has a “category” (Hard or Soft) and a “preference”, GOAL is part of
SUB-GOAL
CONTRIBUTION
GOAL MODEL
DESIGN ALTERNATIVE
DOMAIN NOTION
PLAN
DOMAIN MODEL
DESIGN ISSUE
DESIGN OPERATION
CONCEPTUAL SCHEMA
the GOAL MODEL
A SUB-GOAL is identified based on GOAL
A set of CONTRIBUTIONs are identified and used in the GOAL MODEL
A GOAL MODEL constitutes of goals from GOAL, contributions from
CONTRIBUTION and plans from PLAN. GOAL MODEL has DESIGN
ALTERNATIVES
A DESIGN ALTERNATIVE is extracted from GOAL MODEL. A DESIGN
ALTERNATIVE has DOMAIN NOTIONs
A DOMAIN NOTION is Extracted from a DESIGN ALTERNATIVE. A
DOMAIN NOTION is part of the DOMAIN MODEL
A PLAN is identified to fulfill a GOAL in the GOAL MODEL
A DOMAIN MODEL constitutes of DOMAIN NOTION(s)
A set of DESIGN ISSUEs are identified
A DESIGN OPERATION is implemented to counter measure a DESIGN
ISSUE
A CONCEPTUAL SCHEMA constitutes of DOMAIN MODEL(s) where
DESIGN OPERATIONs are implemented.
References
Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F. and Mylopoulos, J. (2004).
Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent
Systems,8(3):203–236,
Chung, L., Nixon, B. A., Yu, E. and Mylopoulos, J. (2000). Non-Functional Requirements in Software
Engineering. Kluwer Publishing.
Jiang, L., Topaloglou, T., Borgida, A. and Mylopoulos, J. (2007). Goal-Oriented Conceptual Database Design.
Proceedings of the 15th IEEE International Requirements Engineering Conference, Univ. of Toronto, Toronto,
Canada.
Liaskos, S., Lapouchnian, A., Yu, Y., Yu, E. and Mylopoulos, J. (2006). On goal-based variability acquisition
and analysis. In Proceedings of the 14th IEEE International Conference on Requirements Engineering.