Please enable JavaScript.
Coggle requires JavaScript to display documents.
COMP23412 Software Engineering II - Coggle Diagram
COMP23412 Software Engineering II
Web Frameworks
Model-View Controller
An architectural software design pattern which is used to implement user interfaces, providing a complete framework to build software
MVC Components
The components are used to separate internal representations of information from the ways they are presented to the user
Model
Central component, the appplications data structure, independent of the UI
Contains and manages the data, logic and rules of the application
Implemented as a database with application specific transformations
View
Represents the data in the model to the user
Desirable to have multiple views of the data
It acts as a presentation filter, getting necessary data by asking questions
Controller
Accepts inputs and passes it on as commands to the view or model
Thought of as the machinery of the UI, but independent
Editor
A special controller that permits the user to modify the information presented
Spliced into the path between the controller and its view, and is removed once editing is done.
In practice
The controller can use user input to update the model and view, while the model notifies the contoller of changes and the view lets the controller know about user action
This is a good reason to use the controller in this way as the user requests responses in a particular format. It has that information so can apply a particular view to a response
Mapping MVC to the real world
It is messy and requires a lot of trade-offs, removing complexity from you and the system but concepts are taken fro granted
Designing the User Interface
From requirements to design
When we have the requirements we have to divide them into:
What? Functional requirements
How? Non-functional requirements
User stories and use cases are elaborated into scenarious and visual designs ahead of implementations
We leave out details to capture the main idea and scope of the application
This is useful to expose flaws and misunderstandings
The same functional requirements can end up in different designs
Different fidelity levels
Paper sketches - fast, allows ideas to be shown, flexible and shareable
Wireframes - more elaborate, aranges content on the website
Mock-ups - allow us to define the layout and arrange information on the screen. Can add user interface controls and transitions
Prototypes - custom-hard solutions, so not fully interactive but are close to what we are lookin for
Why mock-ups
Stimulates a dialogue with the customer, confirming requirements capture and an exchange of ideas
Saves time by preventing misunderstandings, and removing bugs early
Guidelines for user interface design
Ben Shneiderman's 8 golden rules
Generic enough to be used 30 years later as they are not for a specific technology, but that is their weakness as it is difficult to transfer to particular examples
Strive for consistency
Can be used for malign purposes, as with boosted learnability, the user may click on a button they don't intend to
Consistent sequences of actions, identical terminology, consistent layout, colour, font
Seek universal usability
Users, devices, situations
Adding features for novices and experts enriches the inteface design and improves percieved quality
Offer informative feedback
Say what happened and why
Suggest a next step
Find the right tone
Design dialogues that bring closure
Make sure the user knows the task is complete
Prevent errors
Design the interface so that the users cannot make serious errors, and if they do, there are simple, specific instructions for recovery
Permit easy reversal of action
As errors can be undone, this encourages exploration of unfamiliar options
Keep users in control
Experienced users desire the ense that they are in charge of the interface. They do not want surprises or changes or tedious data-entry
Reduce short-term memory load
Avoid interfaces in which the user must remebr information from one display and use it in another
Dark Patterns: Past, Present and Future
Dark patterns are user interfaces that benefit an online servive by leading users into making decisions they might not otherwise make through deceit or manipulation. These include nagging, obstructing the flow of a task ad setting privacy intrusive defaults.
They are the result of three trends
Deceptive practices from the world of retail
Psycological pricing - making the price slightly less than a round number so that consumers underestimates the price when relying on memory
False claims of store closings
Nudging from research and public policy
Origins - businesses may be able to nudge customers to pay more by anchoring their expectations to a higher number
'Governments, employers and other benevolent institutions should engineer choice architectures to benefit those whom they serve or employ'
Businesses have adopted these techniques in an adversarial way
Growth hacking from the design community
Users advertising on behalf of the company
Growth hackers are trained in design, programming and marketing, using these skills to drive product adoption.
Growth is prioritised due to a growth-first then revenue-generating mantra
A/B testing is used to gauge how revenue production changed with variations of website. The online experiments allow dsigners to find answers to design problems with a few lines of code
Money, Data, Attention
Services used the principles of behavioural influence in ways that indermined the customer's autonomy and informed choice.
Dark patterns nudge customers to spend more than they otherwise would, invade privacy and try to make services addictive
Recommendations for Designer
To hold yourself and organisations to a higher standard you can
go beyond superficial A/B testing metrics, evaluating them on at least one metric that measures long-term impacts
Incorporate ethics into the design process
Self-regulate or get regulated
Data Modelling
Data persistence - or storage - is key if we are going to be able to store anything to use later.
We can annotatae Plain Old Java Objects - POJOs - for persistence e.g.
Entity
Table
(name = "venues")
You can tell Spring primary keys using
Id
and use the
GeneratedValue
annotation to allow Spring to generate the key for you when the model is saved.
Spring abstracts away the implementation details of the database layer. We add a Service layer to get data from the repository and keeps our business logic so that all our repository does is talk to our database. These two together make the model.
As we do not know how Spring implements the underlying repository code, we use the
Autowired
annotation to allow Spring to find and initialise the correct one.
Spring also provides the CRUD repository implementation: Create, Read, Update, Delete
It has a mechanism to convert method names into fully implemented queries, such as find and OrderBy
We also add a service interface to manipulate the data so that we implement Separation of Concerns
Security and Privacy
Security in Web Application
Motivation
We want to protect assets from potential vulnerabilities against potential threats/attackers
Top 10 Security Risks
Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities
Broken Access Control
Security Misconfiguration
Cross-site Scripting
Insecure Deserialisation
Using Componnets with known Vulnerabilities
Insufficient Logging and Monitoring
Authentication
The process of confirming a user's identity, protecting against spoofing identity attacks
Credentials provided by users are compared to those held in a secure user database
Credentials are based on who we are (biometrics, fingerprints, face recognition), what we know (username, password/PIN) and what we have (RFID card, USB token, One-time password token)
2FA is when these are used in combination
We make authentication secure by using a hashed salt to store sensitive data in the database, as just hashing can lead to the hash code being cracked
Authorisation
The process of specifying access rights/privileges to resources, protecting agains privilege escalation attacks. This is usually through role-based authorisation.
Example roles
Admin - cann access everything
HR staff - can access employee records; other relevant documents
Staff - can see own employee record
Guest - very limited access; authentication generally not used/required
Injection attacks
An attacker injects untrusted input which gets processed as part of a command or query e.g. cross-site request forgery, cross-site scripting, SQL injection
It happens because of insufficient user input validation and can be avoided by restricting, controlling and monitoring any form of user input.
Implementing security in Spring
Authentication, Authorisation and CSRF Protection is supported in Spring
Web Application Security Engineering
Approaches that don't work
Bolt-on - ignores security until the end
Do-it-all-upfront - addresses upfront, gets overwhelmed, feeling all bases are covered and not touching it again
Big-bang - depend on a single effort, technique or activity
Buckshot - trying a bunch, hoping to get the right one, not knowing the target
All-or-nothing - caused by over-reacting to failure and taking on too much at once and doing nothing
The approach that works
Baking security into the application's life cycle
Addressing security throughout development to balance it with other quality attributes
To find the techniques to use to shape your software, start with high ROI activities
Security enineering baseline activities
objectives - helps set boundaries and constraints for softwares security
threat modelling - helps inform and rationalise key decisions
design guidelines - use proven software security design principles, practives and patterns
architecture and design review - factors security into its own review, using a question driven approach
code review - determining if the code meets the security objectives
testing - third-part penetration testing
deployment review - to assess the final end game, before actual deployment
Making security activities more effective
You can use the web application security frame to organise recurring issues
input and data validation
authentication
authorisation
configueation management
cryptography
sensitive data
exception management
session management
auditing and logging
Context precision
If you increase the context and precision, factoring that into your technique, you can deepen your impact
Categories for context
application type
deployment scenario
project type
life cycle
Privacy in Web Applictions
We look at Hoepmen's eight privacy design strategies
Minimise
Limit as much as possible the procesing of personal data
Nothing can go wrong with data you do not collects
Tactics: Select, Exclude, Strip, Destroy
Separate
Separate the processing of personal data, making it harder to combine or correlate data
Tactics: Isolate, Distribute
Abstract
Limit as much as possible the detail in which personal data is processed
Tactics: Summarise, Group, Perturb
Hide
Protect personal data, or make it unlinkable or unobservable
Tactics: Restrict, Obfuscate, Dissociate, Mix
Inform
Inform users about the processing of their personal data in a timely and adequate manner
Tactics: Supply, Explain, Notify
Control
Provide users adequate control over the processing of their personal data
Tactics: Consent, Choose, Update, Retract
Enforce
Commit to processing personal data in a privacy-friendly way, and adequetely enforce this
Tactics: Create, Maintain, Uphold
Demonstrate
Demonstrate you are processing personla data in a privacy-friendly way
Tactics: Record, Audit, Report
There are the data-oriented strategies that focus on the privacy-friendly processing of data - minimise, separate, abstract, hide
There are also the process-orinted strategies which focus on the process surrounding the reponsible handling of personal data - inform, control, enforce, demonstrate
The typical order of the security by design approach is identify assets, perform threat modelling, choose mitigation techniques, design and test
Specification by example helps to reduce the ambiguity of requirements
Testing functionality in Isolation
Testing Functionality in Isolation
Unit tests do not build on other tests and test exactly one thing, staying within class values, so we must break some of the connections and make test doubles
Test doubles
Dummy - passed but never used
Fake - works as expected through shortcuts
Stub - provides a canned answer to a particular invocation
Mock - preprogrammed expectations to how it will be called and what will happen internally
Introduction to software testing
Software testing is a process by whcih software functionality and quality is assessed
Validation
Have we built the right software
Does it fill the user's requirements
Verification
Have we built the software right
Is it free of defects and failures
Defects and failures
Not all software defects are coding errors, they can be requirement gaps and non-functional (scalability, usabiity and performance)
Not all software defects result in failure due to luck or just dead code
A defect could be a wrong or missing function in the code
Failure is the manifestation of a defect during execution
Testing methods
Static and dynamic analysis
Static analysis is testing without running the code e.g. code review, walkthrough
Dynamic analysis is testing the code through a test suite
Black-box and white-box testing
White-box is testing the internal functions and structures
Black-box is where we examine the functionality in the round wth no knowlege of the internals
Testing software at different levels
Levels of testing
Unit - makes sure that the code worls in isolation
Integration - make sure that larger blocks of code work correctly
System - ensure the system is function correctly from end to end
Acceptance - test from the perspective of the user
Regression - used to catch bugs and defects throughout the development processes and during maintenance
Benefits of unit testing for agile
Find problems early: code is still in development so it is easy and cheap to fix
Issues can be caught before handovers
They facilitate refactoring and simplify integration while providing documentation
Limitations of unit testing
You cannot test all execution paths in a program or non-deterministic functions
They may also contain bugs
Testing matrix
Flaky Tests
Flaky tests are tests that cause spurious failures without any code changes
They hamper regression testing, increase maintenance, shadow real bugs and decrease trust in tests
Reasons for flakiness
Order dependency
Infrastructure problems
Network randomness and APIs
Types of flakiness
Async wait, concurrency, test order dependency, resource leak, network time, IO, randomness, FP Operations, unordered collections, too restrictive range, test case timeout, platform dependency, test suit timeout
There are victim tests have polluter tests that disturb their execution.
There are brittle tests that require a state-setter test
Using External APIs
Where to start?
You must consider what you are looking for, if there is documentation provided and if it is of good quality
You must also consider your needs e.g a community that will support, any usage quotas
Looking for the right functionalities is a search problem
Programming by example
We reuse existing code on our code, finding analogies and seeing the code as a template
There are two antagonistic strategies
Copy and paste and try to make it work until it does
Try to undertand the whys and hows
Providing a REST API
RESTful Web Services
Rest is an architectural style that can be implemented in many different ways and is the underlying principle in the WWW
Clients can operate without knowing anything about the server or resources it hosts as long as they agree on the media use
Implementing REST with HTTP
Resources are manipulated with the HTTP verbs i.e. POST, GET, PUT, DELETE and these map to CRUS
They rely on the fact that verbs are idempotent (GET, PUT and DELETE are free from side-effects)
Provide responses that are self descriptive and link to other resources as necessary (Hypermedia As The Engine Of Application State)
Features of REST
Resources identified by a persistent identifier - URI
The representation retrieved for a resource is dependent on the request and not the identifier
Maintain state in the object and display that state in the representation
Embed the relationsjips between resources in the repreesentation of the resource
Resource repesentations describe how the representation can be used and under what circumstances it should be discarded/re-fetched in a consistent manner
HATEOAS in Spring
If you use
Entity
and Crud Repository Spring can serve your data automatically in JSON format and provide links where needed
If an API is designed according to RESTful architectural principles, the server must provide responses that are self-descriptive
Representational State Transfer
Deriving REST
Starting with the Null Style - building from nothing, or applying constrainst to the whole system. There are no distinguished boundaries between components
Client-Server - Separate UI concerns from data storage, improving portability
Stateless - communication must be stateless in nature, requests have all necessary information for visibility, reliability and scalability
Cache - client-cache-stateless-server, improves network efficiency and eliminates interactions
Uniform interface - architecture is simplified and visibility of interactions is improved, but degrades efficiency
Layered System - allows an architecture to be composed of hierarchical layers so components cannot see beyond layers, but adds overhead and latency to data processinf
Code-On-Demand - can donwload and execute code in applets and scripts
REST Architectural Elements
REST is an abstraction of the architectural elements within a distributed hypermedia system
Data Elements
Information needs to be moved to the location where it will be used by a reader
The architect has three options: render the data where it is located and send a fixed format, encapsulate the data with a rendering engine and send both, or send the raw data and metadata so the recipient can choose its own engine
REST is able to hybrid these, gaining separation of concers and server scalability with information hiding
Connectors
Connectors are used to encapsulate the activites of accessing resources and transferring resource representations
The stateless ness acomplishes the removal of application state retention, interactions can be processed in parallel, an intermediary can view and understand requests and information that might factor into the reusability of a cache response to be present in each request
There are client, server and cache connector types
Components
REST components are typed by their roles in overall application action
Intermediary components act as both client and server to forward requests and responses
A proxy/gatewat component is an intermediary selected by a client to provide an interface encapsulation of other services etc
REST Architectural Views
Process View - effective at eliciting the interaction relationships among components by revealing the path of data though a system
Connector View - concentrates on the mechanics of the communication between components
Data View - reveals the application state as information flows through the components
