These are the resources used for the Computer Science course Programming Principles, designed to teach students the fundamentals of computer programming and object orientation via learning the Java language. We also touch on some software engineering basics, such as patterns, software design and testing. The course assumes no previous knowledge of programming, but there is a fairly steep learning curve, and students are encouraged to practice, practice, practice!
Two lectures that introduce the idea of modelling in the large, and contrasts hard system and soft system modelling. The second lecture goes into detail on a number of specific methods for analysing a system (CATWOE and CSH) and on modelling a system (Systems Diagrams and Personas).
In this session we look at how to think systematically about a problem and create a solution. We look at the definition and characteristics of an algorithm, and see how through modularisation and decomposition we can then choose a set of methods to create. We also compare this somewhat procedural approach, with the way that design works in Object Oriented Systems,
This is the revision session for our Programming Principles course. We take a whistle-stop tour of the topics covered in the course, look at the three pillars of object oriented programming, and look ahead to the exam.
In this session we build on inheritance and look at overriding methods and dynamic binding. Together these give us Polymorphism - the third pillar of Object Oriented Programming - and a very powerful feature that allows us to build methods that deal with superclasses, but whose calls get redirected when we pass in sub-classes.
This is a presentation for our year one INFO1008 course of Computational Systems. It covers the need for requirements capture and the difficulty of building a specification based on user information. We present UML Use Cases and Use Case diagrams as a way of capturing requirements from the users point of view in a semi-structured way.
This presentation describes the evolution of Software Development Lifecycles (SDLCs) from the first formally proposed linear models including, the Waterfall (Royce 1970) through to iterative prototyping models (Spiral and Win-Win Spiral) and incremental, iterative models used in Agile Methods. We discuss the problems iinherent in each prpoosal and how successive models attempt to solve them.
In this session we look at how to model flow of control and interactions between components using UML Activity and Sequence Diagrams. This is an introductory session and so for Activity Diagrams we only cover branching, forks and joins and swim lanes, and for Sequence we cover lifelines, messages and returns, and alt, par and opt frames.
In this session we look at UML Class Diagrams and how they fit into both the family of UML models, and also the software engineering process. We look at some basic features of class diagrams including properties, operations, associations, generalisation, aggregation and composition.
In this lecture we cover how UML Use Cases can be used for requirements capture. We look at the anatomy of a Use Case Description, and the way in which use cases can be brought together in a use case diagram. We also look at the way that use cases can be derived from problems using noun verb analysis.
This presentation gives an overview of TIDT's development process at time of writitng in March 2016. We were and still are developing our process. It is an agile process based on DSDM and Scrum.
Building software for Web 2.0 and the Social Media world is non-trivial. It requires understanding how to create infrastructure that will survive at Web scale, meaning that it may have to deal with tens of millions of individual items of data, and cope with hits from hundreds of thousands of users every minute. It also requires you to build tools that will be part of a much larger ecosystem of software and application families. In this lecture we will look at how traditional relational database systems have tried to cope with the scale of Web 2.0, and explore the NoSQL movement that seeks to simplify data-storage and create ultra-swift data systems at the expense of immediate consistency. We will also look at the range of APIs, libraries and interoperability standards that are trying to make sense of the Social Media world, and ask what trends we might be seeing emerge.
Topics covered
Professional software development
What is meant by software engineering.
Software engineering ethics
A brief introduction to ethical issues that affect software engineering.
Ethical dilemmas
Disagreement in principle with the policies of senior management.
Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system.
Participation in the development of military weapons systems or nuclear systems.
Case studies
A personal insulin pump
An embedded system in an insulin pump used by diabetics to maintain blood glucose control.
A mental health case patient management system
Mentcare. A system used to maintain records of people receiving care for mental health problems.
A wilderness weather station
A data collection system that collects data about weather conditions in remote areas.
iLearn: a digital learning environment
A system to support learning in schools
This chapter is to introduce software requirements and to explain the processes involved in discovering and documenting these requirements in order to meet stakeholders' needs. You will :
understand the concepts of user and system requirements and why these requirements should be written in different ways;
understand the differences between functional and non-functional software requirements;
understand the main requirements engineering activities of elicitation, analysis and validation and the relationships between these activities,.
understand why requirements management is necessary and how it supports other requirements engineering activities.
Design and implementation
Is the stage in the software engineering process at which an executable software system is developed.
activities are invariably inter-leaved.
Design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements.
Implementation is the process of realizing the design as a program.
Testing can only show the presence of errors in a program. It cannot demonstrate that there are no remaining faults.
Development testing is the responsibility of the software development team. A separate team should be responsible for testing a system before it is released to customers.
Development testing includes unit testing, in which you test individual objects and methods component testing in which you test related groups of objects and system testing, in which you test partial or complete systems.
When testing software, you should try to ‘break’ the software by using experience and guidelines to choose types of test case that have been effective in discovering defects in other systems.
Wherever possible, you should write automated tests. The tests are embedded in a program that can be run every time a change is made to a system.