程序代写代做代考 scheme Java flex AI concurrency PowerPoint Presentation

PowerPoint Presentation

Lecture 1

Bjørn Sand Jensen

bjorn.jensen@glasgow.ac.uk

(Slides adopted from SE(M) 2016 by Dr Julie Williamson and slides from the OOSE book repository)

Today’s Plan

 10:05-10:55:

 What is software engineering?

 Housekeeping (and how to pass this class)

 Break

 11:05-11:55:

 Software development process

 Requirements (mostly review)

 Long break

 14:05-14:55: Object Orientation – important concepts

(mostly review) [Sir Alexander Stone 208, no lab!]

What is Software Engineering ?

Software Development is Hard

 Software is Intangible

Software Development is Hard

 Software is Complex

Software Development is Hard

 Software Fails

 http://spectrum.ieee.org/computing/software/why-

software-fails

http://spectrum.ieee.org/computing/software/why-software-fails

Software Development is Hard

 Software is Malleable

Characteristics of Good Software

 Easy of use

 Modularity

 Modifiability

 Efficient

 Correct

 Maintainability

 Understandability

 Reusable
 Portable

 Security

 … etc

What is Software Engineering?

 “Software engineering is an engineering discipline that is
concerned with all aspects of software production” (Sommerville)

 “A discipline that deals with the building of software systems which
are so large that they are built by a team or teams of engineers.”
(Ghezzi, Jazayeri, Mandrioli)

 “The application of a systematic, disciplined, quantifiable
approach to the development, operation, maintenance of
software; that is, the application of engineering to software….” IEEE

 “The process of solving customers’ problems by the systematic
development and evolution of large, high-quality software systems
within cost, time and other constraints

Why is Software Engineering

Important?

Software Engineering is Design!

 Very much related to the design of the internal structure

software to meet the external requirements.

 This is the fun aspect of software development !

Course Aims

 To introduce the basic concepts of software engineering

in the small;

 To present methods for the design, implementation,

testing and documentation of object-oriented programs;

 To develop program comprehension and design skills by

studying and extending existing programs.

Intended Learning Outcomes and

Course Objectives

Intended Learning Objectives

 1: Develop clear, concise, and sufficiently formal

documentation of extensions to an existing system, based on

the true needs of users and other stakeholders;

 2: Apply design principles and patterns while designing and

implementing simple systems, based on reusable technology;

 3: Produce documentation appropriate for programs

developed in practical exercises;

 4: Create UML class diagrams which model aspects of the

domain and the software architecture;

 5: Carry out testing of programs and apply simple

measurement techniques to software;

 6: Discuss the breadth of software engineering practices.

Topic Who Assigned

Reading
(OOSE, unless

otherwise

indicated)

Morning

Session

10:00-12:00

MB420

Afternoon Session

14:00-15:00

BO1028, if not

otherwise indicated

Assessed

coursework

W17 8/1 Introduction and

review

BSJ Ch 1+2

(review Ch

4)

Lec 1.1 Lec 1.2 (in SAS208)

Lab 1: Review

Eclipse (review

outside of class)

(PI1/Q1, not

assessed; demo

only)

W18 15/1 Modelling and

UML

BSJ Ch 5

Lec 2 Lab 2: Design using

UML

PI2/Q2

19/1 AE1 Handout

W19 22/1 Design Patterns KY Ch 6

Lec 3 Lab 2: Patterns PI3/Q3

W20 29/1 Design Patterns BSJ Ch 6 Lec 4 Lab 3: Patterns PI4/Q4

W21 5/2 Design

Principles and

Architecture

BSJ Ch 9 Lec 5 Lab 4: Design

Principles

PI5/Q5

W22 12/2 Design

Principles and

Architecture

(incl.

documentation)

BSJ Ch 9

Lec 6 Lab 5: Design

Principles and

Documentation

PI6/Q6

16/2 AE1 Deadline &

AE2 Handout

W23 19/2 Testing KY Ch 10 Lec 7 Lab 6: Test PI7/Q7

