(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:
LEARNING OUTCOME
ASSESSMENT STRATEGY
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).
Aim
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)
**
VG
G
F
P
VP
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)
**
VG
G
F
P
VP
Functionality
Completeness
Use of service orientation
Use of Components
Use of Interfaces
Presentation/demo ( /20)
**
VG
G
F
P
VP
Quality
Presentation
Technology
Traceability: from design to code