Catálogo de publicaciones - libros

In the preceding chapters of this book, we studied the structural part of a conceptual schema, that is, the structural schema. In this chapter, we start the study of the behavioral part, called the behavioral schema.

In the preceding chapter we studied the concept of a domain event and how to specify domain event types. We now study the events that request the information system to perform an action. The nature of these events is quite distinct from that of domain events, but they are modeled in a similar way.

In the two preceding chapters, we studied how to define the effect of events by means of () operations. An alternative, or complementary, way is the use of state transition diagrams. This is the main topic of this chapter. We start in Sect. 13.1 with a brief review of finite state machines and their associated state transition diagrams. We then explain, in Sect. 13.2, how entities can be modeled as state machines, and that in this case state transition diagrams are part of the behavioral schema. Sections 13.3 to 13.5 describe how state transition diagrams can be defined in UML.

In this chapter, we study statecharts. Statecharts are an extension of the state transition diagrams that we studied in the previous chapter. Statecharts can be defined in UML. The main extensions provided by statecharts are state hierarchies and parallelism. These are presented in Sects. 14.1 and 14.2, respectively.

We know that a conceptual schema defines the general knowledge required by an information system to perform its functions. But what are the functions of the information system, and what is the knowledge required to perform them? Currently, the answer to these questions is based on the use cases. Use cases define the functionality provided by an information system. The use cases of an information system are determined during requirements elicitation, one of the most important phases of requirements engineering.

In the preceding chapters, we studied the elements from which schemas are made up. We followed a bottom-up approach, starting with the basic elements of entity and relationship types, and then proceeding to more complex elements until we reached the state transition diagrams and statecharts.

One principle of conceptual modeling is that domain objects are instances of entity types. Entity types, however, can also be seen as objects, and so they are also instances of types known as meta entity types. This is the basis of metamodeling, which we discuss in this chapter. Metamodeling is very important in the field of information systems, particularly in conceptual modeling.

Just as a schema is an instance of a metaschema, so is a metaschema an instance of a meta-metaschema. Meta-metamodeling is concerned with the definition and use of meta-metaschemas. The best-known meta-metaschema is the Meta-Object Facility (MOF), which is introduced in Sect. 18.1. Many metaschemas can be defined as an instance of the MOF. However, the MOF can also be used as a conceptual model (that is, a metaschema) for a restricted subset of schemas, as we show in Sect. 18.2.