W24 26/2 Testing KY Ch 10

+TBD

Lec 8 Lab 7: Test PI8/Q8

W25 5/3 Continuous

Integration

KY Lec 9 Lab 8: Continuous

integeration

PI9/Q9

W26 12/3 Revision KY

(BSJ)

Revision Lec 10 Lab revision PI10/Q10

16/3 AE2 Deadline

Course Details

 The syllabus is available on Moodle

 http://moodle2.gla.ac.uk/course/view.php?id=2780

http://moodle2.gla.ac.uk/course/view.php?id=2780

Primary Textbook & Videos

 Object Oriented Software Engineering – Lethbridge and
Laganiere (available as FREE e-book)

 http://www.site.uottawa.ca/school/research/lloseng/

 Classical one-way lectures available from:

 http://www.site.uottawa.ca/school/research/lloseng/suppor
tMaterial/videos/

 Note: Our aim is not to repeat the recorded lectures but to
get you involved and help you to reflect on the material
during lectures.

http://www.site.uottawa.ca/school/research/lloseng/
http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/videos/

Venues

 Lectures (w/quizzes and exercises):

 Week 1-10: Monday 10:00-12:00 Main Building 420

 Week 1 : Monday 13:00-14:00 Sir Alexander Stone 208

 Labs

 Week 2 onwards:

 Monday 13:00-14:00 Boyd Orr Building 1028

OR

 Monday 14:00-15:00 Boyd Orr Building 1028

Lab Scheduling

Monday 13:00-14:00 Boyd Orr Building 1028

OR

Monday 14:00-15:00 Boyd Orr Building 1028

?

Please indicate your preference via Moodle:

http://moodle2.gla.ac.uk/mod/choice/view.php?id=819064

http://moodle2.gla.ac.uk/mod/choice/view.php?id=819064

Who are we?

 Lecturer: Bjørn Sand Jensen (aka Bjørn / Bjorn)

 Office: SAWB 306

 Email: Bjorn.Jensen@glasgow.ac.uk

 Lecturer: Ke Yuan

 Office: SAWB 205

 Email: Ke.Yuan@glasgow.ac.uk

mailto:Bjorn.Jensen@Glasgow.ac.uk
mailto:Ke.Yuan@glasgow.ac.uk

 What we (also) spend our time on…

 Research, rarely on SE aspects per say.

 We are both Machine Learning researchers. We do Machine

Learning, AI and Signal/Image Processing in biology, cancer,

audio, images, text, human behaviour….

 We regularly reuse, extent, develop and apply scientific

software

 My personal experience with software engineering…

Who are we?

Who are you?

Course assessment

 Exam, 70%

 Course-work, 30%

Coursework

 30% of your total mark

 We expect well written well presented work.

 Coursework must have a cover sheet

 Hand in times are at 4:30 on the due date

 No questions will be accepted two days before
assignments are due

Peer Instruction and Quizzes

 10% of your total grade will be based on your participation
in peer instruction activities. This will include:

 Quizzes during lectures to review reading. You will receive 1

point for every correct answer you provide.

 Problem Solving during lectures to break down course material.

You will receive 1 point for every answer (correct or incorrect)

you provide.

 In order to receive full marks for this assessment, you need

only to complete 90% of the total possible points.

 http://learn.gla.ac.uk/yacrs/index.php

http://learn.gla.ac.uk/yacrs/index.php

How does this class work?

 This class is designed a bit differently from what you might

normally be used to

 “Lecture” will be focused around YOU

 What YOU understand

 A “clicker” is required for this class

 It’s not optional, using it will be 10% of your grade

 In this class, your “clicker” will be the YACRS system

 So, lecture will be different

 Ever thought about why we have “lecture”?

Peer Instruction-Based Design

 Greater opportunity for feedback!

 Research on how people learn:

 Everyone constructs their own understanding

 We can’t dump understanding into your brain

 To learn YOU must actively work with a problem and construct

your own understanding of it

Homework Lecture Lab Exam

