Software Design and Development – Assignment 2

Programming Paradigms [P1]


The simplest form of programming is procedural. Programs written in this paradigm run from start to finish – likely from the top of the source code to the bottom – and are somewhat limited in what they can achieve. While the program may well enter limited-iteration loops, pause for periods of time and use functions to reduce repetition in the source code, it will ultimately terminate at a given time. The tasks that a procedural application carries out are generally simple and vary minimally between different instances. Procedural programming languages, and procedural programming in general, offer a good way to introduce someone to writing computer programs, and are useful for creating one-use programs, such as compiling and installing scripts for other pieces of software.

Procedural programming is rarely used in modern, large-scale software development, as other paradigms such as object-oriented and event-driven programming allow for greater productivity and maintainability-of-codebase. Almost all programming languages popular today can be used in a procedural manner, but are capable of more. For example, Python is often used to introduce people to programming, and can be used in a procedural way. That said, the language has full class support, making it object-oriented as well. Python is perfectly suited to large scale development, as shown by it being among Google's handful of favoured languages.

A common example of procedural programming can be found in factory machinery. Some machines that cannot be entirely mechanical require simple programs in order to operate, which likely consist of repetitive operations performed by loops. Procedural programming would be most suited to a machine used for printing the use-by date on food items, for example. The program would begin by determining what food item was being stamped and therefore the time period before expiry. Using the current date, it would then be able to work out a use-by date, and begin to stamp food items using a loop. For each iteration of the loop, the program would likely check the time of day or use another data source to decide whether or not to exit the loop.


Having been developed after it was noticed that sets of data often share similar attributes, object-oriented programming centres around common data structures. Objects are instances of a class, and belong to that class. For example, in a simple dungeon-crawler game, the different enemies would belong to different classes. There would perhaps be a parent class Enemy that would define properties and methods common to all enemies. These might include properties such as position, rotation and status (neutral, "agro", etc.), and methods to move, change status and perform other actions. There would then likely be a series of sub-classes, such as Archer, which would extend the Enemy class, by adding further properties and methods unique to the archer enemy. This could include the number of arrows that the enemy has left, or a method to fire the archer's bow.

By using classes, a piece of software can become much more organised and easier to extend in the future. Object-oriented programming also provides a more intuitive way of handling large fields of data. A popular example of the use of object-oriented programming is in a business environment. Using a Customer class, a new object for each row in a database table can be created, and each object then used as an easier way of accessing customer data.

Object-oriented programming is often used by software development agencies. Not only does this provide the most practical development tool for most large-scale applications, but classes can inherently be shared between different projects. As classes essentially act as data templates and snippets of code which would likely be used to manipulate the class' data, they can be used repeatedly. For example, a shopping website built for one client would likely be largely the same as one built for another client, at least in terms of the server-side application. For this reason, pre-written classes can be taken from existing projects and slightly tweaked for a new client, saving time for the development agency.


The third common programming paradigm is event-driven, executing code only when particular triggers fire in the software's environment. For example, most modern desktop and mobile application development is event-driven, with programs falling into idle as they wait for user input. To an extent, a simple Blackjack game can be used as an example of event-driven programming, as the program will stall and wait for user input when asking the player to stick or twist during the game. Another popular example of an event-driven programming language is JavaScript. Most commonly used in the browser, and more recently on the server-side of the web, JavaScript is largely centred on listening for and firing events. The user pressing a keyboard key while a web page is in focus would count as an event, which could be bound to:

window.onkeyup = function(event) {          // bind to the "keyup" event

    var key = event.which;                  // extract key ID from event data

    if (key == 71) {                        // if the pressed key was G:
        alert("You pressed the G key!");    // create alert window

The above script is active if you are viewing the web version of this assignment. Press G to show it.

Using event-driven programming makes for a much more interactive user experience. Any user interface that uses buttons, text boxes, tick boxes, etc., is using a form of event-driven programming.

Project Life-Cycle [P5]

The systems development life-cycle, or SDLC, is a process model used by software engineers to simplify the steps of developing a software project.

The model begins at the analysis and assessment stage. The developers will look at the problem they will attempt to create a solution for, and decide whether or not the project will be feasible, worth the time, and potentially profitable. By carefully analysing the situation even before designing the software, the developers become more aware of the specific issues they must avoid, and will immediately begin to consider ways around them. This stage is important as the team must familiarise themselves with the task to be completed, and they may find during this stage that there are other projects, libraries or developers already aimed at overcoming the same problem.

The next step of the cycle to design and plan the software. This may involve the use of pseudo-code and potentially some prototyping of particular software modules, but the vast majority of programming will not occur here. By mapping out a rough ides of the classes, data structures, interfaces with other software, and processes undertaken by the software, the team will be able to better work towards where their colleagues have left off and hence create a coherent and efficient final product.

The next phase is the actual development phase. Using tools such as IDEs and source control, the developers build the software outlined in the planning stage. During this process they will likely agree on standards to be used throughout the project to that the work of a number of developers will all follow a common style and work together seamlessly. Throughout this stage, testing of individual components will likely take place, and developers will pull content that others have written to test integration between the two.

The next prominent stage is to test the application as a whole. The work of all the developers is compiled together and tested as one. Very often bugs can be found in the software at this stage, sending the developer back to previous stage. Once a copy of the software has been build that appears fairly stable, the project can move forward.

Once the bulk of the development is complete, the developers can focus on integrating their work with the existing infrastructure. This may involve some extra development and hence more testing, but often the process merely involves placing the software in its operating environment and completing further testing. The configuration of the surrounding pieces of software that will need to communicate with the new program may be changed too.

The last stage involves maintaining the project, which effectively involves repeating the process, and deploying the software into more environments, perhaps for new customers. Providing support for the application, fixing bugs, and adding new features are all accounted for here.

Programming Structures [P5]

The following are elements of a project that would considered by the engineers during the design and planning stage of the SDLC.

Designing structures, or structs, of data for the application would be undertaken. By analysing the data that the program would have access to and would be fed in its intended production environment, the developers would be able to plan and prototype the containers of information that would be used to process data more efficiently. For example, a struct could be created to hold a profile of information about a member of a website. The struct would perhaps include a long int for storing the user's post-count; char arrays to store their name and email address; and a float to store their monetary balance on the website.

The classes of the application would also likely be designed. In a similar way to designing the structures the software would use, the developers could look to the data that the software would be handling, and design classes and sub-classes to most efficiently cater for everything. By understanding the data, the developers would also be able to clarify what methods and functions would need to be designed to modify and process the data. For a more in-depth description of classes and objects, as well as examples, see the object-oriented programming section above.

The variables too would be planned before any actual programming was carried out. The consistency and efficiency of a program will be improved if the developers agree on naming conventions and standard relating to the creation of variables and data types used. For example, most advanced programming languages offer both floats and doubles, and sometimes decimals as well. Each is more accurate at storing a non-integer number than the previous, but results in worse performance. For financial software, the decimal type would almost certainly be used, but for many other applications the performance loss is not worth the increased accuracy. Agreeing upon which to use in particular situations would need to be decided.

The software's functions and general layout would also need to be considered. Knowing what data would need to be processed, where it would, and in what way it would, would mean that the developers could design the functions, and therefore the flow, of the program. An example of such a function is given below in JavaScript, which might appear as part of a Customer object. Although JavaScript does not have full class support, objects can be created from templates with member variables and methods.

function getFullName() {
    return this.name_first + this.name_last;
A simple flow chart showing the steps undertaken by a Blackjack game program. This was built as part of the third assignment. Descriptions of the labelled areas are given below.
  1. A message being outputted to the user.
  2. A decision being made based on user input.
  3. A decision being made based on the value of a stored variable.
  4. A decision being made based on user input, potentially causing the program to loop.
  5. The end of the program being reached, resulting in it quitting.
Image by myself; see license.

Choice of Programming Language [P2]

When a team of developers or a company decide to start a new software project, the choice of language (or potentially languages) is an important decision. There are many different factors which would affect the decision of which language to use, which are explored below.

One must consider the existing organisational policy on software development and language choice when starting a project. For example, and as mentioned briefly before, Google lists a handful of programming languages which it considers to fit its developers' needs best. By using a small number of languages within such a large business means that the there is more consistency overall. Software libraries and frameworks can be built in-house that interact with other company services, for instance, that can then be utilised a by a number of different software teams within the business. This saves time and makes for a more efficient workflow for everyone.

The resource availability must also be considered. This may tie in with the organisational policy somewhat, in that languages used throughout the company will naturally have more company-specific software built with them. Resources such as libraries, frameworks, extensions and interfaces with other languages will all be more available for a more popular language, meaning that using Ruby or Python would be a good choice for a general-purpose scripting language. As a lot of software is now made open-source, deciding to use a language that other developers world-wide frequently use can have a great effect on productivity.

The availability of developers is something must also be considered, perhaps also by the upper management as well as the developers. Using a language that has flaws but that all of the already-employed developers are familiar with and comfortable working with means that a project can be developed quicker and to a higher standard. Companies cannot always afford for their developers to be spending paid time learning to use a language they are unfamiliar with, and the quality of software written by a developer using a new language will almost inevitably be lower than usual.

Reliability and support of a language is also something to consider. A new language that has not been largely accepted and is still under heavy development would not be a good candidate for a software project intending to last a significant amount of time. By using languages that have proved to be stable and reliable for a long time, the resulting software will inherently be more supported and reliable. The C programming language first appeared in 1972, but is still the most commonly used language according to the TIOBI Index, and four of the top five languages are all C or one of its derivatives. This shows that support for the language and implementations of it is still active, and the language is a reliable choice.

The costs associated with using a particular language should also be considered. Some languages, although not many, are proprietary, and can only be used with a license. An example of this is Microsoft's ASP.NET. If a team of developers were prepared to learn and make changes to their workflow, they could transition to another language such as PHP, and therefore negate the need to pay money to deploy their software written in a particular language.

Scalability and future-proofing need to also be considered when developing large scale software projects. Using a language that shows to be modern and easy to adapt to the environment it must run in is important. Node.js, for example, brought JavaScript to the server in an accessible way for the first time, and has been a resounding success.