<commit_before>+++
date = "2017-04-15T00:26:19+01:00"
title = "7CCSMSIA Software Engineering of Internet Applications notes"
markup = "mmark"
+++

## Lecture 1 - Why bother?

**Specification**: A detailed precise presentation or plan or proposal for something.

**Architecture**: The manner in which components of a computer or computer system are organised and integrated.

**Engineering**: The design and manufacture of complex products.

### Current Situation

We have new complexities:
* Large scale, distributed systems e.g. **Internet-centric computing**.
* Cheap microsystems, therefore a massive distribution. e.g. a car has 100s of microprocessors.
* Internet and web applications.

There is **no** silver bullet and software engineering is less clear cut than theoretical computer science. We use **techniques**, **methods** and **tools**, that can reduce the complexity of constructing systems.

**Software Engineering** is the practical application of scientific methods to the specification, design and implementation of programs and systems. We focus on **Semi-formal methods**.

A language is **formal** when:
 * It has a formal language (syntax)
 * whose meaning (semantics) is described in a mathematically precise way.

A development method is formal when:
 * it is based on a formal language and
 * there are semantically consistent transformation/proof rules.

**UML** is a semi-formal method: Often syntax with a mere hint of semantics.

### Modelling

The goal of development is to solve problems in the **real world**. *Structuring* and *abstraction* are critical as the real world is complex. Models are built in the early development phases with a goal of specifying the requirements and precisely whilst avoiding a premature commitment to algorithms or data-structures.

* **Structuring** serves to organise/decompose the problem/solution.
* **Abstraction** aims to eliminate insignificant details.

Classical approaches to Structuring and abstraction are:
 * **Functional Decomposition**: Decomposition independent tasks.
 * **Parameterisation and generic development**: reusability.
 * **Model simplification**: To improve understanding of tasks and possible solutions.
 * **Information-hiding**: Interfaces and property-oriented descriptions.

**Interfaces** must be clearly described. An **interface** is an imagined or actual border between two functional entities with fixed rules for the transfer of data. They have:
 * **Syntactic properties**: The available rules, the types of their arguments etc.
 * **Semantic properties**: A description of the entities behaviour. The goal is support proper use of the entity.

 Interfaces also provide the basis for communicating and explaining (sub)systems between the specifier, implementer, and user.

---

## Lecture 1B - Model-Driven Development (MDD)

Envisages development of software systems as a process consisting of the **construction and transformation of software models** and **semi-automated generation of executable code from models** rather than focusing on manual construction of low level code.

It aims to make production of software systems more reliable and efficient by freeing developers from complexity of implementation on particular platforms and by retaining core functionality of a system despite changing technologies. This is very relevant for web applications because the technology for them changes often.

### Model Driven Architecture (MDA)

**Model Driven Architecture** aims to support cost-effective adaption of a system to new technologies and environments by separating technology-independent models of data and functionality of a system from technology-specific models.