Show Knowledge
Mastery

First Exposure:
With resources and

Feedback

Learn Hard Stuff:
With teacher and

discussion

Practice
Knowledge

Mastery

Q

U

I

Z

Peer Instruction

 Are you prepared? (quick quiz at beginning of class, using

YACRS)

 Pose carefully designed question

 Solo vote: Think for yourself and select answer

 Discuss: Analyze problem in teams (but vote independently)

 Practice analyzing, talking about challenging concepts

 Reach consensus

 If you have questions, raise your hand

 Group vote: Everyone in group votes

 Class wide discussion:

 Led by YOU (students) – tell us what you talked about in

discussion that everyone should know!

Q1.1: Animal preference

 Go to YACRS now:

 https//classresponse.gla.ac.uk

 Join Session 1123

https://classresponse.gla.ac.uk/

Q1.1: Animal preference

I am a:

 A: Cat Person

 B: Dog Person

 C: I don’t like cats or dogs

Q1.1: Animal preference

(solution)

I am a:

 A: Cat Person

 B: Dog Person

 C: I don’t like cats nor dogs

I definitely prefer dogs!

PI 1.1 Software aspects

[group vote]

 Go to YACRS now:

 https//classresponse.gla.ac.uk

 Join Session 1124

https://classresponse.gla.ac.uk/

PI 1.1: Software aspects

[solo vote]

Consider on you own, which aspect of quality is most

important in developing a software system for handling

medical records in a hospital

 A. Easy of use

 B. Modularity

 C. Modifiability

 D. Efficient

 E. Correct
 F. Maintainability

 G. Understandability

 H. Reusable

 I. Portable

PI 1.2: Software aspects

[group vote]

Consider in groups of 3-4 next to you, which aspect of

quality is most important in developing a software system for

handling medical records in a hospital

 A. Easy of use

 B. Modularity

 C. Modifiability

 D. Efficient

 E. Correct
 F. Maintainability

 G. Understandability

 H. Reusable

 I. Portable

PI 1.1-2: Team Challenge

(solution)

 What did you discuss ? Anything missing ?

Assignment 1

 Modelling and Design using UML (10% of your total

grade)

 Full details available on Moodle 19/1 2018

 Due 16/2 2018 at 4:30 on Moodle

Assignment 2

 Software testing (incl design for testing) (10% of your total

grade)

 Full details available on Moodle 16/2 2018

 Due 16/3 2018 at 4:30 PM on Moodle

Academic Honesty

 The School has clear policies for academic honesty, if

you’ve forgotten this, it is available on Moodle

 This course depends on discussion and creativity, so

collaboration is encouraged, but assignments must be

completed individually

 It is your responsibility to be familiar with the policy, but if

you are unsure email me

Marking

 All marking schemes will be provided when assignments

are announced

 No remarking is allowed except in cases of administrative

error.

How to Pass this Class

 Do the readings before coming to the lectures (and
perhaps watch the classic one-way lectures on videos)

 Attend the lecture sessions (and be active)

 Attend the labs

 Work Hard

 Ask questions

You are very unlikely to pass this course by reading the slides
alone !

Questions?

Comments?

Concerns?

Break (~10 min)

Software Engineering cont.

A Generic Software Project

 Requirements Gathering & Specification

 Design & Modelling

 Construction/implementation (i.e. programming)

 Quality Assurance (i.e. testing)

 Deployment

 Maintenance & Support

 Project Management (planning, resource allocation,

development process, risk estimation/mitigation, cost estimation

etc)

Common Activities During Software

Projects

 Requirements Specification

 Domain Analysis

 Defining the Problem

 Requirements Gathering

 Requirements Analysis

 Requirements Specification

 Covered in Software Project Management course (?)

Common Activities During Software

Projects

 Design

 How should the software be divided into subsystems?

 How should each subsystem be organised?

 How should users interact with the system?

 How should the underlying data be organised and stored?

Common Activities During Software

Projects

 Modeling

 Use case modeling

 Structural modeling

 Dynamic and behavioural modeling

