# t_package

Notes:
Purpose:
The purpose of the DDI4 Data Capture Instrument View is to describe the processes of developing- and collect data from a questionnaire instrument, as well as to describe the capture or acquiring of measurements from various sources, like databases, registries, administrative data, bio-medical devices, environmental sensors, or any other source or instrument. The focus on measurement is new in DDI4 compared to earlier versions of the standard.

Use Cases:
Document  the development process for a conceptual questionnaire of an international survey
Design an implemented questionnaire in a specific mode and for a specific population
View how a measurement has been captured or how a survey question has been asked
Reuse of instrument components developed for a different study
Export instrument related metadata between applications
Design a measurement
Describe a measurement  instrument 

Target Audiences:
Developers of conceptual instruments, for example for an international survey
Designers of implemented instruments for surveys and measurements
Designers and developers of data capture tools
Researchers wishing to understand how a measurement has been captured or how a survey question was asked or how it was developed
DDI4 users in general

Restricted Classes:
WorkflowStepSequence is extended by StructuredWorkflowSteps.
RepresentedVariable is extended by InstanceVariable.
CodeList is extended by GeographicUnitClassification, GeographicUnitTypeClassification and StatisticalClassification.
ConceptualVariable is extended by InstanceVariable
Concept is extended by InstanceVariable, Population and UnitType;
ExternalMaterial is extended by ExternalAid.
Code is extended by ClassificationItem.

General Documentation:
Questionnaire development – a brief overview

The goal of questionnaire design is to develop an ImplementedInstrument from which data can be captured when put in field. 

The first step in a questionnaire design process is often to select or define the topics and the Concepts to be measured by the questions in the instrument. 
The concepts are then operationalized into RepresentedQuestions that contains the more reusable components of a question that can be reused among different surveys, studies and modes of collection.
InstanceQuestions realize the represented questions in an instrument. It connects to other InstrumentComponents like for example a showcard or other ExternalAid and Instructions, and links the question to the flow logic of the questionnaire. 
The ConceptualInstrument represents the instrument independent of mode. It organizes the instrument by connecting the instrument components to WorkflowStepSequence that realizes the flow of a questionnaire sequence, including conditions IfThenElse, Loop etc.. 
The ImplementedInstrument has a specific mode and is designed or adapted for a specific sample or population. Two different implemented instruments may use the same conceptual instrument. 

Measurement 

Measurements are non-question based data captures like for example blood pressure measurements, MRI images, thermometer, web-service, and experimental observations.
Measurements often involve the use of specific machines or protocols to ensure consistency and comparability of the measure. The RepresentedMeasurement is a description of the components of a measurement, that can be reused by multiple or repeated studies.
The ImplementedMeasurement initiates the represented measurement so that it can be used in the data capture process. Other InstrumentComponents like Instructions and ExternalAids associated with the measurement can be linked to the implemented instrument.
The ConceptualInstrument represents the reusable components of the instrument that can have different concrete implementations. It connects to the WorkflowStepSequence that realizes the instrument flow. A WorkflowStep can be linked to a WorkflowService that involves agents and services involved in the process step.
The ImplementedInstrument is a specific implementation of a conceptual instrument.


Notes:
Purpose:
The Agent Registry View supports the creation of a listing of Agents (Organization, Individual, Machine) for the purpose of maintenance and reuse. The listing of Agents can be organized as simple lists or in more complicated structures through the use of an AgentRelationStructure. These may be typed and provided with effective date ranges either for the whole AgentRelationStructure or for individual AgentRelations. 
Complex relationships may be described among Individuals or among Organizations or among Machines. Relationships between members of these classes may also be described.


Use Cases:
Maintaining a listing of all Organizations and Individuals related to a project or statistical activities, i.e. Individuals and Organizations related to the IPUMS projects at the Minnesota Population Center or the Departments and Individuals involved in the production of the Australian Census within the Australian Bureau of Statistics.
Organizational affiliations of Individuals. 
Collaboration networks or other social networks.


Target Audience:
Organizations working with a number of Individuals and Organizations whose descriptive information and interrelationships change over time.

Included Classes: Agent Listing, Agent Relation Structure, Organization, Individual, Machine, and External Material. 

Restricted Classes:
Concept is extended by Category, ConceptualVariable, RepresentedVariable, InstanceVariable, Population, UnitType and Universe
ExternalMaterial is extended by ExternalAid


