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:

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.

Example from SEG-2106 course