1. Application Development Theory

2. Road Map Week 1: Anatomy of an Application
Week 2: The Software Process and Development Lifecycle
Week 3: Software Development Methodologies
Week 4: Software Roles & Communication
Week 5: Developer & User Facing Documentation
Week 6: Language Structures & Logic

3. Road Map Week 7: Object Oriented Programming
Week 8: Model View Controller
Week 9: SDKs and APIs
Week 10: User Interfaces
Week 11: All About Data
Week 12: Final Project

4. Anatomy of an Application
● Varies depending on platform and application type You will find some common themes or ideas: ● User interface ● Business Logic ● Data Layer ● User Documentation

5. UI Bad designs

11. User Interface
The layer of the application where all user interaction occurs.
● Command Line
● Graphical
● Speech
● Variations include:
○ Touch Screens
○ Menu Driven
○ Form Driven
○ Web based

12. What to Design Need to take into account: Who the users are
What activities are being carried out
Where the interaction is taking place

13. Understanding users’ needs
Need to take into account what people are good and bad at
Consider what might help people in the way they currently do things
Think through what might provide quality user experiences
Listen to what people want and get them involved

14. Data Layer
● Generally used to directly communicate with a storage medium. ● Database or file system reading and writing. ● This is where SQL queries and PHP go. ● Calculations related to the data live here as well. Further reading

15. Business Logic
● “Functionality required to achieve business needs of the application” ● Specifies how information is created, displayed, altered, or removed. ● Manages communication between the presentation layer (User Interface) and the database or store. ● Executes actual business rules using code. ● Workflow is designed to satisfy the business rules.

16. Documentation
● Part of every application ● User Facing Documentation ● Developer Documentation ● Commenting code

17. Let’s Talk About Software Quality
● Software Quality is an abstract idea. ● Can mean something different to everyone. ● High quality software can be described as: ○ Fast ○ Reliable ○ Having no major design flaws ○ Something that does what it says it does ● What does “Software Quality” mean to you as the end user? ● What does “Software Quality” mean to a software developer or quality assurance analyst?

18. Some Items We Discussed
User Interface: The layer of the application where all user interaction occurs
Data Layer: Generally used to directly communicate with a storage medium.
Business Logic: Functionality required to achieve business needs of the application
Documentation: Developer, User Guide, Commenting/Documenting Code

19. What is A Computer Program?
● A computer program is simply a list of one or more instructions that tell a computer what to do. ● The instructions are converted to machine language, which is the instruction set both supported by and executed on the computer’s CPU. (Central processing unit) ● There are different language levels - high level, low level ● Everything a computer does is done using one type of computer programming language or another. ● You’re learning how to tell a computer what to do. It knows nothing until you do that.

20. Machine Code
● Extremely fast ● Languages that uses a series of binary ( ) or hex instructions. ● Each 1 or 0 can be thought of as either True or False, On or Off.n. ● Different CPUs support different instruction sets.

21. CPU Instruction Set

22. Machine Code
● Coding directly for the instruction set of a specific CPU has its limitations. ● Coding in machine language is time consuming. Machine Language BASIC 5 FOR I=1 TO 1000: PRINT "A";: NEXT I These two programs both print the letter "A" 1000 times on the scree

23. Assembly Language
● Low level programming language for a computer. ● Still very fast, and very powerful. ● Produce code optimized for your hardware setup. ● Strong relationship between the language and the machine code. ● Each processor supports its own Assembly language, since the language is tied directly to that CPUs instruction set. ● Assembly language code is converted to machine code by a program called an assembler.

24. Assembly Language ● Long and dull to write
● Can be quite difficult to debug
● Can be expensive & difficult to maintain
● Non-portable for other architectures

25. High Level Languages
● Java, C#, Python, C++ (newer iterations) ● FORTRAN, PASCAL, C, COBOL (older iterations) ● Allow for the solution to a problem to look closer to something used by a human being. ● Designed to make programming easier, and for the programmer not to have to know the internal structure of each specific computer.

26. High Level Languages
● Much closer to human language. ● Easier to debug ● Standardized code - completely independent of processor. ● Still need a compiler or interpreter to translate high level language to machine code. ● Sacrifice some power and speed (when compared to Assembly or Machine language)

28. Why Do Developers Practise Methodologies?
● Software quality ( Has the software been continually evolving for over 50 years?) ● Over the years, many “development methodologies” have been experimented with. Many helped, and many failed or were built-upon. ● All methodologies have similar goals, including, but not limited to: ○ increasing software quality. ○ increasing developer productivity. ○ improving the management of large scale projects. ○ creating a better work environment. ● At first, it was the wild-wild west. There were no rules. Making stuff up.

29. Non-Structured Programming -1950s
● Heavily criticized for producing hardly-readable “spaghetti code”. ● Early programming languages that rely on this paradigm include BASIC, FORTRAN, COBOL. ● GOTO Statements

30. Software Design Evolution - 1960’s
● Structured Programming - A New Programming Paradigm ○ Top-Down Approach ○ Code is structured into logical blocks. ○ Code is executed in the order in which it is written. ○ Makes use of subroutines, for and while loops, block structures. ○ Pascal, ALGOL, Ada

31. Programming Paradigm
A programming paradigm is a style or “way” of programming.
Some languages make it easy to write in some paradigms but not others.
A paradigm is a way of doing something (like programming), and not a concrete thing (like a language).

33. Object Oriented Programming -1980's
● Different type of structured programming ● C, C++, and later C#, Java ● Uses objects and classes ● Code can easily call other areas of code, do work, then return and continue execution. ● Composition - Objects can contain other objects. ● Inheritance - “Is a” relationship. ● Abstract classes - Can be used to define and enforce a structure.

36. Group Activity
Let’s practise thinking like a software developer by writing some structured code.

37. Read http://www.thecorememory.com/SHOS.pdf
Read the following sections:
“Programming Languages and Operating Systems”
“Software Comes of Age”
“The Internet and the World Wide Web”

38. Assignment - Write
1. In your own words, describe why object oriented programming is an improvement on earlier programming paradigms. 2. How do you think the advent of the internet changed: a. How we write computer software b. The types of software and applications that exist 3. Research, then compare and contrast the advantages and disadvantages of the following: Machine Code, Low level programming languages, and high level programming languages. Create a table and list these differences. Which paradigm strikes you as the most relevant in 2016? Why?