General Documentation:
The primary class is the Agent List which can be structured by AgentRelationStructure. Agents may be of any type supported by DDI at the time of this release. Agent relationships can be defined using the adjacency list Agent Relation within AgentRelationStructure. specifying the RelationshipSpecification (Equality, Parent/Child, Whole/Part, etc.), a relevant semantic such as a specific role or relationship type, and effective time span for the relationship.


Notes:
This package comprehends XML Schema datatypes which are used in the DDI model.


# t_projectroles

Description:
Define and model the application structure


Notes:
Define and communicate application architecture


# t_requiretypes

Description:
System will display in a specified format

Notes:
Information will be displayed in a particular way


Notes:
The system must meet some performance criteria


Notes:
The system will allow the user(s) to print out some artifact as required by the specification.


Notes:
The system will have the facility to produce a report as required


Notes:
The system will validate a specific rule as supplied in the business requirements


# t_scenariotypes

Notes:
Path of execution that includes exceptional conditions.


Notes:
The standard execution path with no exceptions


# t_stereotypes

Description:
A classifier whose instances represent a flow


Description:
Source class will be notified when an event occurs in target


Description:
A worker who directly interacts with actors outside the system


Description:
Passive class accessed and manipulated by workers


Description:
A worker that interacts with other workers and entities inside the system.


Description:
An abstraction of a human that works within the system.


Description:
Contains business process objects, work units, organization units and relationships


Description:
Subsystem corresponding to an organizational unit of the actual business


Description:
Specifies an element that is at the system boundary (e.g.. User Interface)


Description:
A class that represents a client based web page


Description:
Specifies an element that controls the work and lifetimes of other objects


Description:
Specifies a persistent element mainly concerned with managing its own state


Description:
An event may be thrown or caught by operation


Description:
A class that represents a html frame set


Description:
Implementation of a class in some programming language


Description:
A collection of operations that specify a service of a class or component


Description:
A classifier whose objects are all children of a given parent


Description:
A library of subroutines/functions for web pages


Description:
A class that represents a server based web page


Description:
Specifies an asynchronous stimulus communicated amongst instances


Description:
The classifier is a stereotype that may be applied to other elements


Description:
A class that represents a database table


Description:
A classifier whose instances represent a lightweight flow of control


Description:
An abstract class specifying the structure but not implementation of a set of objects


Description:
A class whose attributes and operations are all class-scoped


Description:
A classifier whose objects are all classes


Description:
Specifies a desired feature, property or behavior of system


Description:
Specifies a contract by or an obligation of a class


Description:
Component represents a document containing source code


Description:
A component that represents a database table


Description:
Constrain must always hold for associated element


Description:
A constraint must hold after the invocation of an element


Description:
A constraint that must hold before an element is invoked


Description:
Public contents of target are accessible to namespace of source


Description:
Source instantiates target template using given parameters


Description:
Source is given special visibility of target


Description:
Public contents of target are imported into source namespace


Description:
The source object is an instance of the target


Description:
Operations on the source class create instances of the target class


Description:
Source is at a finer degree of abstraction than source


Description:
The target is an historical ancestor of source


Description:
The semantics of the source depend on the public part of the target


Description:
Child inherits implementation of parent but does not support its interfaces


Description:
A GUI element that forces user selection


Description:
A GUI element for grouping other controls


Description:
A List of Information with an expandable text field


Description:
A List of Information with a tree structure


Description:
Corresponding object is visible because of enclosing scope


Description:
The corresponding object is visible in local scope


Description:
The corresponding element is visible because it is a parameter


Description:
The corresponding object is visible because it is the dispatcher


Description:
Target is same as source but later in time


Description:
Target is exact but independent copy of source


Description:
Contains analysis classes - entities, boundaries and control elements


Description:
Contains implementation subsystems and/or components and relationships


Description:
Specifies the services offered to the users


Description:
A class that represents a personal computer


Description:
A class that represents a storage device


Description:
A Check constraint to enforce domain integrity


Description:
A trigger which executes automatically when an UPDATE, INSERT, or DELETE statement is issued


Description:
A Unique constraint to enforce the integrity of a database automatically


Description:
Package is a view of another concrete package


Description:
A semantically closed abstraction of a system


Description:
A package serves as a proxy for the public contents of another package


Description:
A grouping of elements that constitute a specification of behavior offered by other contained elements


Description:
A package representing the entire system being modeled


Description:
Communication between actor and use case


Description:
Target use case extends the source at a given extension point


Description:
Source use case explicitly includes the behavior of target


# t_tcf

Description:
Response or throughput performance objectives


Description:
Special user training faciities are required


