1)     Object-oriented design

Object-oriented design is an approach to software design where the fundamental components in the design represent objects with their own private state as well as represent operations rather than functions.

An object should have constructor and inspection operations allowing its state to be inspected and modified. The object provides services (operations using state information) to other objects. Objects are created at run-time using a specification in an object class definition.

Objects may be implemented sequentially or concurrently. A concurrent object may be a passive object whose state is only changed through its interface or an active object that can change its own state without outside intervention.

The Unified Modeling Language (UML) provides a range of  notations that can be used to document an object-oriented design.

The process of object-oriented design includes activities to design the system architecture, identify objects in the system, describe the design using different object models and document the object interfaces.

A range of different models may be produced during an object-oriented design process.

These include static models (class models, generalisation models, association models) and dynamic models (sequence models, state machine models).

Object interfaces must be defined precisely so that other objects can use them. A programming language such as Java may be used to document object interfaces. An important advantage of object-oriented design is that it simplifies the evolution of the system.

2)     Application Architecture

Generic models of application systems architectures help us understand the operation of applications, compare applications of the same type, validate application system designs and assess large-scale components for reuse.

Many applications either fall into one of four classes of generic application or are combinations of these generic applications. The four types of generic application covered here are data-processing systems, transaction-processing systems, event-processing systems and language-processing systems.

Data-processing systems operate in batch mode and generally have an input-process-output structure. Records are input into the system, the information is processed and outputs are generated.

Transaction-processing systems are interactive systems that allow information in a database to be remotely accessed and modified by a number of users. Information systems and resource management systems are examples of transaction-processing systems.

Event-processing systems include editing systems and real-time systems. In an editing system, user interface events are interpreted and an in-store data structure is modified.

Word processors and presentation systems are examples of editing systems.

Language-processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language. They include a translator and an abstract machine that executes the generated language.

3)     Verification and validation

Verification and validation are not the same thing. Verification is intended to show that a program meets its specification. Validation is intended to show that the program does what the user requires.

Test plans should include a description of the items to be tested, the testing schedule, the procedures for managing the testing process, the hardware and software requirements, and any testing problems that are likely to arise.

Static verification techniques involve examination and analysis of the program source code or detect errors. They should be used with program testing as part of the V & V process. Program inspections are effective in finding program errors. The aim of an inspection is to locate faults. A fault checklist should drive the inspection process.

In a program inspection, a small team systematically checks the code. Team members include a team leader or moderator, the author of the code, a reader who presents the code during the inspection and a tester who considers the code from a testing perspective.  

Static analysers are software tools that process a program source code and draw attention of anomalies such as unused code sections and uninitialised variables. These anomalies may be the result of faults in the code.

Cleanroom software development relies on static techniques for program verification and statistical testing for system reliability certification. It has been successful in producing systems that have a high level of reliability.

4)     Testing

Testing can only show the presence of errors in a program. It cannot demonstrate that there are no remaining faults.

Component testing is the responsibility of the component developer. A separate testing team usually carries out system testing.

Integration testing is the initial system testing activity where you test integrated components for defects. Release testing is concerned with testing customer releases and should validate that the system to be released meets its requirements.

When testing systems, you should try to ‘break’ the system by using experience and guidelines to choose types of test cases that have been effective in discovering defects in other systems.

Interface testing is intended to discover defects in the interfaces of composite components.

Interface defects may arise because of errors made in reading the specification, specification misunderstandings or errors or invalid timing assumptions. 

Equivalence partitioning is a way of deriving test cases. It depends on finding partitions in the input and output data sets and exercising the program with values from these partitions. Often, the value that is most likely to lead to a successful test is a value at the boundary of a partition.

Structural testing relies on analysing a program to determine paths through it and using this analysis to assist with the selection of test cases.

Test automation reduces the costs of testing by supporting the testing process with a range of software tools.

5)     Project management

Good software project management is essential if software engineering projects are to be developed on schedule and within budget.

Software management is distinct from other engineering management. Software is intangible. Projects may be novel or innovative so there is no body of experience to guide their management. Software processes are not well understood.

Software managers have diverse roles. Their most significant activities are project planning, estimating and scheduling. Planning and estimating are iterative processes. They continue throughout a project. As more information becomes available, plans and schedules must be devised.

A project milestone is a predictable outcome of an activity where some formal report of progress should be presented to management. Milestones should occur regularly throughout a software project. A deliverable is a milestone that is delivered to the project customer.

Project scheduling involves the creation of various graphical plan representations of part of the project plan. These include activity charts showing the interrelationships of project activities and bar charts showing activity durations.

Major project risks should be identified and assessed to establish their probability and the consequences for the project. You should make plans to avoid, manage or deal with likely risks if or when they arise. Risks should be explicitly discussed at each project progress meeting.

6)     Service-oriented software engineering

Service-oriented software engineering is based on the notion that programs can be constructed by composing independent services that encapsulate reusable functionality.

Services are language independent and their implementation is based on widely adopted XML-based standards.

Service interfaces are defined in an XML-based language called WSDL. A WSDL specification includes a definition of the interface types and operations, the binding protocol used by the service and the service location.

Services may be classified as utility services that provide some general-purpose functionality, business services that implement part of a business process or coordination services that coordinate the execution of other services.

The service engineering process involves identifying candidate services for implementation, defining the service interface and implementing, testing and deploying the service.

 Service interfaces may be defined for legacy software systems that continue to be useful for an organisation. The functionality of the legacy system may then be reused in other applications.

The development of software using services is based around the idea that programs are created by composing and configuring services to create new composite services.

Business process models define the activities and information exchange that takes place in some business process. Activities in the business process may be implemented by services so that the business process model represents a service composition.

Techniques of software testing based on source-code analysis cannot be used in service- oriented systems that rely on externally provided services.

7)     Aspect- oriented software development

The principal benefit of an aspect-oriented approach to software development is that it supports the separation of concerns. By representing cross-cutting concerns as aspects,

these concerns can be understood, reused and modified independently.

Tangling occurs when a module in a system includes code that implements different system requirements. The related phenomenon of scattering occurs when the implementation of a single concern is scattered across several components in a program.

Aspects, include a pointcut—a statement which defines where the aspect will be woven into the program and advice—the code to implement the cross-cutting concern. Join points are the events that can be referenced in a pointcut.

To support the separation of concerns, systems can be designed as a core system that implements the primary concerns of stakeholders and extensions that implement secondary concerns.

To identify concerns, you may use a viewpoint-oriented approach to requirements engineering to elicit stakeholder requirements and explicitly identify the cross-cutting quality of service and policy concerns.

The transition from requirements to design can be made by identifying use-cases, where each use case represents a stakeholder concern. The design may be modelled using an extended version of the UML with aspect stereotypes.

The problems of inspecting and deriving tests for aspect-oriented programs are a significant barrier to the adoption of aspect-oriented software development in large software projects.