msc-computer-science-notes

MSC Software Engineering Lesson Notes

This module is for MSC Software Engineering lessons notes.

Overview

WEEK 1

Main Topics

1) Software Process Models :
waterfall model to incremental, spiral, unified process, prototyping and agile development,

2) Software design models :
Unified Modeling Language (UML)

Sub titles:

What is software engineering?

Software :
The combination og programs and documentation, such as requirement models, design model, test specifications, user manuals, maintenance manual

Software Engineer:
Engineering discipline which is concerns all aspect of a software production (design, analysis, testing, operations and programming ) and aims to develop high-quality of software systematic and organised manner.

The importance of Software Engineering :
According to Sommerville Book (2016 pp.22-23). There are 2 reasons:

1) Individuals and society increasingly rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly 2) It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write programs as a personal programming project. Failure to use software engineering methods leads to higher costs for testing, quality assurance, and long-term maintenance.

Some project activities :
requirements, analysis, feedback, validation, design, implementation, verification, delivery, support

Lifecycle Methods:

Software Processes :
Software processes are to organise the order of the software activities.
From an abstract level :
linear , Iterative , Parallel

</br>alt text

Selecting appropriate life-cycle model

</br>alt text

WaterFall:

Process from - to:

</br>alt text

</br>alt text

Pitfalls:

Waterfall with Iterations:

</br>alt text

Incremental:

</br>alt text

Prototyping:

</br>alt text

Stages required to prepare a prototype are as follows.

Advantages:

Pitfalls:

Iterative and incremental development.

</br>alt text

Spiral:

Boehm’s Spiral model (1988):

Advantages:

Pitfalls:

</br>alt text

Methodological Approaches

Unified Software Development Process

</br>alt text

</br>alt text

Agile Development

Agile:

Plan-driven software development process

Common Characteristics of agile methods

</br>alt text

Essential distinction between plan-driven and agile approaches

Essential distinction to system specifications:

Core values for agile development

</br>alt text

Agile development techniques

Extreme Programming (XP)

User Stories:

Design

</br>alt text

Refactoring

Test-First Development

Pair Programming

Agile Project Management

Scrum :

Scrum Roles:
</br>alt text

Practical problems with agile methods

Software Models in UML

Introduction to Unified Modeling Language (UML)

Use Case Diagram

</br>alt text

Class Diagram

</br>alt text

Instance Diagram

</br>alt text

Sequence Diagram

</br>alt text

Activity Diagram

</br>alt text

Questions:

</br>alt text

Sources

WEEK 2

Main Topics

1) Apply appropriate requirement elicitation techniques :
* Typically, examining the aim, strengths, weaknesses and applicable situations for background reading, interviews, questionnaires, observation and document sampling * Exploring in depth the guidelines for conducting a good interview and constructing good questionnaires. 2) Create a use case model :
* Looking into the concept of use cases and use case diagram notations, paying particular attention to use case relation and actor-generalisation relationships * Exploring use case descriptions in both general and step-by-step form with prototype support.

Sub titles:

Requirement capture

Introduction

User Requirements

Current System

New Requirements

Functional Requirements

Non-Functional Requirements

Usability Requirements

Fact-Finding Technics

Background reading

Interviewing

Observation

Document sampling

Questionnaires

</br>alt text

Other techniques

Inspection List

User Involvement

</br>alt text

Documentation Requirement

Use case model

</br>alt text

Notation

</br>alt text

Systems

Actor

Use Case

Relationships

Association :

Include :

</br>alt text

Extend :

</br>alt text

</br>alt text

Example:
</br>alt text

Generalization & Specialization :

</br>alt text

Supporting use cases with prototyping

</br>alt text

CASE tool support

Business modelling with use case diagrams

</br>alt text

Testing and use cases

Requirements Capture and Modelling

</br>alt text

Capturing use case diagram:

</br>alt text

Summary:

</br>alt text
</br>alt text

Questions:

SOURCE

WEEK 3

Main Topics

1) Conduction requirement analysis and creating an analysis class model
2) Conducting interaction modelling and creating communication diagrams

Relevant module learning :

Sub titles:

Requirement analysis and class diagram

Analysis model

Why requirement analysis?

Major analysis activities

</br>alt text

Class diagram: concept and notations

</br>alt text

Analysis Class Diagram: Concepts and Notation

Classes and objects

Class

</br>alt text

Object

</br>alt text

Attributes

</br>alt text

Associations between classes

</br>alt text
</br>alt text

Multiplicity

Operations

</br>alt text

Object State