Common Activities During Software

Projects

 Programming

 What are the best ways to implement high level designs?

 Project management: How should teams be organized and

managed to successfully create the software ?

Common Activities During Software

Projects

 Quality Assurance

 Design (& program ) for testability

 Reviews and Inspections

 Testing

Common Activities During Software

Projects

 Deployment, Maintenance & Support

 Release management

 User documentation

 Customer support

 Updates

Common Activities During Software

Projects

 Management

 Resource allocation

 Cost estimation (based on input from REs)

 Development models

 Risk estimation

 Customer relations

 … etc

Requirements

PI 1.3-4: Review requirements

 Go to YACRS now:

 https//classresponse.gla.ac.uk

 Join Session 1125

https://classresponse.gla.ac.uk/

PI 1.3: Stakeholders

[solo vote]

All software engineering projects will have stakeholders. The

different stakeholders of a software engineering project will:

 A – all participate in the development of the software

 B – have different priorities and needs for the software

 C – be interested in the development of the software

 D – carry stakes to destroy the software

PI 1.3: Stakeholders (solution)

Stakeholders often have different and sometimes

competing needs. For example, consider how the following

stakeholders may have different requirements and priorities

for a software system:

 Users

 Customers

 Developers

 Managers

PI 1.4 – Requirements

[group vote]

The requirements stage is used to understand the customers

needs. The requirements specification must primarily

describe:

 A: The cost of the system

 B: What the system will do

 C: How the system will be implemented

 D: Who will develop the system

PI 1.4 Requirements (solution)

 The requirements specification must describe what the

system will do. Other constraints should only be included

if it is unavoidable.

 i.e. B: What the system will do

Requirement Specification

 It is a statement describing either

 1) an aspect of what the proposed system must do,

 or 2) a constraint on the system’s development.

 In either case it must contribute in some way towards

adequately solving the customer’s problem;

 the set of requirements as a whole represents a negotiated

agreement among the stakeholders.

 A collection of requirements is a requirements document.

Types of requirements

 Functional requirements

 Describe what the system should do

 Quality requirements

 Constraints on the design to meet specified levels of quality

 Platform requirements

 Constraints on the environment and technology of the
system

 Process requirements

 Constraints on the project plan and development methods

Use cases (& scenarios)

 A use case is a typical sequence of actions that a user
performs in order to complete a given task

 The objective of use case analysis is to model the system from
the point of view of

… how users interact with this system

… when trying to achieve their objectives.

It is one of the key activities in requirements analysis

 A use case model consists of

 a set of use cases

 an optional description or diagram indicating how they
are related

Use case description

• A. Name/id: Give a short, descriptive name to the use case.

• B. Actors: List the actors who can perform this use case.

• C. Goals: Explain what the actor or actors are trying to

achieve.

• D. Preconditions: State of the system before the use case.

• E. Summary: Give a short informal description.

• F. Related use cases.

• G. Steps: Describe each step using a 2-column format.

• H. Postconditions: State of the system in following
completion.

Use case diagrams (modelling)

Image: Courtesy of OOSE 2ed

Use case diagrams (modelling)

Image: Courtesy of OOSE 2ed

Requirement document

1. Problem

2. Background information

3. Environment and system models

4. Functional Requirements

5. Non-functional requirements

Issues with requirements

 Lack of understanding of the domain or the real problem
 Do domain analysis and prototyping

 Requirements change rapidly
 Perform incremental development, build flexibility into the

design, do regular reviews
 Attempting to do too much

 Document the problem boundaries at an early stage,
carefully estimate the time

 It may be hard to reconcile conflicting sets of requirements
 Brainstorming, group sessions, competing prototypes

 It is hard to state requirements precisely
 Break requirements down into simple sentences and review

them carefully, look for potential ambiguity, make early
prototypes

SE (M) 2017-2018

 The focus of this course is to outline principles for how to

take a requirements document and come up with a

“good” design which when once implemented can be

verified to fulfil the requirements (incl. functional, non-

functional)

