EEE226
Lecture 1 - Introduction
Design: The end product of the software design process is a ‘plan’ or ‘drawing’
Real time system: Must deliver result within a specified time. (used for safety critical) (Real time bugs can be expensive and hard to fix)
Embebded system: a system operating as a part of a larger system
Real time system:
- hard - deadline must be met (airbag system)
- soft - system is allowed to lag at times (human machine interface)
- slow - response may take time
- fast - response should be ear instant
- Multi Rate - A real time system that is multi rate controls multiple sesors and outputs and can deal with them at diffent times aka check for inputs every clock cycle and change outputs every 5 clock cycles.
- distributed system - in this all controll signals are sent to a communication bus and are completely seperated from eachother apart from this constant bus between them all, the data is then picked up by devices that need it
Lecture 2 - Embeded systems programming
Embeded system - A system designed to do one task (not a general purpose machine)
Accululator (A-register) - for adding quickly
B register - For dividing quickly
R Registers - General purpose
Data pointer - Only 2 byte user accessible register, used by commands to point to data
Program counter - 2 byte register to count what line of code you’re on
Stack pointer - used to keep an address to point to the next stack item (the top one because it’s a stack)
Machine cycle:
- fetch
- decode
- execute
- store
machine cycles can take any amount of clock cycles to complete
Bitwise operators - and (&) or (|) not(~) xor(^) shift operators (<<,>>,<<<,>>>,<<=,>>=,<<<=,>>>=)
Lecture 3
Interrupts - important signal sent to the cpu to pause current operation and swap the current processing. can be internal or external.
IE index - this is the priority of interrupts with power off being most important
Lecture 4 - Verification and validation
V Model - Same stages as waterfall but shows how the design links to each testing stage. Same issues as waterfall with the lack of mobility.
Waterfall stages -
- Requirements - Find out the consumer requirements
- High level design - Design entire installed system
- Detailed design - Design individual units
- Production - Create the system
- Unit testing - Test individual units
- Integration testing - Testing the installed system
- Acceptance testing - Test system meets the consumer requirements
Unit testing :
- Written by the programmer
- Test driven development (the unit should fit the test not the other way)
- Automatic testing
- Generally try and do a unit test every change
- removes bugs
- easier to find bugs
- reduces regression errors
- encourages good design
Static verification - Checking code meets convention and shows bad practice code. (this is called a lint (splint is popular for C))
Unit test - programmed to run specific tests (such as CUnit)
Coverage testing - Used to see if all code is run (Such as Gcov)
Memory Behaviour analysis - used to detect memory leaks (Such as Valgrind)
CUnit:
- Define Asserts that must be met and tested during the test
- Asserts belong to tests which belong to suites
GCov:
- Tells you how many times each line is ran
Integration testing:
Should follow after through Unit testing
Well defined functions make integration testing easier
Big Bang:
- Integrate the entire system at once
- Saves time and money if the system is fully working
- Dangerous if the system isn’t fully working and can waste lots of time and money
- Difficult to find bugs
Bottom Up:
- install sections piece at a time starting with smaller advanced sections
- System needs to be designed around the installation approach
- Tests need to be carried out for every section
- The system can exist without base functions for a period of time depending on bugs
- These functions need inputs from the larger systems and these inputs are called drivers
Top-Down:
- similar but opposite to bottom up where the base functions are installed and then small sections after
- Top down requires functions to output data to these are called stubs
- The stub takes the same data but does fake logic
- Top-Down requires programmer to create test code that must be implemented but is never used making it time consuming
Sandwich:
- a mix of top-down and bottom-up
- Test all sections with drivers and stubs seperately
- Then test sections together replacing stubs and drivers one at a time
- This can take more effort for the programmer but take less time to implement
System and Integration Testing:
- Test the whole system to make sure the requirements have been met
- Ideally automated but exhaustive automated tests take a lot of effort
- Test valid and indvalid inputs
- Should test reliability and performance, not just functionality
Acceptance tests:
- These determine if the system is finished
- Alpha testing
- Prototype that is used under supervision
- Restricted use
- Lots of bugs that should be reported
- Beta Testing
- Close to final release
- little restrictions on use
- small number of bugs to be reported
Bugs:
- Bug fixes can depend on severity (safety critial bugs will usuall cause the developer to stop all use of the system)
- Small bugs can be released and simply explained in a known bugs section
- After bugs are fixed regression testing should take place
- Regression testing - afte changing a piece of code check other sections still respond as designed when used together.
- Bugs should be kept written down when working as a group (GNATS, Github etc…) This allows for easy prioritisation and distribution
Lecture 5 - Design Methodologies
Models give a representation of software development.
Default steps:
- Specification
- Development
- Implementation
- Validation
- Refinement
Waterfall Model
Start at the top and finish at the bottom, each stage must be met before going to the next.
You can only go down the model never back.
This is the most basic methodology and is linear.
Each phase is verified and validated
The model is easy to follow and definitive, generally top-down
Model cannot adapt to changes
Evolutionary Development
Processes can iterate aka multiple design stages to fix errors after testing
Single description sets off a loop of specification, development and validation which then outputs an initial version the intermediate versions and then a final version.
This is looped untill the final version meets the initial outline description.
Each version is thrown away after getting feedback (throw away prototyping)
Advantages:
- More customer involvment means a more likely correct solution
- More regular testing means less bugs
Disadvantages:
- Difficult to monitor progress
- Constant changes can lead to badly structured code
- Iterations can go on indefinitely
Incremental Model
The requirements are interperated as a system and then this system is split into many increments. Each increment is treated as a waterfall and then each increment added.
Advantages:
- Prioritises requirements
- Produces prototypes along the way automatically
- Each increment can be fully tested individually
Disadvantages:
- Requirements can be hard to map into increment sections
- Some projects simply do not fit this style
- Sometimes each increment can’t be tested easily
Spiral Model
The spiral model has 4 quadrants:
- Determine objectives
- Identify and resolve risk
- Development and test
- Plan iteration
Each revolution of the spiral model costs more and takes more time. But every revolution should mark a customer report on progress meaning more progress in the beginning of the project and less further on.
Agile Development
95% of buisness now use agile development to plan and build products.
On average about 80% of buisnes.
Use agile for small teams with weak existing requirements.
Agile defines 12 principles 5 of which are:
- Deliver early and often (increases product quality and customer satisfaction)
- Change requirements (understanding that changes happen instead of resisting them)
- Face to face meetings (much better to understand things face to face and creates customer satsifaction)
- measure progress in terms of software (measure whats working not what phaases of development)
- Simplicity saves effort and time as long as it meets the requirements
Scrum
Most common method of agile development is scrum.
- Group of user stories (requirements) is called the product backlog (A wish list)
- Roles: Scrum master, Developer, Tester,
- Product backlog is reduced into a specification (release backlog)
- This release backlog is then time estimated and prioritised for each object
- These are then split into sprints where a release is produced at the end of the sprint
- Sprints are measured with burndown charts showing what needs to be done and whether it’s on time
- Daily meetings show off what’s been done and keeps everybody up-to date
Weaknesses:
- Integration is done at the end not continously
- Lack of scalability
- Based on the robustness of human communication
- Lack of formalism
- Lack of clear definitions
XP(Extreme Programming)
- releases are often and early to get feedback as soon as possible
- user stories are created to say what the program should do and based around a time estimate
- Pair programming - the idea of having two programmers using one workstation to prevent bugs due to two minds on one job
- Test driven
- collective ownership - everyone looks after every piece of code
- continouous integration - code is merged as soon as it’s complete
Weaknesses:
- Difficult co co-ordinate large teams
- Can run indefinitely if not managed
- Lack of proper documentation
- Difficult to know how far through the project
Used when:
- The project uses brand new technology
- Frequent releases are required
- Projects are small
Lecture 6 - Structured Programming Diagrams
Structured programs should be:
- Modular
- Modifiable
- Robust
- Readable
Conditioning:
- Define inputs and outputs, if tests are passed no need to look any lower level
- useful for bug searching
Jackson Structure charts
- shows composition of program as well as sequence
- Sections are split up into sub sections with more detail the futher down
- Circles in the top right show that these are options (true false clauses)
- Asterisk in the top right show a loop case (anything underneath is looped until condition met unless an Exit is found (E Block))
Jackson Structure Charts Extended Notation
- A new box shows test conditions or loop conditions removing ambiguity
Jackson Structure Charts CASE (Computer-Aided Software Engineering)
- Multi boxes - these allow conditions to be written at the top of a box and the statement written underneath in a connected box
Program writing
With the JSC built writing the code is easy simply write the system from top down dealing with each level before branching off. This generates code that can be tested throughout and keeps the program design simple.
This code is then validated and verified.
Lecture 9 - Object Orientated Programming
Object orientated programming is programming which is orientated around objects taking advantage of encapsulation, polymorphism and inheritance to increase re-use of code.
Generally a OOP langauage can be used for both OOP and POP (Procedure orintated programming)
A class has properties, properties are a collection of attributes (such as color) and can also have methods.
A class is a shell for an object to be made.
Classes are then instantiated into objects, these objects have all of the properties and methods of the class but are defined (such as color=brown)
Encapsulation - The use of modifiers to make properties only accessible from certain sections of the program. (This is good to protect objects properties)
Constructor - This is the command called to create an instance of the class
Destructor - This is the command called to delete an instance of a class
Inheritance - The idea a class can take the properties of another class
Polymorphism (Function overriding) - Functions with the same name can be over-ridden depending on the parameters input (A class that inherits from another can use a function with the same name to over-ride aka if a doubledecker is a deviation from bus the bus can have a function size which is length by width and a function for doubldecker for size can be length by width by height)
Function Overloading - A class that has multiple functions with the same name with different input types (sting/int/char), depending on the data type input a different function is run.
EEE226
Lecture 1 - Introduction
Design: The end product of the software design process is a ‘plan’ or ‘drawing’
Real time system: Must deliver result within a specified time. (used for safety critical) (Real time bugs can be expensive and hard to fix)
Embebded system: a system operating as a part of a larger system
Real time system:
Lecture 2 - Embeded systems programming
Embeded system - A system designed to do one task (not a general purpose machine)
Accululator (A-register) - for adding quickly
B register - For dividing quickly
R Registers - General purpose
Data pointer - Only 2 byte user accessible register, used by commands to point to data
Program counter - 2 byte register to count what line of code you’re on
Stack pointer - used to keep an address to point to the next stack item (the top one because it’s a stack)
Machine cycle:
machine cycles can take any amount of clock cycles to complete
Bitwise operators - and (&) or (|) not(~) xor(^) shift operators (<<,>>,<<<,>>>,<<=,>>=,<<<=,>>>=)
Lecture 3
Interrupts - important signal sent to the cpu to pause current operation and swap the current processing. can be internal or external.
IE index - this is the priority of interrupts with power off being most important
Lecture 4 - Verification and validation
V Model - Same stages as waterfall but shows how the design links to each testing stage. Same issues as waterfall with the lack of mobility.
Waterfall stages -
Unit testing :
Static verification - Checking code meets convention and shows bad practice code. (this is called a lint (splint is popular for C))
Unit test - programmed to run specific tests (such as CUnit)
Coverage testing - Used to see if all code is run (Such as Gcov)
Memory Behaviour analysis - used to detect memory leaks (Such as Valgrind)
CUnit:
GCov:
Integration testing:
Should follow after through Unit testing
Well defined functions make integration testing easier
Big Bang:
Bottom Up:
Top-Down:
Sandwich:
System and Integration Testing:
Acceptance tests:
Bugs:
Lecture 5 - Design Methodologies
Models give a representation of software development.
Default steps:
Waterfall Model
Start at the top and finish at the bottom, each stage must be met before going to the next.
You can only go down the model never back.
This is the most basic methodology and is linear.
Each phase is verified and validated
The model is easy to follow and definitive, generally top-down
Model cannot adapt to changes
Evolutionary Development
Processes can iterate aka multiple design stages to fix errors after testing
Single description sets off a loop of specification, development and validation which then outputs an initial version the intermediate versions and then a final version.
This is looped untill the final version meets the initial outline description.
Each version is thrown away after getting feedback (throw away prototyping)
Advantages:
Disadvantages:
Incremental Model
The requirements are interperated as a system and then this system is split into many increments. Each increment is treated as a waterfall and then each increment added.
Advantages:
Disadvantages:
Spiral Model
The spiral model has 4 quadrants:
Each revolution of the spiral model costs more and takes more time. But every revolution should mark a customer report on progress meaning more progress in the beginning of the project and less further on.
Agile Development
95% of buisness now use agile development to plan and build products.
On average about 80% of buisnes.
Use agile for small teams with weak existing requirements.
Agile defines 12 principles 5 of which are:
Scrum
Most common method of agile development is scrum.
Weaknesses:
XP(Extreme Programming)
Weaknesses:
Used when:
Lecture 6 - Structured Programming Diagrams
Structured programs should be:
Conditioning:
Jackson Structure charts
Jackson Structure Charts Extended Notation
Jackson Structure Charts CASE (Computer-Aided Software Engineering)
Program writing
With the JSC built writing the code is easy simply write the system from top down dealing with each level before branching off. This generates code that can be tested throughout and keeps the program design simple.
This code is then validated and verified.
Lecture 9 - Object Orientated Programming
Object orientated programming is programming which is orientated around objects taking advantage of encapsulation, polymorphism and inheritance to increase re-use of code.
Generally a OOP langauage can be used for both OOP and POP (Procedure orintated programming)
A class has properties, properties are a collection of attributes (such as color) and can also have methods.
A class is a shell for an object to be made.
Classes are then instantiated into objects, these objects have all of the properties and methods of the class but are defined (such as color=brown)
Encapsulation - The use of modifiers to make properties only accessible from certain sections of the program. (This is good to protect objects properties)
Constructor - This is the command called to create an instance of the class
Destructor - This is the command called to delete an instance of a class
Inheritance - The idea a class can take the properties of another class
Polymorphism (Function overriding) - Functions with the same name can be over-ridden depending on the parameters input (A class that inherits from another can use a function with the same name to over-ride aka if a doubledecker is a deviation from bus the bus can have a function size which is length by width and a function for doubldecker for size can be length by width by height)
Function Overloading - A class that has multiple functions with the same name with different input types (sting/int/char), depending on the data type input a different function is run.