UNIT 5 SPECIFICATION OF DETAILED CONCEPTUAL DATA MODELS

Question 1

What is a Conceptual Data Model?

Answer 1

They are models used in the specification of conceptual entities (business objects) and their correlations. Conceptual data models are used to uniformly define conceptual classes (business objects) and their correlations for all participants. Software models (such as Unified Modeling Language [UML] class diagrams) serve to specify the structure, composition, and relationship between different functional classes. With complex systems that process identical data in different components, conceptual data models are a way of ensuring that exchangeability between individual components and systems is retained. A conceptual data model therefore acts as a parenthesis around the different aspects of a system and its specification.

Question 2

How are Data Models used for Component and System Behavior?

Answer 2

When specifying component and system behavior, data models (also known as domain models) are used to document business objects, their properties, and their correlations. The modeled conceptual classes clearly and concisely denote which information the system must process and support. While process models prescribe the HOW of a system, data models specify the WHAT.
From the development team’s perspective, the conceptual data model provides a rough framework for defining the system’s data architecture. It can also help to identify requirements by acting as a kind of checklist. Each relevant element in the data model must be supported by the software system. The development and detailing of the conceptual data model in collaboration with the relevant stakeholders is vital for transferring knowledge from the requirement sources to the development team.

Question 3

How are Data Models used for GUI Specification?

Answer 3

An information system communicates with its users via the user interface, so the GUI is used for manual inputs and modeling the business objects stored in the system. All relevant elements from the domain model must therefore be taken into account when designing the GUI. The structure of business objects also has a decisive influence on the design and implementation of the system interface because many of the GUI requirements are derived directly from the conceptual data model. Examples include the number of input and output elements, requirements governing validation via the data type, and the input of self-selected values via the text box or from a list.

Question 4

How are Data Model used for Technical Interfaces?

Answer 4

A user can extract the key information from a letter or email and enter it in the system via the GUI, thereby transforming an unstructured message into structured information. Software systems communicate directly at technical interfaces via the exchange of messages. Unlike letters and emails, the data transferred at a technical infrastructure must conform to a strict predefined structure, otherwise the message will not be (fully) understood. A conceptual data model provides the basis for a detailed specification of messages at a technical interface. Smooth interoperability between software systems is only possible when the development team reaches a detailed, thorough agreement on the structure of messages exchanged between systems.

Question 5

How are Documentation Forms used for Data Models?

Answer 5

Conceptual data models can usually be documented with the same concepts as technical models. Visual software models, such as UML class diagrams, UML object diagrams, and entity relationship diagrams, are widely used. Data models at interfaces are often described using Extensible Markup Language (XML) as structured text.
* UML class diagram: For documenting conceptual and
technical elements at type level, from analysis through to implementation
* UML object diagram: For representing specific data
records or business objects; for illustrating instances in a class diagram
* Entity relationship diagram: For specifying data and database models; often used in a database context
* XML: For specifying data models at system interfaces; for specifying data models of documents and strict tree structures

Question 6

How are UML Class Diagrams used in a RE environment?

Answer 6

In a requirements engineering environment, class diagrams are used to document static concepts in an application area. This includes business objects; conceptual entities (industry-
specific real and virtual “things” that are managed by information systems); persons; objects; and systems and their relevant properties, relationships, and interdependencies. Their purpose is to document, comprehend, and communicate the conceptual problem. The classes in the class diagram are therefore interpreted as concepts of their environment rather than elements of a system.
A UML class equates to a conceptual concept, i.e., a group of objects with the same characteristics, such as customer, item, or order, as shown in the following figure. The class diagram is not suitable for modeling behavior or operations.

Question 7

What are some common aspects of the conceptual or technical specification of data models?

Answer 7

• Identifier (ID) Attribute for Unique Identification
• Completeness of all Attributes
• Detailed Properties of Attributes
• Data type
• Multiplicity
• Default setting
• Property values
• Constraints

Question 8

