Software Engineering Principles

Course notes for ELG-7187C - 2013

The software development cycle

Different development activities

David Harel's view into the future :

Notations and tool support for the different SE activities

Defining notations

In many cases, the syntax of the specification language is formally defined, but the semantics is is many cases only defined informally (through some english explanations). Some people consider that such languages are not formal. An example is UML. The OMG documents defining UML (Infrastructure - Superstructure) include for each type of UML diagram (for instance Activity Diagrams), the following definitions:

• The language meta-model (represented in the MOF notation and entitled "Abstract Syntax"). This is so-to-speak the logical syntax defining the concepts in the language, without specifying the form in which the language concepts are represented.
• Then the concrete syntax is defined which explains how these concepts are graphically represented. The abstract syntax plus the concrete syntax, together, represent what I called above "context-free syntax".
• For each concept / language elements (i.e. class in the meta-model), further details are defined, including attributes of these elements (which are important for the semantic definition), constraints (which are the semantic constraints of the syntax mentioned above, they are sometimes described using the formal OCL notation).
• The semantics (meaning) of these language concepts is described informally in the form of english text, which may sometimes be ambiguous. Note also that the designers of UML have purposely introduced so-called "semantic variation points" which are points in the semantic definition where several semantic variants are foreseen. This means that the user of the language must specify which semantic variant is assumed. This difficulty is ignored in most practical applications of UML. Nevertheless, the conscientious user should know which of these variation points should be adopted (by the designer and the supporting CASE tools).

Problem domain analysis

During the requirements analysis phase of the system development cycle, one usually wants to establish a model of the existing system or of the system to be built. How can one approach this model construction process ? - The following methodology is proposed. It should be used with much back-tracking - trial, correction, improvement of the established model.

1. Normally, a textual description of the problem domain and requirements is given in some form. Establish a dictionary of terms, which includes the most important words in the textual description. Each noun indicates an object, or object class that may be important to be represented in the model. These are the so-called "entities" in the entity-relationship modeling approach. Each verb indicates a relationship between objects that may be important to be represented in the model. Distinguish between active objects (so-called actors) and passive objects that have no own initiatives (they are usually "called").
2. Based on the relationships between object classes, identify the interactions between entities. There may be different kinds of interactions identified at an abstract level (see below for more detail): operation (method) calls, rendezvous interactions, and message exchanges.
3. Some of the identified objects may exist in different states, and their dynamic behavior may be different in these different states. Identify these states by constructing a state machine model for these objects. Note that the state transitions (in the state-oriented modeling approach) correspond to transitions between states in the state machine model.
4. One has to distinguish the part of the domain representing the "system to be built" from its environment.

During Requirements Analysis, one finds the existing properties of the problem domain, as well as the requirements that should be satisfied in the domain-to-be. We assume that the domain-to-be will include a new system-to-be-built and other aspects of the domain may also be changed. The determination of this domain-to-be, including the system-to-be) is a typical design process. It is called external design because the system-to-be is considered during this process as a black-box and the external environment of it is designed (in a white-box manner) – the domain-to-be. It is «The invention and definition of the behavior of a new system (solution domain) such that it will produce the required effects in the problem domain ». Note: During this process, the boundary (and interfaces) of the system-to-be will be established

For modeling the domain, one usually uses Entity-Relationship modeling (originally proposed by Peter Chen in 1976), often using the notation of UML Class diagrams.

• Entity: represents a type of entity instances, defines the properties that hold for all such instances.  
• Relationship: represents relationship instances that hold between certain pairs of entity instances.
  • The related entity types are also called roles.
  • Multiplicity information indicate how many instances of the “other” side may be related to a given instance of “this” side.
• Attribute: An entity or a relationship may have one or several attributes. Each attribute is identified by a name and its type, where such a type is usually some simple data type such as integer or character string. Note: An entity type is normally not used as the type of an attribute, because such a situation is rather represented by a relationship between the given entity and the attribute type.