practical report


(CWK2) – Practical Report: It contains 2 tasks: 1) Implementation (coding), 2) Presentation/demo

Module Learning Outcomes are assessed in in the research report, practical report and demo: 





Critically analyse   architectural styles of software systems and evaluate the role of software   architecture in the design and evolution of software.

Submission of research report.   To include in-depth background analysis.


Apply the   principles of software architecture construction particularly using component   and service oriented programming.

Submission of research report.   To include detailed analysis of component oriented architecture against other   architectural styles.


Evaluate the   benefits of software architectures and their corresponding programming   paradigms in terms of software quality factors such reusability, maintenance,   extendibility. 

Submission of the research   report. To cover the benefits of component software architectures in term of   software quality factors.


Critically discuss legal, social and   ethical issues associated with software construction.

Submission of the research   report. To cover the ethical, social and professional issues.


Apply technical proficiency in component   and service oriented analysis and design

The analysis and design part of   the practical report.


Evaluate the strengths and weaknesses of   service oriented and component technologies. 

Service and component   technologies evaluation part of the practical report.


Build a complex business application that   satisfies an architectural design using a service oriented component   technology.

The implementation part of the   practical report and the demonstration/presentation (practical exam).

CWK2: One zipped file named surnames_CWK2_Practical_Report which contains the code, presentation/demo, associated with CWK2, and README file containing the name of the student and their specific contributions, and any specific instructions for installation/configuration/ that might be needed.

Submission details: The second part of the coursework should be submitted as a single zipped file to canvas, and it should contain the code and the presentation.

Module Learning Outcomes assessed in this piece of coursework

· Build a complex business application that satisfies an architectural design using a service oriented component technology.

· Evaluate the strengths and weaknesses of service oriented and component technologies. 

1. Assignment Brief: Analysing and Building a Banking System Software Using Component and Service Oriented Cloud Architecture (Part 2).


The aim of the second part of the coursework is to demonstrate the knowledge and awareness of service oriented and other latest software development technologies in a given scenario. This should involve the following:

1. Apply technical proficiency in component, service and modular programming.

2. Implementation the demo system using a service oriented architecture and frameworks of your choice.

3. Produce a presentation/demonstration to discuss the used technologies and show a working prototype.

The Problem

In order to remain competitive and be able to expand its business ABC Banking Group must update its services to reflect the recent advances in information and communication technology. This will require the design and implementation of an adaptable technology migration strategy. Currently, ABC Banking Group system is a LAN based, able to be reached over the web using legacy software. Thus, the Group needs a migration strategy from a LAN based system to Cloud based system, however such a migration requires the consideration not only of the underlying Cloud service oriented architecture, and its benefits, but also should reflect the main business activities of the Group. 

At the core of the Group’s business activities is its transaction processing system. The system is used to define accounts and transactions. Accounts refer to things like customers’ bank accounts, while transactions are things like deposits and withdrawals which are essentially time-stamped records. Each account keeps track of the transactions that affect it. It also has a set of attributes such as customer’s name, address, balance, overdraft, running totals (of deposits and withdrawals) computed from the transactions etc.

Once an account is set up, it is used by creating transactions and by querying the attributes of the account. Transactions can come from other systems, like direct debits, or from different branches and they can be created by program control or can be created by a user filling out an input screen. Customers can access their account and conduct transactions using their desktops, mobile phones etc.

Your task is to design new service based architecture of the system. It is up to you how to go along the task. However, you have to take into account the distributed nature of the problem and the possibility of accessing account details, on the server, using different clients and different graphical user interfaces. These interfaces are programmed so that they communicate with the server. 

You define how an account handles transactions that are posted to it, one way of handling transactions, is by putting them in a list in order of their date. Queries can be from a simple interface, from reports such as bank statements or from programs that are creating transactions. All interactions with the system are achieved by creating transactions and querying attributes.

The system should be able to perform a number of operations including creating account for every customer, holding the customer’s name and address, allocating a numeric code (account number) for every customer, balance, cost for overdrafts, returning the statements etc. The system also should be able to add, delete customers and work out the total number of customers. 

Coursework Documentation/Report

You are asked to address the aims and business requirements by producing a practical report which covers:

Implementation (80%)

You are asked to implement and construct your application using a programming language and programming environment that supports component/service oriented paradigm.

Presentation/demo (20%)

This should include a brief discussion of of the deployed technologies  and a working prototype of your program which should demonstrate good knowledge of fundamental service/component oriented and modular concepts.

2. Feedback (including details of how and where feedback will be provided)

You will receive the feedback electronically using the feedback form (check the summary table for deadlines)

Marking scheme

Implementation: Coding Fundamentals ( /30)









Use of   OO Concepts


Use of   classes


Use of   method invocation


Use of   storage


Use of   interaction and selection


Variables/Header   box/Comments/

Implementation: Services/Components Integration ( /50)













Use of service orientation


Use of Components


Use of   Interfaces

Presentation/demo ( /20)















Traceability:   from design to code


Overall mark  ( /100)

** VG: Very Good, G: Good, F: Fair, P: Poor, VP: Very Poor