Software Engineering

Principles

Modelling

Each software system has an application domain, and it models the entities that form the system which constitutes the application domain.

Practices

See also Teaching_(Computing)

• Keep a record of the development process
  • Use something like cvs, subversion, git or whatever.
• Establish a defined and automated build process
  • Use a tool such as make or ant.
  • Distinguish between original and dependent files.
  • Do not archive dependent files.
• Build automated tests
  • Tests must run non-interactively
  • Tests must return a zero (success) exit code only if successful

Building Software

• GNU autoconf, automake, and libtool, by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor

Software Architecture

• SoftwareArchitekTOUR podcast, (German)
• cyclomatic complexity, a software metric
• Software Engineering Radio (MP3 podcasts)

Web Technologies

• EJB
• Struts
• JavaScript (aka ECMAScript)
  • A Re-Introduction to JavaScript
  • RFC 4329
• Web Sockets API
• Web Application Description Language (WADL)
• JavaScript
  • ECMAScript specification
  • Introduction to JavaScript for Java Programmers

Other Technologies and Concepts

• JavaSpaces
• Hadoop Map / Reduce
• Business Process Execution Language (BPEL) - "orchestration" of business processes
• Representational State Transfer (REST)
  • A RESTFul Web Service, an example based on del.icio.us
• OSGI
• Scala, a functional and object oriented language
• NoSQL databases
• Jetbrains Meta Programming System (MPS)

Authentication

• Acegi is an authentication framework based on Spring. Acegi Security in one hour seems like a good introduction.

Notes

Agility really is a consequence of adequate modelling. For a system that provides behaviour without internally modelling the problem domain (aka Universe of Discourse etc.), accommodating a change of requirements will likely result in large scale changes in design and implementation. In contrast, if the system is based on a detailed and highly adequate model, the extent of changes in design and implementation caused by a requirements change will correspond closely to the extent of the requirement change itself. Thus, small changes in requirements can be accommodated in an agile manner.

Somewhat metaphorically, a system that provides required behaviour without adequate internal modelling is "brittle" like a hash: If one bit in the requirements (the input) changes, all bits in the system (the hash) are subject to change.

Reusability really reflects the adequacy of a model independently of the purpose (i.e. independently of the current set of requirements).

The real use of prototoypes is that the software developers get to engage with the problem domain in a symbolic manner. It is an added benefit that prototypes provide opportunity for clients (or other non-developer stakeholders) to get to see the developing system, but (contrary to a somewhat popular view), this is not the main benefit.

Rewriting from scratch may be a bad idea, some say it's a thing you should never do or consider it harmful

Requirements Generally, requirements should not be considered as boxes that need ticking by whatever means. They are pieces of information for determining the adequate system design. If a design makes meeting the requirements easy, natural and "intuitive" from the implementors' perspective, that is a good sign that the design captures some of the essence of the application domain.