Key concepts:
 * **Platform-Independent Models (PIMs)**
 * **Platform-Specific Models (PSMs)**
 * **Model Transformations**

 A **Platform Independent Model** can transform into a **Platform Specific Model** which transforms into a language implementation.

 ![alt text](https://docs.google.com/drawings/d/12UTIUZSLnXkHMsk2ypaOCb6kDnRRXy032r2exvdRaCo/pub?w=521&h=256 "MDA Process Example")

A **Platform-Independent Model (PIM)** is a system specification or design model that models a system in terms of domain concepts and implementation-independent constructs. It expresses *business rules* that are the core definition of functionalities of a system. If a PIM is defined in a manner that abstracts from particular algorithms and computation procedures, then it can be referred to as a **Computation Independent Model**.

A **Platform-Specific Model (PSM)** is a system specification or design model of the system tailored to a specific software platform and programming language such and J2EE and Java or C++. It defines the functionalities of a system in sufficient enough detail to be directly programmed from the model.

A **Model Transformation** produces a new model from an existing model. This can be to:
 * improve the quality of the a model by removing redundancies
 * refine a PIM towards a PSM
 * refine a PSM to an implementation

### UML Notation

* **Use Case Diagrams**: Show services used by a system and which users/agents these services interact with.
* **Class Diagrams** and **Object Diagrams**: Describe the structure of entities involved in a system and relationships between these entities.
* **State machine diagrams**: Describe the behaviour of objects and execution steps of individual operations on objects.
* **Object Constraint Language (OCL)**
* **Interactions Diagrams**
* **Activity Diagrams**
* **Deployment Diagrams**

#### Rules

* **Rectangles** denote classes or instances.
* **Ovals** denote functions.
* Names of Classes are **not** underlined.
* Names of instances are underlined.
* An edge between two nodes denotes a relationship between the corresponding entities.


### Use Case Diagrams

**Use Case Diagrams** represent the functionality of the system from a user's point of view.

*NOTE: DIAGRAM (Slide 39 of Lecture1b)*


### Class Diagrams

**Class Diagrams** represent the structure of the system.

*NOTE: DIAGRAM (Slide 40 of Lecture1b)*


### Sequence Diagrams

**Sequence Diagrams** represent the behaviour of a system as messages (interactions) between different objects.

### Statechart Diagrams

**Statechart diagrams** represent the behaviour of a single object with interesting dynamic behaviour.

### Object Constraint Language (OCL)

OCL enables developers to describe properties of classes, associations and state machines in detail using a textual language.<commit_msg>[sia] started use case. Up to lec 1b s54<commit_after>+++
date = "2017-04-15T00:26:19+01:00"
title = "7CCSMSIA Software Engineering of Internet Applications notes"
markup = "mmark"
+++

## Lecture 1 - Why bother?

**Specification**: A detailed precise presentation or plan or proposal for something.

**Architecture**: The manner in which components of a computer or computer system are organised and integrated.

**Engineering**: The design and manufacture of complex products.

### Current Situation

We have new complexities:
* Large scale, distributed systems e.g. **Internet-centric computing**.
* Cheap microsystems, therefore a massive distribution. e.g. a car has 100s of microprocessors.
* Internet and web applications.

There is **no** silver bullet and software engineering is less clear cut than theoretical computer science. We use **techniques**, **methods** and **tools**, that can reduce the complexity of constructing systems.

**Software Engineering** is the practical application of scientific methods to the specification, design and implementation of programs and systems. We focus on **Semi-formal methods**.

A language is **formal** when:
 * It has a formal language (syntax)
 * whose meaning (semantics) is described in a mathematically precise way.

A development method is formal when:
 * it is based on a formal language and
 * there are semantically consistent transformation/proof rules.

**UML** is a semi-formal method: Often syntax with a mere hint of semantics.

### Modelling

The goal of development is to solve problems in the **real world**. *Structuring* and *abstraction* are critical as the real world is complex. Models are built in the early development phases with a goal of specifying the requirements and precisely whilst avoiding a premature commitment to algorithms or data-structures.

* **Structuring** serves to organise/decompose the problem/solution.
* **Abstraction** aims to eliminate insignificant details.

Classical approaches to Structuring and abstraction are:
 * **Functional Decomposition**: Decomposition independent tasks.
 * **Parameterisation and generic development**: reusability.
 * **Model simplification**: To improve understanding of tasks and possible solutions.
 * **Information-hiding**: Interfaces and property-oriented descriptions.

**Interfaces** must be clearly described. An **interface** is an imagined or actual border between two functional entities with fixed rules for the transfer of data. They have:
 * **Syntactic properties**: The available rules, the types of their arguments etc.
 * **Semantic properties**: A description of the entities behaviour. The goal is support proper use of the entity.

 Interfaces also provide the basis for communicating and explaining (sub)systems between the specifier, implementer, and user.

---

## Lecture 1B - Model-Driven Development (MDD)

Envisages development of software systems as a process consisting of the **construction and transformation of software models** and **semi-automated generation of executable code from models** rather than focusing on manual construction of low level code.

It aims to make production of software systems more reliable and efficient by freeing developers from complexity of implementation on particular platforms and by retaining core functionality of a system despite changing technologies. This is very relevant for web applications because the technology for them changes often.

### Model Driven Architecture (MDA)

**Model Driven Architecture** aims to support cost-effective adaption of a system to new technologies and environments by separating technology-independent models of data and functionality of a system from technology-specific models.

Key concepts:
 * **Platform-Independent Models (PIMs)**
 * **Platform-Specific Models (PSMs)**
 * **Model Transformations**

 A **Platform Independent Model** can transform into a **Platform Specific Model** which transforms into a language implementation.

 ![alt text](https://docs.google.com/drawings/d/12UTIUZSLnXkHMsk2ypaOCb6kDnRRXy032r2exvdRaCo/pub?w=521&h=256 "MDA Process Example")

A **Platform-Independent Model (PIM)** is a system specification or design model that models a system in terms of domain concepts and implementation-independent constructs. It expresses *business rules* that are the core definition of functionalities of a system. If a PIM is defined in a manner that abstracts from particular algorithms and computation procedures, then it can be referred to as a **Computation Independent Model**.

A **Platform-Specific Model (PSM)** is a system specification or design model of the system tailored to a specific software platform and programming language such and J2EE and Java or C++. It defines the functionalities of a system in sufficient enough detail to be directly programmed from the model.

A **Model Transformation** produces a new model from an existing model. This can be to:
 * improve the quality of the a model by removing redundancies
 * refine a PIM towards a PSM
 * refine a PSM to an implementation

### UML Notation

* **Use Case Diagrams**: Show services used by a system and which users/agents these services interact with.
* **Class Diagrams** and **Object Diagrams**: Describe the structure of entities involved in a system and relationships between these entities.
* **State machine diagrams**: Describe the behaviour of objects and execution steps of individual operations on objects.
* **Object Constraint Language (OCL)**
* **Interactions Diagrams**
* **Activity Diagrams**
* **Deployment Diagrams**

#### Rules

* **Rectangles** denote classes or instances.
* **Ovals** denote functions.
* Names of Classes are **not** underlined.
* Names of instances are underlined.
* An edge between two nodes denotes a relationship between the corresponding entities.


### Use Case Diagrams

**Use Case Diagrams** represent the functionality of the system from a user's point of view.

*NOTE: DIAGRAM (Slide 39 of Lecture1b)*

**Use cases** are a scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself. That is, a use case is a set of scenarios tied together by a common user goal (which might succeed or fail). A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use cases by showing the sequence of event processing in the system.

* **Actor**: Models an **external entity** which communicates with the system. They have a unique name and an optional description. e.g. `Client`: *A person in the train.*
* **Use Case**: A use case represents a **kind of task** provided by the system as an event flow. A use case consists of:
  * Unique name
  * Participating actors
  * Entry conditions
  * Flow of events
  * Exit conditions
  * Special requirements

Each **Use case** has:
* A **primary actor**, which calls on the system to deliver a service. It is the actor with the goal that the use-case attempts to satisfy, and are usually, but not always the initiator of the use-case. e.g. `Client` is the initiating actor of `Withdraw`.
* A **pre-condition** (or **entry-condition**) that describes what the system should ensure is true before the system allows the use case to begin. e.g. `Withdraw:Client` must have opened a bank account and received a bank card with pin.
* A **guarantee** (or **exit condition**) that describes what the system will ensure at the end of the use case. Success guarantees hold after a successful scenario; minimal guarantees hold after any scenario. *Success guarantees* hold after a successful scenario. *Minimal guarantees* hold after any scenario.
* A **trigger** that specifies the event that gets the use case started.


### Class Diagrams

**Class Diagrams** represent the structure of the system.

*NOTE: DIAGRAM (Slide 40 of Lecture1b)*


### Sequence Diagrams

**Sequence Diagrams** represent the behaviour of a system as messages (interactions) between different objects.

### Statechart Diagrams

**Statechart diagrams** represent the behaviour of a single object with interesting dynamic behaviour.

### Object Constraint Language (OCL)

OCL enables developers to describe properties of classes, associations and state machines in detail using a textual language.
{'fraction_non_alphanumeric': 0.07138523761375126, 'fraction_numerical': 0.006268958543983822, 'mean_word_length': 5.03580146460537, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2022397', 'n_tokens_mistral': 3637, 'n_tokens_neox': 3405, 'n_words': 1979}