UFMFGT-15-1

Programming for
Engineers
Lecture 1
Module introduction, become a
programmer
Dr James Whiting
Lecturer in Electronic Engineering
University of the West of England
Lecture topics
How the module is structured

Program design

• Pseudocode

• Flow charts

• Structure charts

Debugging/testing
Module introduction
Module Team:

James Whiting Paul Worgan Ghaly Mikhail Tom Knowles

Module Leader

Contact hours (labs and lectures): Self study hours: 114 hours
1hr Lecture + 2hr Lab Tutorial
 Module introduction
Module Learning Outcomes:

MO1 Create appropriate software based solutions to a variety of mathematical and engineering
problems.

MO2 Develop and document computer code to meet appropriate codes of practice and industry
standards in relation to software development.

MO3 Apply fundamental programming principles and a system approach to the design, development and
testing phases of software development.

MO4 Use a variety of information sources including technical literature to inform software development
applications.
 Module Assessment
Digital Logbook (Portfolio of Evidence) marks breakdown

Progress submission 1 (binary mark, 5%):– due 25th February 2pm (no grace period)
Expected submission, Lab Exercises 1 and 2.
Progress submission 2 (binary mark, 5%):– due 10th March 2pm (no grace period)
Expected submission, Lab Exercises 3 and 4
Logbook of exercises (scaled mark, 20%):- due 19th April (48 hour grace period
applies)
Expected submission, Lab Exercises 5, 6 and 7

Mini Coursework
Report, Development Log: 30% - due 2th May (48 hour grace period applies)
Oral Exam, Viva & Demo: 40% - To be scheduled in UWE Weeks 38 & 39
(between 6th and 17th May). Controlled conditions assessment.

Description Module Assessment Weighting Assessment Submission Deadline

Portfolio Log book of Lab Exercises 1-7 30% 19/04/2024
Report Development Log of Mini Coursework 30% 2/05/2024
Oral Exam Oral Exam/Viva & Demo of Mini Coursework 40% In UWE weeks 38 & 39.
 Log book Content