Explain the Identifier (ID) Attribute for Unique Identification aspect for specification of data model.

Answer 8

Business objects must usually be clearly distinguishable from one another and uniquely identifiable. When referring to an instance of a class in an object-oriented system, two objects are considered identical if all their attributes are identical. The addition of an ID attribute to the data model allows data records to be distinguished and identified, even if the business object’s conceptual attributes are insufficient for this purpose. These conceptual ID attributes will not usually change over a business object’s lifecycle. A change to the ID implies a conceptually different object. There is a crucial distinction between conceptual IT attributes and technical ID attributes.
Conceptual IT attributes must never be used for the technical distinction of data records or business objects, for example, as an entry in a database. It is often the case, when upgrading an outmoded system, that the conceptual data are transferred into the new system. This may necessitate an amendment to the value ranges of the admissible technical IDs. As such, it must be possible to amend the technical ID independently of the conceptual ID attribute. Conversely, it must also be possible to amend a conceptual ID without simultaneously amending the technical ID. There is a risk that extensive amendments and modifications may be needed if this distinction is not consistently maintained.
It is also possible for data records to be given a separate, internal technical ID that is not clear outside of the system. Comparisons at system interfaces should therefore only be
made on the basis of one or more conceptual ID attributes.

Question 9

Explain the Completeness of all Attributes aspect for specification of data model.

Answer 9

When preparing a conceptual/technical specification, it is important to ensure the completeness of all relevant business objects and their attributes. For data models at technical interfaces in particular, it is crucial to ensure that both the message sender and its recipient are using the same information structure. Previously modeled operations and scenarios may be useful when verifying completeness; the same applies to object diagrams.

Question 10

Explain the Detailed Properties of Attributes aspect for specification of data model.

Answer 10

The documentation of attributes and their name is often sufficient for the purposes of requirements engineering (RE), whereas conceptual/technical specification dictates that a data type must be specified for each attribute. Among other things, definition of a data type will influence
* the choice of input and output elements on the GUI.
* the validation and conversion rules for the GUI.
* the chosen technical data type in the database and all other technical components required for interim storage and editing.
* the chosen technical data type for messages to system interfaces.
Here’s an example for the detailed and complete specification of attributes, whereby the elements in “[]” are optional:
Name of attribute: Data type [Multiplicity] [= Default value] [{Property values|Constraints}]

Question 11

Explain the Data Type aspect for specification of data model.

Answer 11

A string (technical data type for storing strings of
characters of unlimited length and type) is a very general data type for attributes and should be chosen if there are no conceptual or known technical restrictions on the value range.
Consequently, the value ranges for attributes should only be restricted for conceptual or known technical reasons. Length restrictions and limitations on accepted values are often specified to save storage space and facilitate GUI inputs. These unnecessary restrictions may prove impractical over the application’s lifecycle, leading to avoidable modifications
and maintenance work.
A typical example is the specification of attributes when building numbers are saved in the form of integers (whole numbers), which would preclude the addition of a building numbered 15b. Another example would be to specify the data type for post codes as integers, so that when the postcode 01069 is entered, the leading zero is omitted and stored in the database as 1069.

Question 12

Explain the Multiplicity aspect for specification of data model.

Answer 12

Optional multiplicities allow you to specify how many values may be linked to an attribute. Multiplicities are often modeled together with associations. In the UML class diagram, these quantities may be documented immediately after the data type.

Question 13

Explain the Default setting aspect for specification of data model.

Answer 13

The optional default value setting (also known as an initial value) allows the definition of a value that is automatically pre-assigned to the attribute. For example, today’s date may be pre-entered in the date box by default, or a frequently selected option assigned to selection boxes. Default settings help to make a system more usable.

Question 14

Explain the Property values aspect for specification of data model.

Answer 14

Optional property values are used to document additional information about the attribute that may be relevant when creating the system. Examples of property values include
* {readOnly}: value cannot be overwritten.
* {unique} or {id}: value must be unique; no other object may have the same value for this attribute.
* {ordered}: values are listed in order and do not contain any duplicates.
Property values are specified as required on an individual project basis.

