Applying Software Architecture Concept to Design Single Window for Modifiability

Transcription

1 Applying Software Architecture Concept to Design Single Window for Modifiability Somnuk Keretho Director, Institute for IT Innovation Kasetsart University, Thailand Conférence Internationale sur les Guichets Uniques: «Guichet unique virtuel du commerce extérieur : L'exigence d'une collaboration inclusive» SWC2016

2 In this presentation «Changes» in Trade Facilitation & Single Window functionalities could not be avoided, e.g. because of new regulations, new functional requirements, new electronic documents, and new extensions. How to design and implement SW with the Modifiability quality (i.e. easier, faster, less cost to change)? Suggestion (among several measures): Applying Software Architecture, Tactics and Design Patterns to improve modifiability* * Ref: Modifiability Tactics, F. Bachmann, L. Bass and R. Nord, 2007 (CMU/SEI Technical Report) 2

3 Modifiability is about the cost & time of making changes To plan for modifiability, a designer has to consider four questions: What can change? What is the likelihood of the change? When is the change made and who makes it? What is the cost of the change? One cannot plan a system for all potential changes therefore, risk-driven design* is recommended (based on the answers of the above questions). * Ref: Just Enough Software Architecture A Risk-driven Approach, George Fairbanks,

4 Modifiability Generic Scenario (1/3) Source Government Mandate, New Law/Regulation, Authorized End Users, and Developers request or introduce a change to the system. Stimulus A directive to Add/delete/modify functionality Modify quality attributes Modify platform, technology Operate in a new environment, new users Scale up and scale out Artifact Code, data, interfaces, components, resources, configurations, * Ref: Modifiability Tactics, F. Bachmann, L. Bass and R. Nord, 2007 (CMU/SEI Technical Report) 4

5 Modifiability Generic Scenario (2/3) Environment 5

6 Modifiability Generic Scenario (3/3) Response Make, test and deploy the modification Response measures Number of affected artifacts Size of the change Effort & time Cost (direct or opportunity cost) Number of other functions or quality attributes affected by the change New defects introduced 6

7 Modifiabililty Generic Scenario Artifact Code, Data, Interfaces Components, Resources, Configs.. Source - Gov Mandate - New Law - End User - Developer - Sys admin Stimulus Modify: - Functions - Qualities - Platform - Technology - Scale/Scope Environment - Design - Build - Deploy - Runtime Response - Change, - Test - Deploy Measure - # of artifacts - Effort - Time - Cost - Impact - New defects 7

8 Example: A Modifiability Concrete Scenario A developer wants to change the UI code (e.g. change an input field to a pick list) at design time; the modification is made without side effects in 3 hours. 8

9 Understanding Modifiability The modifiability of a system is determined by: Coupling: Modules in systems have different responsibilities. If the responsibilities of modules overlap, a single change request may impact multiple modules. The probability that a modification to one module will propagate to another is called coupling. Coupling is an inter module characteristic and is the enemy of modifiability: therefore, low coupling is good. Cohesion: Cohesion measures how much the responsibilities of a module are related. The cohesion of a module is the probability that a change request to one responsibility will impact another one. Cohesion is an intra-module characteristic, therefore, high cohesion is good. 9

10 Modifiability Tactics Change Request Arrives Tactics to Control Modifiability Changes made, Tested and Deployed on Time, within Budget Reduce Module Size, e.g. by splitting modules Increase Cohesion, e.g. abstract common services, increase semantic cohesion Reduce Coupling, e.g. encapsulation, restrict communication paths, use an intermediary Defer Binding Time, e.g. commit as late as possible 10

11 Some Recommended Architectural Patterns & Tactics* The Model-View-Controller (MVC) architectural pattern divides an interactive application into three components. The Model contains the core functionality, data and state. Views is the user interface component. It produces a representation of the model and can handle input. Controllers manage the interaction between the model and the view ensures consistency between. Used in: Java Spring Framework, Django Framework, ASP.net * Many other architecture patterns are not described in this presentation. 11

12 MVC Tactics analyzed: The Model-View-Controller pattern implements the following tactics: Maintain Semantic Coherence: According to the definition, the model component contains the functional core of the application, requiring all the necessary responsibilities for those concepts to be located within the model. Encapsulation: The model component encapsulates the functional core data and functionality. Use an Intermediary: The controller acts as an intermediary between the view and the model. Use Runtime Binding: Views can be opened and closed dynamically, and different views can be bound to the data at different times during execution. 12

13 The Layers Pattern The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction The pattern consists of a number of layers. Layers are partially ordered with respect to the uses relationship. A layer may only use lower level layers in the partial order. 13

14 Layers Pattern 14

15 Case Example: SOLAS Container Weight Verification Requirement International Maritime Organization (IMO) has amended the Safety of Life at Sea Convention (SOLAS) the container must have a verified weight (for loading a packed container onto a ship for export) Legally effective on July 1, Basic Principles: Before a packed container loaded onto a ship, its weight must be determined through weighting. Two permissible weighting methods: 1) weighting the container after it has been packed, 2) weighting all cargo and contents of the container and adding those weights to the container s tare weight. Estimating weight is not permitted. A carrier may rely on a shipper s signed weight verification to be accurate. 15

16 As-Is Process of Paperless Customs Declaration & e-container (Goods control list) Thailand Case 1 3 Submit e-container 4 Validate e-container with Submit e-export Declaration e-export Declaration Freight Agent (on behalf of the Exporter/Shipper) 2 Generate Declaration ID 6 NSW Submit and Validate Container NO./ Declaration ID Customs Officer 5 Verify Container NO. Container truck Customs gate * Digital Signature is already used by the Freight Agents/Customs Agents for identity authentication. 16

17 Thailand Case To-Be Process of Paperless Customs Declaration & e-container with new SOLAS Container Weight Verification Exporter/Shipper 4 Submit/declare VGM* (Verified Gross Mass) Carriers 8 Receive the signed weight verification 8 Receive the signed weight verification Terminal Operator 3 1 Submit e-container Submit e-export Declaration Freight Agent (on behalf of the Exporter/Shipper) 2 Generate Declaration ID NSW 7 5 Validate e-container with e-export Declaration Customs Officer Submit and Validate Container NO. and Declaration ID 6 Verify Container NO. Container truck The change in new processes and data requirement (e.g. only one data element, CGM, is added) is very minimum. Customs gate 17

18 Conclusion New regulations, new functional requirements, new electronic documents, and new extensions to the Single Window for better trade facilitation environment should be encouraged Government mandate and regulations help accelerate the development SW must be designed and implemented for future change and enhancement For any new requirements, the As-Is Analysis and To-Be Design of both Processes & Data must be carried out, along with legal and security issues Software architecture concept, e.g. design tactics and architectural patterns, among other measures, should be used to design for Modifiability. 18

19 Thank you Somnuk Keretho, PhD Director, Institute for IT Innovation Kasetsart University, Thailand