• Ei tuloksia

Data modeling in digital interface design

2.5 Digital interface design and implementation

2.5.1 Data modeling in digital interface design

Data modeling is a key part of design of databases and systems & software involving complex data structures. As such, it is also a key part of modern digital interface design. In fact, a device attached to an interface is often viewed as a data resource which is accessed or presented to the operating system similarly to a remote database or data storage unit. Structured data on the remote devices needs to be accessed effectively, and established data modeling techniques and practices developed for database systems can be applied in the design process of digital interfaces. Traditional data modeling only models data. Although usable, this approach has limitations when modeling devices with functionality or resources for more complex operations.

Modern data modeling approaches use object-oriented modeling techniques, which add behavior modeling alongside data modeling. These object-oriented techniques can therefore be used to model advanced computerized devices with functionality in addition to data resources, which extends their usability in modern interface design.

What is data modeling?

A data model is the main tool for hiding details of data storage and providing data abstraction [Elm94]. Data model defines the format of the data. Most modern data models also include concepts to specify behavior. Consistent use of data models enables data compatibility. A

2.5 Digital interface design and implementation 33

schema is a description of a data model, usually diagrammatic.

Three basic styles of data models can be identified [Elm94, Amb09]:

• Conceptual data models (domain models), explore domain concepts with project’s stake-holders. A conceptual schema describes the semantics of a domain.

• Logical data models (LDMs), explore domain concepts and their relationships. They depict logical entity types, the data attributes describing those entities, and the relation-ships between the entities. A logical schema describes the semantics as represented by the particular technology

• Physical data models (PDMs), used to design the internal schema of a database, depicting the data tables, the data columns of those tables, and the relationships between the tables.

A physical schema described the physical means by which data are stored.

The conceptual data models are high-level data models close to the way many users perceive the data; where as the physical data models are low-level models which describe details of the computer implementation. The logical data models are a class of representational or imple-mentation models, which provide concepts that, can be understood by users but which can be implemented quite directly on computer systems.

There has been some confusion on the use of terms “data model” and “information model”.

The RFC 3444 [Pra03] proposes the following distinction. Information model models managed objects at a conceptual level, independent of any specific implementations or protocols used to transport data. Data models are defined at lower level of abstraction and include many details.

They are intended for implementations and include protocol specific constructs. I.e., multiple data models can be derived from a single information model [Pra03]. Object-oriented techniques, such as UML [Obj09b, Obj09a], are commonly used to describe information models.

Data models define managed objects at a lower level of abstraction. They include imple-mentation and protocol-specific details, e.g., rules that explain how to map managed objects onto lower-level protocol constructs [Pra03]. Languages such as ASN.1 [Int87] have been used to define data models.

Object-oriented data models

Object-oriented data models were proposed for database systems to meet the needs of emerging complex applications and growing data sizes. The object-oriented data modeling approach offers flexibility without being limited by the data types and query languages available in traditional database systems. A key feature of the object-oriented databases is the power they give the designer to specify both the structure of complex objects and the operations that can be applied to these objects. [Elm94]

The concept of encapsulation is one of the main characteristics of object-oriented languages and systems. It is also related to the concepts of abstract data types and of information hiding in programming languages. In traditional databases, it is customary to make the structure of database objects visible to users and external programs. In object-oriented approach, the main idea is to define the behavior of a type of object based on the operations that can be externally applied to objects of that type. The internal structure of the object is hidden, and the object is accessible through a number of predefined operations. The implementation of an operation can be specified in a general-purpose programming language that provides flexibility and power in defining the operations. The external users of the object are only made aware of the interface to the object, which defines the names and arguments of each operation. The implementation of the object is hidden from the external users. In object-oriented terminology the operation implementation in called a method. Typically, a method is invoked by sending a message to the object to execute the corresponding method. [Elm94]

As can be seen from above, the modeling approach is readily and directly applicable to communication interfaces, in which the data is exchanged using messages between the commu-nicating entities. By using methods to update data of the objects instead of direct access to the data the data integrity constraints can be met.

Object-oriented software design

Modern digital interfaces rely heavily on software implemented protocol stacks. The intercon-nected devices and their data structures are often modeled using object-oriented techniques and tools. To understand modern digital interface design, one must also understand the basic concepts of object-oriented software design.

Object-oriented software design is part of an object-oriented development process, which includes:

1. Object-oriented analysis - develop an object-oriented model of the application domain 2. Object-oriented design - develop an object-oriented model of the software system to

im-plement the requirements

3. Object-oriented programming - realize a software design using an object-oriented pro-gramming language. [Som00]

Two types of design models are normally used to describe an object oriented design [Som00].

Static models describe the static structure of the system in terms of the object classes and their relationships. Dynamic models describe the dynamic structure of the system and show the in-teractions between the system objects. The static models are sometimes referred as structural and dynamic as behavioral models, views or diagrams. For digital interfaces, the static models

2.5 Digital interface design and implementation 35

describe how the data is structured in the devices, and the dynamic models describe the in-teractions between the devices over the interface media. To date, UML 2.2 [Obj09b, Obj09a]

supports 14 types of diagrams [Obj09b]. Class, composite structure, component, deployment, ob-ject, package, and profile diagrams are used to describe the static structure. Dynamic operation is modeled using activity, interaction, use case, and state machine diagrams. The interaction diagrams have been further divided into sequence, communication, interaction overview, and timing diagrams, to support different application needs.

Data models in modern digital interface design

Data models are indispensable when designing and documenting complex interface standards.

Modern object-oriented techniques and methodologies can be used as a tool when specifying a new standard, and thus providing a readily implementable specification. For a user of es-tablished standard interfaces, the data structures, information models and supporting device profiles provided by the standard can be used and users modeling needs are reduced. Even then, the data modeling paradigm still exits at higher level of systems development, which is out of the scope of this Thesis. An example of the object-oriented interface design is the ISO/IEEE 11073 standard introduced in Chapter 3, which is based on an object-oriented data (information) model.

Each digital interface has some low-level data schema, even if it lacks a defined data model.

If the data structure and the communication needs of the device are very simple, then a model based design may not offer benefits that outweigh the additional work. In a very resource limited environment, such as a small battery-powered wireless device (including short data payload, infrequent transmissions, power consumed on each transmission), a more engineering view based design approach of looking at the system as a data path/pipe between two entities may result in more optimal performance. Indeed, this engineering approach is often used to produce efficient communication protocols for simple systems with very fixed data properties, usually using point-to-point communication. For example, a small sensory device may broadcast a message once in an hour. This gives the designer a limited number of bytes which he will then try to use as effectively as possible to convey as much information as possible. A packet data structure schema is developed without a true underlying data model. Although very optimal in performance, systems and communication protocols designed in this way are often inflexible and difficult to expand in functionality afterwards.

Benefits of data model based interface data structure design include avoidance of redundant information, flexible design, and that changes to structure are later possible. The drawback of model based design for an interface designer is that some control over resource usage optimization is lost and some extra headers are introduced compared to fixed (inflexible) implementations.

Furthermore, object-oriented models are not as straightforward to implement in a resource limited embedded systems programmed using non-object-oriented languages such as C, than

in a computer system with object-oriented programming language. Embedded systems have limited RAM, and it is easy to overuse it with memory structures required for objects.