Question 15

Explain the Constraints aspect for specification of data model.

Answer 15

Optional constraints (conditions and restrictions) are used to provide further details of admissible attribute values, in addition to data type. Constraints can define the length and type of admissible characters in the attribute value, stipulate compliance with certain format guidelines, and define interdependencies with other attributes. For example, in the terms of a contract, one requirement is that the start date must be before the end date.
Where these constraints are already known at the time of specification, they may be incorporated directly into the data model for that attribute.
Unlike object-oriented analyses, specifications do not document an attribute’s visibility.

Question 16

What are Enumerations and how are they used?

Answer 16

Some attributes in the data model will generally have a pre-defined set of admissible values. This means that an attribute’s specific value cannot be freely assigned within the
value range for its data type but must belong to the predefined set.
When specifying a conceptual/technical data model, these types of lists may be defined as a separate data type, known as enumerations.
Enumerations are specified in the same way as classes with attributes: The stereotype «enumeration» denotes it as an enumeration data type rather than a business object.
Possible values are specified as attributes of the enumeration class. Enumerations can be used in all other classes of that model. If you need to modify the value set of an enumeration type, you only need to do so once.

Question 17

How do Business Rules put constraints on the Structure of Data Models?

Answer 17

Structural business rules may be used for the detailed specification of data models. These rules specify key static aspects of a system that must apply to the data model at all times. Structural business rules are composed of terms and facts. Terms are words or descriptions with particular conceptual relevance in the data model. These terms should be explained in a glossary. The facts describe the relationships between terms. Unlike business rules, which specify behavior, structural rules relate only to the data model. Some of these rules are readily denoted in UML. Rules that cannot be modeled directly in the class diagram may be documented in natural language to complement the data model.
Always write structural business rules in a declarative (descriptive) way, stating simply that they apply but without any indication of when the specified rules are reviewed. The development team decides when and where in the system this occurs.

Question 18

What are Relationships between Classes?

Answer 18

Functional dependencies and relationships between classes are described as relationships (or associations) between classes. The notation elements in the UML class diagram already used in requirements engineering are generally sufficient for a detailed specification.

Question 19

What is important to do in the Specification of Functions?

Answer 19

Occasionally, in a conceptual data model, classes may be identified which are responsible for key functions. Responsibilities for conceptual functions can be included in the data model as methods relating to modeled classes. However, only essential conceptual functions should be specified at this point. Trivial and obvious methods, such as reading and amending values, should not be modeled here. For function, alongside the name, it is also important to describe the quantity and data type of the required parameters together with the quantity and data type of the return type(s).

Question 20

What is an UML Object Diagram (OBD)?

Answer 20

Object diagrams (OBD) are a type of class diagram, used to represent an instance of a class by modeling objects whose attributes contain specific values. Objects differ from classes in that they show a particular value for each attribute of an object. The class name is underlined and preceded by a colon “:”. Where necessary, the object can be identified with a unique ID to the left of the colon. The ID in the object header is a technical ID, rather than a conceptual ID, which is only valid in the object diagram.

Question 21

What are UML Object Diagrams used for?

Answer 21

Certain complex system states may be denoted using object diagrams to check and evaluate the conceptual correctness of class diagrams, as well as the current status of data records. Object diagrams are particularly ideal for denoting quantities. By modeling quantities as multiplicities of relationships in the class diagram, each individual object is explicitly represented in the object diagram. Modeling data record at the instance level, rather than at the type level (as in a class diagram), which requires far less abstract reasoning than would be needed to comprehend a class diagram. To aid legibility and comprehension of the object diagram, the corresponding class diagram must also be available so that the current status of objects can be seen in context. There is no need to specify all values of all object attributes in full. Object diagrams are often used to illustrate or discuss very specific value constellations or statuses.
When creating an object diagram, you should only include those values which are currently relevant for comprehension and omit all other values.

Question 22