Stability of the analysis class diagram

Refining the Requirements Model

Finding and modelling generalization

</br>alt text
</br>alt text
</br>alt text
</br>alt text

Finding and modelling composition (Aggregation, composition)

</br>alt text
</br>alt text

Class modelling

Class Stereotypes

Boundry classes

Entity classes

</br>alt text

Control classes

</br>alt text

Guidelines for Identifying Classes

From Use Case to Class Diagram

</br>alt text

Interaction modelling

Class Responsibility Collaboration Cards (CRC)

</br>alt text
</br>alt text

Sequence diagram notations

</br>alt text
</br>alt text
</br>alt text
</br>alt text

Questions:

</br>alt text

Sources

UML Cheatsheat
UML Cheatsheat 2
UML Cheatsheat 3
Association vs. Dependency vs. Aggregation vs. Composition

VP Class diagram VP Sequence Diagram

WEEK 4

Main Topics

1) Specify constraints and operations for a class diagram using OCL
2) Model state related behaviour using state machines

Relevant module learning outcomes for this week:

Title

Sub titles:

Operation specification

alt text

Describing Operation Logic

Non-algorithmic approaches (declarative):

alt text

Algorithmic approaches (procedural)

Object constraint language (OCL)

OCL keywords:

OCL Data types

OCL arithmetic operators

OCL comparison operators

String operation

OCL Set operators

OCL type operators

Properties on a class diagram

Notation for collection feature call

context
Person
inv:
    self.employer->size() < 3

Comment notation

Logic

alt text

alt text

Examples

// -- Invariants
context Company
inv: self.numberOfEmployees > 50

context c:Company
inv: c.numberOfEmployees > 50

context c:Company
inv enoughEmployees: // -- named invariant
    c.numberOfEmployees > 50

// -- Pre and Post conditions
context Person::income(d:Date):Integer
post: result = 5000

context Person::income(d:Date):Integer
pre: d > 2000
post: result = 5000

context Person::income(d:Date): Integer // -- with optional condition names
pre: parameterOK: d > 2000
post: resultOK: result = 5000

// -- Let Expression :The let expression allows one to define a variable which can be used in the constraint.

context Person
inv: let income: Integer = self.job.salary->sum() in
    if isUnemployed then
        income < 100
    else
        income >= 100
    endif

// Combine Props
// [1] Married people are of age >= 18
context Person
inv:
    self.wife-> notEmpty() implies self.wife.age >= 18 and 
    self.husband->notEmpty() implies self.husband.age >= 18

// [2] a company has at most 50 employees
context Company
inv:
    self.employee->size() <= 50

alt text

Pre- Post constraints

alt text

Properties: AssociationEnds and Navigation

context
Company
inv: self.manager.isUnemployed = false // -- self.manager is a Person, because the multiplicity of the association is one
inv: self.employee->notEmpty()  // -- is a set

Iterate Operation

collection->collect(x:T | x.property)
// -- is identical to:
collection->iterate(x:T ;acc : T2 = Bag{} | acc->including(x.property))


self.employé->select(age > 50)
self.employé->select(p | p.age > 50)
self.employé->select(p:Personne | p.age > 50)
self.enfants->forall(age < 10)
self.enfants->exists(sexe = Sexe::Masculin)


// The complete select syntax now looks like one of:
    collection->select(v:Type | boolean - expression -with-v) 
    collection->select(v | boolean - expression -with-v)
    collection->select(boolean - expression)

alt text

// A vehicle owner must be at least 18 years old
context Vehicle
inv: self.owner.age >=18

// A car owner must be at least 18 years old
context Car
inv: self.owner.age >=18

// Nobody has more than 3 vehicles
context Person
inv: self.fleet -> size() <=3