See you at 14:00 in SAS 208

Lecture 1.2 – OO development

Bjørn Sand Jensen

bjorn.jensen@glasgow.ac.uk

(Slides adopted from SE(M) 2016 by Dr Julie Williamson and slides from the OOSE book repository)

OO

Procedural paradigm:
 Software is organized around the notion of procedures
 Procedural abstraction

 Works as long as the data is simple
 Adding data abstractions

 Groups together the pieces of data that describe some
entity

 Helps reduce the system’s complexity.
 Such as Records and structures

Object oriented paradigm:
 Organizing procedural abstractions in the context of data

abstractions

OO

 An approach to the solution of problems in which all

computations are performed in the context of objects.

 The objects are instances of classes, which:

 are data abstractions

 contain procedural abstractions that operate on the

objects

 A running program can be seen as a collection of objects

collaborating to perform a given task

Core OO concepts

 Core OO principles:

 Encapsulation

 Inheritance (composition, delegation)

 Polymorphism

 All allows abstraction…but how ?

SE is not entirely about programming

but…

 We assume you are familiar with the following programming/OO
concepts (in Java):
 Variables and assignments (incl. static and final, and static final)

 Class (incl. static, final and static final)

 … and objects (an instance of a class)

 Method (incl. private, public, (protected), static, final and static
final)

 Attributes

 Inheritance (extents) (simple associations)

 Basic datatypes (Boolean, integer, Sting, arrays,…)

 We will need a few more concepts to do “good” design:
 Nested classes

 Abstract classes

 Interfaces

 We will not rely on Java Generics (albeit useful) and we will not worry
(to much) about concurrency

Classes and objects

Object

 A chunk of structured data in a running software system

 Has properties

 Represent its state

 Has behaviour

 How it acts and reacts

 May simulate the behaviour of an object in the real world

Classes and objects

A class:

 A unit of abstraction in an object oriented (OO) program

 Represents similar objects

 Its instances

 A kind of software module

 Describes its instances’ structure (properties)

 Contains methods to implement their behaviour

PI 1.5: Objects and Java

 Go to YACRS now:

 https//classresponse.gla.ac.uk

 Join Session 1126

https://classresponse.gla.ac.uk/

PI 1.5 – Objects and Java

public class Bunny {

private String name;

private int weight;

public Bunny(String name, int weight) {

this.name = name;

this.weight = weight;

}

}

Bunny bob = new Bunny(“bob”, 12);

In this code, bob is a:

 A: Class

 B: Object

 C: Variable

 D: Abstraction

PI 1.5 – Objects and Java (sol.)

public class Bunny {

private String name;

private int weight;

public Bunny(String name, int weight) {

this.name = name;

this.weight = weight;

}

}

Bunny bob = new Bunny(“bob”, 12);

In this code, bob is a:

 A: Class

 B: Object

 C: Variable

 D: Abstraction

Class

Instance Variables

Variable Object

Methods

Method

 A procedural abstraction used to implement the behaviour

of a class

 Several different classes can have methods with the same

name

 They implement the same abstract operation in ways

suitable to each class

 E.g. calculating area in a rectangle is done differently

from in a circle

Polymorphism

A property of object oriented software by which an

abstract operation may be performed in different ways in

different classes.

 Requires that there be multiple methods of the same name

 The choice of which one to execute depends on the object

that is in a variable

 Reduces the need for programmers to code many if-else

or switch statements

Inheritance Hierarchies

Superclasses

 Contain features common to a set of subclasses

Inheritance hierarchies

 Show the relationships among superclasses and subclasses

 A triangle shows a generalization

Inheritance

 The implicit possession by all subclasses of features defined in
its superclasses

Inheritance

 The implicit possession by all subclasses of features
defined in its superclasses

Rectangle

QuadrilateralCircle

Ellipse Polygon PlaneLine

Shape3DShape2D

MatrixShape Point

MathematicalObject

Abstract Classes (and methods)

 Use when you don’t want the class type to be able to be