• Brief description, interpretation and assumptions of exercises. (10%)
• Design Documentation e.g. structure charts, flowcharts, pseudocode, state transition diagrams. (25%)
• Code (not weight bearing but needed in log book *
• Evidence of testing (and working code) (30%) - this is your responsibility
• Problems encountered and solved & Reflection each week. (20%)
• Dated entries (5%)
• References/Record of information sources e.g. websites. (5%)
• Legibility. (5)%

*Note, source code MUST be included with every submission.

See example on Blackboard

We will be learning the C programming language – Why?

One of the top programming language to learn in 2021

https://spectrum.ieee.org/top-programming-languages/

The top rated embedded language

https://www.geeksforgeeks.org/top-10-best-embedded-systems-programming-langu
ages/
You will use it next year in MAGL,
Benefits over other languages:
developing a maze solving robot on a
microcontroller!
• low-level access to memory

• loose data typing policy (i.e. use of pointers)

• ease of porting embedded programs

• It is FAST!
Let’s start with software design
How do we begin Coding/Programming designing software?

Think like a software designer!

Software design
One definition: Deriving a solution which satisfies software requirements (Sommerville,
Software Engineering)

• Most real-world software engineering design problems are complex and difficult to solve (e.g.
avionics, robot controllers, operating systems, communication systems).

• A common approach in general is to use a “divide and conquer” strategy.

i.e. break down the complex system into components (modular decomposition), solve
each one separately and then integrate the components.

Software need
Benefits?

Subsystem1 Subsystem2 Subsystem3

Combined solution
Software design
Benefits:

• Improved understandability and manageability

• Distributed development

• Module/Code reusability

• Testability – Modules can be tested before integration

• Maintainability –Easier to locate and fix bugs –Easier to make changes to one module without
affecting other modules

• Improved robustness
Key issues in modular Software design

Abstraction

A technique for managing complexity of software systems. Used to hide certain details and only
show the essential features of modules.

• abstract entity: module is described by what it does and what its interfaces are (and not its
implementation)

Information Hiding

• Module hides the internal details of its data and processing activities

• Modules limit access to internal data only to internal operations that need it. Communication
occurs only through well-defined interfaces.
Key issues in modular Software design

Coupling

The degree of dependence or amount of interactions between components.

Coupling should be minimised i.e. modules should be independent of each other making it easier to

• Modify the program

• Reuse module

• Test module

• Reduce propagation of software errors

Key issues in modular Software design

Cohesion:

The degree to which all elements of a component (module) are directed towards a single
task

and all elements directed towards that task are contained in a single component.

• The elements of each module should be closely related to one another.

• High cohesion makes modules easier to use and makes the entire program easier to understand

Further reading:

https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/
Top Down design
Break down a complex problem into subproblems to develop solutions.

• In attempting to solve a subproblem at one level, introduce new subproblems at lower levels.

• The process proceeds from the origin problem at the top level to the subproblems at each lower
level.

• Analogous to the process of refining an process.

Work breakdown structure (WBS)
WBS is one of the most important management tools for software design
it decomposes the overall task into smaller more manageable subtasks

Let’s have a go as an example WBS

Articulating software design
How do we share our designs with others?
• Pseudocode
• Flow Chart
• State transition diagrams

• (Also Structure Charts)

Pseudocode

1. Pseudocode is a semiformal, English-like language

with limited vocabulary that can be used to design &
describe algorithms/tasks.
2. Define the procedural logic of an algorithm in simple
and easy to understand steps.
3. Free of syntactical complications of a programming
language.
Pseudocode - example
Find the maximum value in an array of 20 random numbers
1. Start
2. Declare array and size
3. Declare maximum(max)
4. For N values
a. Generate Random number
b. Store in array
5. Initialise max as first element in array.
6. For N values in array
a. Compare max with value in array
b. IF value > max then assign value to max
7. Print max to screen
8. end
Flow Chart
Visual representation of progress (good for loops/iteration!)
Symbol Name Function
Represents any type of internal operation inside
Process the Processor or Memory
Used for flow control. Output (of question asked)
Decision is in binary format (Yes/No, True/False)

Represents Input / Output (I/O) operation

Input/Output

Allows the flowchart to be drawn without

Connector intersecting lines or without a reverse flow
Predefined Used to invoke a subroutine or an Interrupt
process program.
Shows direction of flow
Flow lines

Represents the starting or ending of the program,

Terminal process, or interrupt program
Flow Chart - Example
Compute the average marks from the marks of 25 entered

Process

I/O
Terminal

Decision
 State Transition Diagrams
• A state transition diagram is a technique to depict
1. The states of an entity
2. The transitions of states of the entity
3. The events that cause the transitions of states of the entity
• In principle the entity could be
1. a physical device such as a light switch or button
2. a software system or component such as a communications system or an
operating system
3. a more complicated machine such as a robot
• The generic name for such an entity is a Finite State
Machine (FSM)
 State Transition Diagrams
• States are usually represented as labelled circles, boxes etc.
(according to design notation in use).
• Transitions are represented as directed lines or arcs.
• Events are represented as line/arc labels. e.g.
State Transition Diagrams – Phone call example
States:
Idle, Dialling, Ringing,
Remote End
Ringing,
Connected.

Events:
Pick-Up, Incoming Call,
Receive Ring Tone,
Remote End Answers,
Hang Up.

Notice that what happens

when a Pick-Up event occurs
depends on the current
system state.

(This diagram is for illustration

only and is not complete; it
also does not deal with
Structure Charts – the relationship diagram

• Depict functions and sub-

functions of each part of system.
• Clearly show relationships
between modules of a
computer program.
• Hierarchical, modular structure
–Each layer in a program performs
specific activities.
–Each module performs a specific
 Structure Charts – the relationship diagram

Can have loops too

Data Flow

Control flow (flags or true/false)

• Rectangle represents a module (typically a

function in C)
• Arrows show which modules use other modules
• Labelled arrows with circles show data passing
between modules
Structure Charts - Example
Selection (branches)
Good software practice
Programme banners.
Includes key information about the software displayed at the top of
a file.
Commented out, i.e. only humans read it.
Example:
Include these in all of your
designs!
/* Filename: Something.c
Description: Tell readers what you are trying to do.
Author: take credit for your work here!
Date: When did you start it?
Input/output: if you read files or have input (not user keyboard
input or display)
Version: 1, 2, 3 etc
Change Log: What have you added since the last edit/version.
*/
Module Software
Clion Integrated Development Environment (IDE)

Available on UWE and home computers via

Create a New Project
https://appsanywhere.uwe.ac.uk/ for EVERY exercise!
- Off campus, use UWE VPN
Save on your Student
H: Drive!
Or if you are not at a UWE computer

https://www.onlinegdb.com/online_c_compiler

But manually save the code somewhere!

 Testing – how do you show it
works?
Test case scenario template
Type of test Unit/Integration/Scenario
Test Objective Clearly state the objective or purpose of the test
Describe the steps or actions to be taken during the test- only needed for Scenario test, optional for
Test Steps integration test
Expected Result Define the expected outcome or behavior after executing the test steps
Test Data What input(s) or commands given, there may be repeats to test boundary and tricky conditions
Pass Criteria Define the criteria for considering the test as passed
Fail Criteria Specify conditions that would indicate a failure of the test
Outcome: Did the version pass or fail (for which test data)
Test Notes What version this was tested on and other important information, possibly include the optional criteria here
Test Author
Date

Optional
Test Execution Provide instructions on how to execute the test
Test Dependencies List any dependencies or external factors that may impact the test
Test Environment Specify the environment in which the test will be conducted, including software versions, hardware, etc.
Software Design
We have learned about:

• The module itself!

• The process of software design

• How we describe our designs to others.

We won’t be able to help you, without your

software designs!

Now time for the lab work!

Don’t forget – Daily support via Espresso Programming sessions