// All cars of a person are black
context Person
inv: self.fleet -> forAll(v | v.colour = #black)

// Nobody has more than 3 black vehicles
context Person
inv: self.fleet- select(v | v.colour= #black)-> size()<=3

context Person
inv: self.fleet–>iterate(v; acc:Integer=0
    | if (v.colour=#black)
    then acc + 1 else acc endif) <=3

// A person younger than 18 owns no cars.”
context Person
inv: age<18 implies self.fleet–>forAll(v | not v.oclIsKindOf(Car))

// These is a red car
context Car
inv: Car.allInstances()->exists(c | c.colour=#red)

// Apply operations
// “If setAge(. . . ) is called with a non-negative argument then the argument becomes the new value of the attribute age
context Person::setAge(newAge:int)
pre: newAge >= 0
post: self.age = newAge

// Calling birthday() increments the age of a person by 1.
context Person::birthday()
post: self.age = self.age@pre + 1

// Calling getName() delivers the value of the attribute name.
context Person::getName()
post: result = name

Bank Account

alt text

// CUSTOMER
context Customer
//--Test comparison operator
inv: (firstName<>lastName) <>  (firstName=lastName)

//--oclIsTypeOf
inv: self.oclIsTypeOf(Customer)

//-- Navigation result is a collection
inv: self.heldAccount->size()<=5

//-- Query operation
inv: self.getAge()>=18

//--Query operation with brackets omittted
inv: self.getAge>=18

//--Customer should have at least one account with balance more than 200
inv: self.heldAccount -> select (balanceEnquiry()>200) ->notEmpty or
self.heldAccount -> exists (balanceEnquiry()>200)

//--Customer should have all accounts with balance more than 200
inv: self.heldAccount -> forAll (balanceEnquiry()>200)

//-- A customer can have no more than 5 accounts
//-- Navigation result is a collection
inv: self.heldAccount->size()<=5

/* Customer must be no less than 18 years old*/
inv: age>=18

inv: self.age>=18

//-- The sum of a Customer balance for all accounts should be no less than 10
inv: self.heldAccount->collect(balanceEnquiry())->sum>=10

/* Customer must be no less than 18 years old*/
inv: age>=18
inv: self.heldAccount->collect(balanceEnquiry())->sum>=1000

context Customer::addAccount(account:Account)
// --the person shouldn't already own the account
pre: not heldAccount->includes(account)
//--the acount is owned by the new customer and account is added to the customer
post:(account.holder = self) and
heldAccount = heldAccount@pre->including(account)

// ACCOUNT
context Account
//-- An account can only have one holder
inv zero: self.holder->size = 1

//-- overdraft limit may not exeed
inv one: 	self.balance >= -self.odLimit

//-- customer under 18 years of age are not allowed overdrafts
//-- Navigation result is a query operation
inv two: 	self.holder.getAge()<= 18 implies self.odLimit =0

//--overdrafts are not allowed on deposit accounts
inv three: 	self.accountType = #deposit implies self.odLimit =0 or
self.accountType=AccountType::deposit implies self.odLimit=0


context Account::deposit(depType: DepositType, amount:Integer)
//-- zero deposits are not allowed
//-- the deposit must be applied to the right account
pre:	amount>0 and accessor = holder
// --if the amount deposited is in cash,
// --if is added to the balance; if it is a cheque, it is added to the uncleared amount
post:	(depType=#cash implies self.balance = balance@pre + amount) or
(depType=#cheque implies self.uncleared = uncleared@pre + amount)


context Account::withdraw(amount:Integer)
//--zero withdrawals are not allowed
//--the transaction must not result in the overdraft limit being exceeded
//--the person making the withdrawal must be the account holder
pre:amount>0 and
balance-amount>= -odLimit and
accessor = holder
//--the balance is reduced by the amount withdrawn
post:balance = balance@pre-amount


context Account::balanceEnquiry():Integer
//--balance details may only be given to the holder of the account
pre: accessor = holder
//--the balance is returned
post: result = balance


context Account::availableFunds():Integer
//--details of funds available may only be given to the holder of the account
pre: accessor = holder
//--the available fund are calculated from the current balance and the customer's overdraft limit
post: result = balance + odLimit


context Account::clear(amount:Integer)
//--you cannot clear more than the cleared amount
pre: uncleared>=amount
//--the cleared amount is subtracted from the uncleared amount
//--the balance is increased by the cleared amount
post: (uncleared = uncleared@pre + amount) and
(balance = balance@pre + amount)

Campaign


context Campaign
inv: self.estimatedCost=self.advert.getEstimatedCost()->sum() *(1 + ohRate)

context Campaign::upDateEstimatedCost()
post:
if self.estimatedCost > estimatedCost@pre and
    self.estimatedCost>budget and
    self.estimatedCost<= budget*1.02
then self.clientLetterRequired= 'true'
else self.clientLetterRequired = 'false'
endif

context Campaign::checkCampaignBudget():Real
pre: self<> 'null'
post: result=self.budget-self.estimatedCost and
self.estimatedCost=self.advert.getEstimatedCost()->sum()


context CreativeStaff::changeGrade(grade:Grade, gradeChangeDate:Date)
pre: grade.oclIsTypeOf(Grade)and
gradeChangeDate.isNotEarlierThan(today)
post: self.staffGrade->notEmpty and
self.staffGrade.previous->notEmpty and
self.staffGrade.getGradeStartDate()=gradeChangeDate and
self.staffGrade.previous.getGradeFinishDate()=gradeChangeDate.minus(1)

Person

context Person
inv: self.gender=Gender::male or self.gender=Gender::female
inv: self.savings>=500
inv: self.husband->notEmpty() implies self.husband.gender=Gender::male
context Company
inv: self.CEO->size()<=1
inv: self.employee->select(self.employee.getAge<60)->size()<100N

Crate

context Crate
// -- the number of bottles may not exceed its capacity
inv: bottles->size()<=capacity
// --each bottle must fit in the crate
inv: bottles->forAll (b|b.getDiameter<self.maxDiameter)
// -- the total weight must be less than the maximum
inv: totalWeight() <= maxWeight
// -- totalWeight() is derived
inv: totalWeight() = self.bottles.totalWeight()->sum() + self.weight

context Crate::addBottle( b : Bottle )
// -- there must be room in the crate
pre: bottles->size() < capacity
// -- the maximum weight for the crate may not be exceeded
pre: totalWeight() + b.totalWeight() <= maxWeight
// -- the bottle is not yet in the crate
pre: bottles->excludes(b)
// --the bottle is added successfully>br/>  
post: bottles = bottles@pre->including(b)

alt text

// There are two pre-requisites for a GPModule team: the number of members on a team should be no more than maxNumber and a team ID should contain no more than 10 characters.
context Team 
inv f1: member->size()<=maxNumber
inv f2: teamID.size()<=10

// The operation addMember is used to allocate a member to a team. It has two pre-requisites that the member does not belong to any team and the team cannot exceed a maximum number limit by adding the member. It has one post-requisite that the member is successfully allocated to the team.
context Team::addMember(m:Member)
pre: m.team->size()=0 and
     member->size()<maxNumber
post: member->includes(m)

// The operation deregisterStudent is used to deregister a student when a student quits a module. It has one pre-requisite that the student must be one of the students who is registered to the module. It has two post-requisites that the student is not registered with the module and the student is removed from his/her team.
context GPModule::deregisterStudent(s:Member)
pre:student->includes(s)
post:student->excludes(s) and s.team->size()=0

Exam Questions

2018

alt text

// 1 [8 marks] There are two pre-requisites for a mortgage: 
// i) the age of the borrower must be no less than 18 and no more than 65 years old and 
// ii) the borrower of a mortgage on a house must be the owner of the house.
context Mortgage
inv f1: self.borrower.getAge()>=18 and  self.borrower.getAge()<=65
inv f2: self.borrower = self.house.owner

//2. [12 marks] The operation getMortgage is used to access a mortgage for a borrower. 
// It has two pre-requisites: i) a minimum deposit of 5% of the house’s value is needed for a mortgage and 
// ii) by receiving the mortgage the total amount of the borrower’s mortgage will not exceed five times of his/her salary. It has one post-requisite that the mortgage is successfully granted to the applicant.
context Person::getMorgage(m: Morgage,d: deposit)
pre: self.home.getPrice() * 0.05 <= d and
    self.morgage.getAmount()->sum() + m.getAmount() < self.salary * 5
post: self.morgage->includes(m)

//3. [10 marks] The operation sellHouse is used for a house owner to sell his house. It has
// one pre-requisite that the house in question belongs to the owner. It has two post-
// requisites: i) the house is successfully sold and ii) the mortgage for the house is removed from the house owner.
context Person::sellHouse(h: House)
pre: self.house->includes(h)
post: self.house->excludes(h) and
    self.morgage.house->excludes(h)

2017

alt text

// 1. [8 marks] There are two pre-requisites for a module: the moduleID should contain exactly four characters and the number of students on each module must be at least 10.
context Module
inv f1: self.moduleId.size()=4
inv f2: self.student->size()>=10


// [12 marks] The operation registerModule is used to register a student to a module. It has two pre-requisites: that the student must not already be registered to that module; and the student has paid for the fees. It has one post-requisite: that the student is successfully registered.
context Student::registerModul(mod : Module)
pre: self.module->excludes(mod) and
    self.feesPaid=true
post: self.module->includes(mod)

//  [10 marks] The operation passModule is used to update student credits earned when they pass 	a module. It has one pre-requisite: that the module must be one of the modules the student has been registered to. It has one post-requisite: that the creditsEarned now held in the object Student must be equal to the previous credit with the credit of this module added into the total.
context Student::passModule(mod: Module)
pre: self.module->includes(mod)
pro: self.creditEarned= self.creaditEarn@pre + mod.getCredit()

State Machines

alt text

State Modelling

Notation

alt text
alt text

alt text

alt text

alt text

Preparing a State Machine

A behavioural approach

A lifecycle approach

Questions for State Machine

* 1. What is the difference between a call trigger and a signal trigger?

* A call trigger is a normal message, a signal trigger is an asynchronous message *
2. What does an action start with?

* / *
3. When there is more than one action, what are the actions separated by?

* ; *
4. Does internal transition cause state change?

* No *
5. Does internal transition invoke exit and entry activity?

* No *
6. For a state with internal activities, any transition into the state causes which activity to fine?

* Entry *
7. For a state with internal activities, any transition out of the state causes which activity to fine?

* Exit * All of them correct !
* A transition to a state with concurrent substates means simultaneously entering the concurrent substates.
* A transition out of a composite state applies to all its substates (no matter how deeply nested).
* The use of the join pseudostate means that the composite state is not exited until both concurrent nested state
  machines are exited.

Activity

alt text
alt text

Summary

Examples

Sources

OCLE
Ocla Specofocation OMG
Introduction to OCLA
OCL Cheat Sheet

State Machine Diagram Tutorial

WEEK 5

Main Topics

1) Assess software architecture patterns and applicable situations
2) Produce a design class model
3) Apply design pattern to teh class design

Relevant module learning outcomes for this week:

Sub titles:

Intro

</br>alt text

12 Quality Criteria For Good Design

High-level design

</br>alt text

Criteria for package design

Software Architecture Patterns

Closed Architecture

</br>alt text

Open Architecture

</br>alt text

Repository Architecture

Client-server architecture

Peer to peer architecture (P2P)

Broker architecture

</br>alt text

MVC (Model-View-Controller)

</br>alt text

10 Common architecture

</br>alt text

Low-level design

Criteria for good class design

</br>alt text

</br>alt text
</br>alt text
</br>alt text

Attributes and operation specification

</br>alt text
</br>alt text

Designing associations and constraints

</br>alt text

Constraints Design

Software design patterns

</br>alt text

GOF Design Patterns (Gang of four)

Creational Pattern

Singleton

</br>alt text
</br>alt text

Structural Pattern

Composite Pattern

</br>alt text
</br>alt text

Behavioral Pattern

Strategy Pattern

</br>alt text

Observer Pattern

</br>alt text

Questions

Design Patterns Composite pattern

TODO:

WEEK 6

Main Topics

Relevant Module Learning Outcomes

Sub titles:

Specification-based testing

</br>alt text

Five Level Testing

Unit Testing

Integration Testing

</br>alt text

* bottom-up
    * starts at lowest level (units) and progressively combines into larger subsystems until final system is reached
    * Integration of lower level elements requires a driver.
    * It is good that bottom up testing allows parallel testing
    * But environment of testing is not actual execution environment, control problems or fundamental architectural
      problems may not surface until very late.

</br>alt text

* big-bang approach
    * All the method links, edits, compiles and runs all the modules together.
    * Often reveals some errors
    * May possibly be used to create a backbone network, which can subsequently act as a test harness.
    * it is only interesting for small to moderate size projects.

</br>alt text

Subsystem testing

System testing

Regression Testing

User Acceptance Testing

3 Level Testing

Test Planning

Specification-based testing (Black box testing)

</br>alt text

Structural testing (White Box Testing)

Control Flow Graph

</br>alt text

Statement and Branch coverage

</br>alt text

</br>alt text

Task

 int ABS(int x)
        {
        if(x< 0)
        x=-x;
        return x;
        }

</br>alt text

Conditional coverage

</br>alt text

Activity

White and Black test is used for

JUnit and refactoring

Unit testing

@Before public void setup(){...}
@After public void teardown(){...}

@BeforeClass public static void setUpBeforeClass(){...}
@AfterClass public static void tearDownAfterClass(){...}

Refactoring

Cyclomatic complexity

Source

TODO:

WEEK 7

Main topics

Relevant Module Learning Outcomes for this week:

Sub Titles

Quality management

Intro

Quality Plan

Software Quality

Software Standards

</br>alt text

Reviews and inspections

The review process

</br>alt text

Program inspections

Configuration management

</br>alt text

Version Managment

</br>alt text

System building

</br>alt text

</br>alt text

</br>alt text

Change management

</br>alt text

Questions

What makes a good Quality Assurance Manager?

Top 10 Characteristics of Quality Managers

Activity-Software Inspection