- SWE4202 Computing Infrastructure UOB Portfolio Assignment Answer, UK
- TM353 IT Systems: Planning For Success Assignment Sample UK
- Agile Methodologies Assignment Answer UK
CET3016 Enterprise Software Engineering Assignment 1 Sample – Sunderland
For information and reference only – not to be submitted as your own work. Use this extract to see how a CET3016 submission can link architecture, UML models and critical discussion, then build your own design, diagrams and wording from your own reasoning and your module handbook.
This model-answer extract responds to Assignment 1 of CET3016 Enterprise Software Engineering at the University of Sunderland: the analysis and design of an enterprise system for SunMortgages Ltd, a local mortgage broker that manages client records and brokers current deals from a national bank. It shows the shape of a strong answer rather than a complete submission, so each task is condensed.
Table of Contents
hide
Design position in one paragraph
The extract proposes a modular, layered web platform behind an API gateway. It uses one identity provider, role-based access control (RBAC) enforced on the server, an encrypted relational store, and a dedicated bank-integration adapter. A modular monolith is chosen over microservices because the firm is small today, yet each module has a clear boundary so that it can be split out when international expansion demands it.
Task 1: System architecture
Component table
A diagram is mandatory in the real submission. This table is the written key that sits beside it, and every row should be visible in the drawing (illustrative).
| Layer | Component | Responsibility | Security control |
|---|---|---|---|
| Client | Responsive web application (staff, customer and developer portals) | Presentation, input hints, accessibility (WCAG 2.2 AA target) | Content Security Policy, no secrets stored in the browser |
| Edge | API gateway and web application firewall | Routing, rate limiting, TLS termination | TLS 1.3, throttling, request size limits |
| Identity | Identity provider (OpenID Connect over OAuth 2.0) | Authentication, multi-factor for staff, token issue | Short-lived access tokens, refresh rotation, lockout policy |
| Application | Client Management, Mortgage Deals, Notification and Audit modules | Business rules, validation, orchestration | Server-side RBAC checks, input validation, parameterised queries |
| Integration | Bank adapter with queue and cache | Calls the bank API, maps responses, retries with back-off | Mutual TLS, secret vault, circuit breaker |
| Data | Relational database, document store, backups | Client records, deals cache, audit log | Encryption at rest, field-level encryption for identifiers, row-level ownership checks |
| Operations | Monitoring, logging, CI/CD pipeline | Availability, alerting, controlled releases | Immutable audit trail, dependency scanning |
Why this shape
The layering gives separation of concerns: the presentation tier never touches the database, and the bank is reached only through one adapter. Bass, Clements and Kazman (2021) argue that architecture should be driven by quality-attribute requirements, so each decision above is tied to one: security, availability, modifiability or scalability.
The adapter matters most. If the bank changes its API, only that component changes, which protects maintainability. If the bank is down, the cache serves the last approved deals with a visible timestamp, which protects availability.
Alternative architecture evaluated
| Criterion | Modular monolith (chosen) | Microservices (rejected for now) |
|---|---|---|
| Operational cost for a small broker | One deployable unit, low overhead | Many services, orchestration and tracing needed |
| Scalability | Scale whole application horizontally | Scale each service independently |
| Security surface | Fewer network hops to protect | More internal endpoints to authenticate |
| Expansion readiness | Module boundaries allow later extraction | Ready on day one, but paid for from day one |
The trade-off is honest: the monolith risks coupling creeping in. The mitigation is enforced module interfaces and architectural tests in the pipeline.
Buy Non Plagiarized & Properly Structured Assignment Solution
If you are still deciding how deep each diagram should go, our software engineering assignment help page explains how model answers and guidance work.
Task 2A: Sequence diagrams
Three diagrams are required. Draw them in a UML tool, label lifelines with the Task 1 component names, and use alt fragments for failure paths. The numbered table below is the message list behind the first diagram, staff retrieving customer details (illustrative).
| Step | From | To | Message | Alt or failure path |
|---|---|---|---|---|
| 1 | Staff user | Web app | Open customer record | No session: redirect to login |
| 2 | Web app | API gateway | GET /customers/{id} with bearer token | Rate limit exceeded: 429 |
| 3 | API gateway | Identity provider | Validate token signature and expiry | Invalid or expired: 401, log event |
| 4 | API gateway | Client Management | getCustomer(id, staffId) | – |
| 5 | Client Management | Access policy | isPermitted(role, action, resource) | Denied: 403 and audit entry |
| 6 | Client Management | Validator | Check id format | Malformed: 400 |
| 7 | Client Management | Database | Parameterised query | Not found: 404; timeout: 503 |
| 8 | Client Management | Audit module | Record read event | Audit failure blocks the response |
| 9 | Client Management | Web app | Customer DTO with masked fields | – |
The second diagram, a customer updating their own record, reuses steps 1 to 6 but adds an ownership check (the token subject must match the record owner) and an optimistic-lock version field to stop lost updates. The third, retrieving deals, is system-initiated: a scheduler calls the bank adapter, which authenticates with mutual TLS, handles timeout through retry then circuit breaker, validates the payload schema, then writes to the cache.
A frequent marking point: the three diagrams must use the same participants and security steps as Task 1. A diagram that skips authorisation contradicts your own architecture.
Task 2B: Class diagram
| Class | Key attributes (type) | Key methods | Relationships and multiplicity |
|---|---|---|---|
| User | userId: UUID, email: String, status: Status | authenticate(), hasRole() | 1 User has 1..* Role |
| Role | name: String, permissions: Set<Permission> | grants(action) | Role is held by 0..* User |
| Customer | customerId: UUID, type: CustomerType, address: Address | updateProfile() | 1 Customer has 0..* MortgageApplication |
| MortgageApplication | applicationId: UUID, amount: Decimal, state: AppState | submit(), withdraw() | Each application references exactly 1 MortgageDeal |
| MortgageDeal | dealId: String, rate: Decimal, term: Integer, retrievedAt: DateTime | isCurrent() | Many deals come from 1 BankProvider |
| AuditEntry | entryId: UUID, actorId: UUID, action: String, at: DateTime | – | Written for 0..* operations |
Fowler (2004) recommends keeping class diagrams at the level of detail the audience needs. Show generalisation (for example, Individual and DeveloperCompany specialising Customer) only if it changes behaviour.
Task 3 extract: 7.1 Methodology comparison
| Factor | Waterfall | Scrum | Hybrid (chosen) |
|---|---|---|---|
| Regulatory and security design | Strong up-front analysis | Risk of late security work | Security architecture fixed early, features iterated |
| Changing bank API | Costly change | Easy to absorb | Absorbed in sprints behind the adapter |
| Stakeholder feedback | Late | Every sprint | Every sprint, with gated releases |
Sommerville (2016) notes that practical projects usually mix plan-driven and agile practices rather than following one purely. The justification here is that the architecture baseline is agreed in a short initial phase, while delivery of portals and deal retrieval follows two-week sprints.
Task 3 extract: 7.3 Security and access control
Authentication uses OpenID Connect built on OAuth 2.0 (Hardt, 2012), with multi-factor authentication for staff. Authorisation uses RBAC in the tradition of Sandhu et al. (1996): staff, customer and developer roles hold permissions, and the server enforces them on every request. Attribute-based rules, as described by Hu et al. (2014), are added only for ownership, for example a customer reading their own record.
The OWASP Top 10 (2021) lists broken access control first, so the extract names server-side checks, deny-by-default and audit logging as direct mitigations. Transport uses TLS 1.3 (Rescorla, 2018). The UK GDPR and Data Protection Act 2018 shape retention, consent and data-subject access features, and international expansion adds data-residency questions.
Traceability check
| Requirement | Architecture element | Diagram or class |
|---|---|---|
| Role-based access | Identity provider, access policy | Sequence steps 3 and 5; User and Role classes |
| Bank deals | Bank adapter, cache | Sequence 3; MortgageDeal class |
| Auditability | Audit module | Sequence step 8; AuditEntry class |
Generative AI declaration (model wording)
The brief limits generative AI to brainstorming, explanation and proofreading, with no design decisions delegated. A declaration should state the tool, the purpose and the date, and confirm that all design choices are your own.
Please Write Fresh Non Plagiarized Assignment on this Topic
For a deeper walk-through of how markers read this kind of submission, see our blog on making UML diagrams consistent with your architecture, or browse the computer science assignment help and programming assignment help pages. Our university assignment help hub covers other UK institutions.
David Lee
programming and software. Holds a Bachelor’s degree in Computer Science from the University of Glasgow and has worked as a software engineer for four years. His listed skills include Java, Python, C++ and PHP, data structures, algorithms and IEEE citation style.
References
Bass, L., Clements, P. and Kazman, R. (2021) Software architecture in practice. 4th edn. Boston: Addison-Wesley.
Fowler, M. (2004) UML distilled: a brief guide to the standard object modeling language. 3rd edn. Boston: Addison-Wesley.
Hardt, D. (2012) The OAuth 2.0 authorization framework. RFC 6749. Internet Engineering Task Force. Available at: https://www.rfc-editor.org/info/rfc6749.
Hu, V.C. et al. (2014) Guide to attribute based access control (ABAC) definition and considerations. NIST Special Publication 800-162. Gaithersburg: National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-162.
OWASP Foundation (2021) OWASP Top 10:2021. Available at: https://owasp.org/Top10/2021/.
Rescorla, E. (2018) The Transport Layer Security (TLS) protocol version 1.3. RFC 8446. Internet Engineering Task Force. Available at: https://www.rfc-editor.org/info/rfc8446.
Sandhu, R.S., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (1996) ‘Role-based access control models’, IEEE Computer, 29(2), pp. 38-47.
Sommerville, I. (2016) Software engineering. 10th edn. Harlow: Pearson.
UPTO 35% DISCOUNT
