CI7250
Software Architecture and Programming Models Assessment Compendium
Assessment in CI7250 will be 100% coursework,
which is a mix of the research report (50%) including architectural aspects and
the early stages of the software development lifecycle, and the practical report including
implementation and presentation/demo (50%).
The
summary table below gives the key assessment points and dates (also in the
Module Guide) and the following pages of the booklet contain the assessment
briefs.
|
In-course assessment |
Type |
Weight |
Set date |
Due date |
Marker |
Initial Feedback |
|
Research report Practical report |
50% 50% |
29/09/20 29/09/20 |
02/11/20 |
(SK)/(JF) (SK)/(JF)/ (SB) * |
25/11/20 14/12/20 |
|
|
Examination |
|
0% |
|
|||
* Prof S.
Khaddaj (SK), Dr J. Francik (JF), Prof J. Dehmeshki (JD), Dr S. Habib (SH)
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). |
Module Learning Outcomes assessed in this piece of
coursework
·
Critically
analyse architectural styles of software systems and evaluate the role of
software architecture in the design and evolution of software.
·
Apply
the principles of software architecture construction particularly using
component and service oriented programming.
·
Evaluate
the benefits of software architectures and their corresponding programming
paradigms in terms of software quality factors such reusability, maintenance,
extendibility.
·
Apply
technical proficiency in component and service oriented analysis and design
·
Evaluate
the strengths and weaknesses of service oriented and component technologies.
Assignment Brief and assessment criteria (these will be
discussed within a formally timetabled class)
1. Assignment Brief: Analysing and Building a
Banking System Software Using Component and Service Oriented Cloud Architecture
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.
Aims and Business
Requirements
The aims are to design a new software architecture
for a banking application and to demonstrate the benefits of service oriented
approaches. This should involve the following:
1.
Critical analysis of the
various architectural styles and recommendations regarding their suitability
for the above problem.
2.
The evaluation of the
benefits of software architectures and their corresponding programming
paradigms, particularly object and service orientation, in terms of software
quality factors such reusability, maintenance, extendibility.
3.
The production of a high
level analysis and design of the chosen architecture style and the migration
steps.
4.
The identification of a
strategy for migrating to a Cloud based service architecture and technologies,
which should include a critical discussion showing the benefits and drawbacks
of the new strategy/architecture.
You are asked to address the aims and business requirements by producing a report, based on your own wider reading and research including relevant citations to recent literature, which covers:
1.
Software Architecture (20%)
This should include selection, analysis and evaluation of architectural styles based on the work undertaken in the broader subject area. This should also include some recommendations for a suitable, to the above problem, architectural style.
2.
Architecture Comparison (20%)
This should include the overview of the benefits of software architecture using software quality factors, highlighting advantages and disadvantages of two architectural styles such as object and service orientation, and a suitability analysis of the service based architecture.
3.
Analysis & Design (20%)
This should include a discussion of your analysis and design aspects decisions. It should also include requirement specification and design diagrams such as component, class and sequence diagrams.
4.
Migration Strategy and Technologies (20%)
This should include selection and reviewing potential Cloud services, mapping of a selected architecture onto the Cloud with clear migration strategy. This should also include and the potential technologies for the implementation.
5.
Report & Overview (20%)
This covers the report’s overall content, research, legal, social and ethical
issues associated with software construction, referencing, flow and structure.
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
Software
Architecture – (Student name) ( /20)
|
** |
VG |
G |
F |
P |
VP |
|
Selecting
and reviewing software architectures |
|
|
|
|
|
|
Architectural
styles and their roles |
|
|
|
|
|
|
Analysis
of component/service architecture |
|
|
|
|
|
|
Selecting and justification of two architectural
styles |
|
|
|
|
|
Architecture
Comparison - (Student name) ( /20)
|
** |
VG |
G |
F |
P |
VP |
|
High level comparison of two software paradigms |
|
|
|
|
|
|
Software
quality factors selection |
|
|
|
|
|
|
Software
quality factors analysis |
|
|
|
|
|
|
Recommendation
and conclusion |
|
|
|
|
|
Analysis
& Design (Student name) ( /20)
|
** |
VG |
G |
F |
P |
VP |
||||
|
Completeness
& quality |
|
|
|
|
|
||||
|
Selects and justifies reasonable techniques for analysis |
|
|
|
|
|
||||
|
Selects and justifies reasonable techniques for design |
|
|
|
|
|
||||
|
traceability:
from analysis to architecture design |
|
|
|
|
|
||||
Migration
Strategy & Technologies (Student name) ( /20)
|
** |
VG |
G |
F |
P |
VP |
||||
|
Selecting
and reviewing potential Cloud services |
|
|
|
|
|
||||
|
Justification
of chosen technology |
|
|
|
|
|
||||
|
Component/service
technology analysis and suitability |
|
|
|
|
|
||||
|
Migration
strategy |
|
|
|
|
|
||||
Report
& Overview - (Student name(s) ) ( /20)
|
** |
VG |
G |
F |
P |
VP |
|
Content
& referencing |
|
|
|
|
|
|
Organisation:
Report well laid out and easy to follow |
|
|
|
|
|
|
Identifies topics relevant to cwk for research |
|
|
|
|
|
|
Critically discuss legal, social and ethical
issues |
|
|
|
|
|
Overall mark (
/100)
** VG: Very Good, G: Good, F: Fair, P: Poor, VP: Very Poor
Title of Assignment: CWK Part 2: Practical report Deadline: 27/11/20
Module weighting: 50%
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.
Assignment Brief and assessment criteria (these will be
discussed within a formally timetabled class)
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
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 |
|
|
|
|
|
||||
0 comments:
Post a Comment