How would you go about Using Object Diagrams to Check the Correctness of Class Diagrams?

Answer 22

Class diagrams contain numerous notation elements, which can be helpful when specifying data models, but their interpretation requires knowledge and practical experience.
Because attributes and relationships are inherited and quantities are documented as multiplicities, the conceptual accuracy of detailed class diagrams cannot always be verified with all stakeholders.
Class diagrams project a slice of reality (the real world) at type level by describing (summarizing) multiple similar real-life objects as types (classes). Object diagrams may help a layperson to verify the validity of this projection when modeling. For example, the legacy relationships may be conceptualized, whereas another representation may show each actual object and each actual link between those objects.
Wherever possible, use real-life data records to check class diagrams. For example, work with a subject expert to select typical business objects from their database, then generate them in the form of an object diagram for that particular class diagram. If a corresponding object diagram can be generated for each relevant data record, this indicates that the specified data model is probably suitable. Often, object diagrams will identify gaps and weaknesses in the data model, which then need to be rectified. Once a class diagram has been modified, it can and should be checked, for example when maintaining and upgrading an application. Modified class diagrams are checked in exactly
the same way as newly created diagrams.

Question 23

What are the typical elements of Conceptual Data Model?

Answer 23

Detailed conceptual data models contain numerous model elements, and, as a result, they are often quite large and complex. While potentially confusing, they also allow you to focus selectively on key relevant areas.
The categorization of model elements can make data models easier to handle in a more selective way. The elements of a conceptual data model can generally be classified into one of the following three categories:
1. Entities
2. Values
3. Services

Question 24

What are Entities in Conceptual Data Models?

Answer 24

Entities are elements of a data model that have a conceptual identity. Entities are often subject to a lifecycle that can be described with a state diagram. An entity’s characteristics change over the course of its lifecycle. An application for insurance is one example of an entity. It is subject to its own lifecycle, during the course of which it evolves from an application to a policy. At the same time, the quantity and nature of the business object’s relevant attributes also change. Giving entities a conceptual identity can be helpful for tracking them throughout their entire lifecycle. A comparatively long lifespan is also a typical property of entities. Historization (record of all
changes implemented) and traceability are among the requirements typically placed on entities, enabling every previous state of an object to be reconstructed.
When preparing a data model, be sure to assign a conceptual ID attribute to each entity. Keep the number of attributes modeled on an entity to a minimum. Any information not required for key functions can be outsourced into value objects. In the class diagram, add
the stereotype «entity» to denote a class as an entity. The previous figure denotes the classes “customer” and “order” together with all items as examples of entities.

Question 24

What are Value Objects in Conceptual Data Models?

Answer 24

Value objects are data objects without their own identity. Only the data stored in these objects are conceptually relevant. They do not have their own lifecycle, nor do they have a conceptual ID attribute. Value objects can be used to store additional information about entities, among other things. Conceptually, value objects are “less interesting” than entities. Unlike entities, value objects can be copied directly without risking conflicts with ID attributes.
A value object is a conceptual grouping element. In other words, modeling should ensure close conceptual links between the attributes in a value object. Multiple value objects may be modeled for a given entity. Value objects are denoted by the stereotype «value object».

Question 25

What are Services in Conceptual Data Models?

Answer 25

Services are stateless functions not directly attributable to entities or value objects, where “stateless” means that the service itself does not have any attributes and hence no inner status. Stateless functions with identical parameters will always deliver the same result. If functions in a conceptual data model are identified that cannot be directly assigned to classes with attributes, these may be modeled as services.
A service is only described by its behavior, as there are no data stored in it. When modeling services, remember to ensure that the parameters and the return value all originate from the set of entities and value objects. In data models, services are denoted with the stereotype «service». By classifying the elements in a conceptual data model into entities, value objects, and services, you can help to keep the data model manageable, while at the same time providing valuable information for the software architect and development team. Depending on the category allocated to a data model class, various draft decisions will be made over the subsequent course of the software project.