instantiated

 Declare methods as abstract if you want to enforce the

inheriting type

 Abstract classes can give inherited functionality with non-

abstract methods

Example: Fruit

public abstract class Fruit {

public abstract boolean isEdible();

public void takeABite() {

if (this.isEdible()) {

System.out.println(“Tasty Fruit.”);

}

else {

System.out.println(“You are about to be sick.”);

}

}

}

Interface

 Like abstract classes, but cannot have executable
statements

 Define a set of operations that make sense in several possibly
unrelated classes (e.g. Comparable)

A class can implement any number of interfaces

 It must have concrete methods for the operations

You can declare the type of a variable to be an interface

 This is just like declaring the type to be an abstract class

Important interfaces in Java’s library include

 Runnable, Collection, Iterator, Comparable, Cloneable

Overriding

A method would be inherited, but a subclass contains a

new version instead

 For restriction

 E.g. scale(x,y) would not work in Circle

 For extension

 E.g. SavingsAccount might charge an extra fee

following every debit

 For optimization

 E.g. The getPerimeterLength method in Circle is much

simpler than the one in Ellipse

PI 1.7: OO

 Go to YACRS now:

 https//classresponse.gla.ac.uk

 Join Session 1127

https://classresponse.gla.ac.uk/

PI 1.7: OO

This code could be refactored to

better utilise object orientation.

How would you change this code

to make it more efficient?

A: Create an Abstract Class

UIElement with an abstract

method draw

B: Create a Class UIElement with a

method draw

C: Create an Interface drawable

with a method Draw

D: Create an Interface with

methods for draw, getX, and getY

public class Radio {

int x;

int y;

String text;

public int getX() {

return this.x;

}

public int getY() {

return this.y;

}

public void draw() {

// Do some swing

}

}

public class Button {

int x;

int y;

String text;

public int getX() {

return this.x;

}

public int getY() {

return this.y;

}

public void draw() {

// Do some swing

}

}

 This class follow the “is-a” rule, a radio

button is a UIElement

 These elements could all be

clustered as “drawable” things

 It is context dependent if this is usefull. It implies that all

drawable has x and y coordinates which is not a very usefull

abstraction. Could be interpreted as implementing the

actual methods which is not allowed on interfaces (clearly

wrong in that case).

 In this case, we don’t want a generic

UIElement to be able to be instantiated

This code could be refactored to

better utilise object orientation.

How would you change this code

to make it more efficient?

A: Create an Abstract Class

UIElement with an abstract

method draw

B: Create a Class UIElement with a

method draw

C: Create an Interface drawable

with a method Draw

D: Create an Interface with

methods for draw, getX, and getY

PI 1.7: OO (solution)

Access

Applies to methods and variables

 public

 Any class can access

 protected

 Only code in the package, or subclasses can access

 (blank)

 Only code in the package can access

 private

 Only code written in the class can access

 Inheritance still occurs!

 See e.g.
https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html

https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html

Basic documentation

Comment extensively

 Comment whatever is non-obvious

 Do not comment the obvious

 Comments should be 25-50% of the code

Organize class elements consistently

 Variables, constructors, public methods then private
methods

Be consistent regarding layout of code

Main idea: Coupling and Cohesion

 Cohesion

 How related things in a given class are (within a class)

 Coupling

 How dependent classes are on each other (between

classes)

 Design principle: increase cohesion and decrease
coupling

Wrap up (Week 1)

 Reading: Chapters 1 and 2 (should be familiar, but

material will be examinable).

 Requirements is needed before we can start designing

our system (they may change). Review Chapter 4.

 OO approach allows abstraction

 Encapsulation, Inheritance/composition and
polymorphism are core concepts of OO-based design

and development.

Preparation for Next Week

 We’ll be covering UML and modeling

 Read OOSE Chapter 5 Modeling Classes

 Assessed Quiz (starting precisely at 10:05) will be on UML

syntax

Questions?

Comments?

Concerns?

20180108_Lecture_1_1_public
20180108_Lecture_1_2_public