Software Design Principles Lecture Notes PDF

SOFTWARE DESIGN PRINCIPLES ICT2112 SOFTWARE DESIGN - TOPIC 2  SUPPLEMENTARY READING Software engineering design, Carlos Otero, Chapter 1 (Software Design Fundamentals) SIT ICT2112 - TOPIC 2 - AY24/25, T2 2 ...

SOFTWARE DESIGN PRINCIPLES ICT2112 SOFTWARE DESIGN - TOPIC 2  SUPPLEMENTARY READING Software engineering design, Carlos Otero, Chapter 1 (Software Design Fundamentals) SIT ICT2112 - TOPIC 2 - AY24/25, T2 2  LIBRARY BOOKS BORROWING SYSTEM Assuming that you are part of a team to design and develop the library's books management system for the university's library. How would you begin? SIT ICT2112 - TOPIC 2 - AY24/25, T2 3  STAGES OF SOFTWARE DESIGN Understanding and analysing the problem Identify solutions: one or more Describe abstract solutions Commonly using graphical, formal or other descriptive notation to describe the components of the design Repeat the process for each identified abstraction until the design is expressed in primitive terms SIT ICT2112 - TOPIC 2 - AY24/25, T2 4  LEVELS OF SOFTWARE DESIGN 1)The Software system 2)is first organised into subsystems. 3)The subsystems are further divided into classes, and 4)the classes are divided into routines and data. 5)The inside of each routine is also designed McConnell, S., & Mcconnell, S. (2004). Code Complete. In Code Complete. Microsoft Press. SIT ICT2112 - TOPIC 2 - AY24/25, T2 5 SOFTWARE DESIGNING ANXIETY SIT ICT2112 - TOPIC 2 - AY24/25, T2 6  What is Complexity? Anything related to the structure of a software system that makes it hard to understand and modify the system. Complexity can take many forms. It might: not be clear be hard to take a lot of effort be difficult to fix which parts of the understand how to implement a one bug without system must be a piece of code small introducing modified to make works improvement another the improvement SIT ICT2112 - TOPIC 2 - AY24/25, T2 7 SIT ICT2112 - TOPIC 2 - AY24/25, T2 8  STRUCTURING THE SOLUTION After you have drafted your approach to the solution to address the problem and requirements, you need some way to formalise and organise your concepts so that the design of your approach can be evaluated and refined and accepted by the stakeholders. SIT ICT2112 - TOPIC 2 - AY24/25, T2 9 HOW DO YOU BEGIN IF… the client wants scalability? you want to divide the work (short turn around time)? you have coupling issues in your design? SIT ICT2112 - TOPIC 2 - AY24/25, T2 10  Software architecture requirements are not the only functional requirements SIT ICT2112 - TOPIC 2 - AY24/25, T2 11 The software architecture drivers define the what and why about the architecture. They include: 1. Primary functionality 2. Design purpose 3. Quality attributes (let’s look at what are these) 4. Architectural concerns 5. Architectural constraints SIT ICT2112 - TOPIC 2 - AY24/25, T2 12 MICROSOFT QUALITY ATTRIBUTES Usability: How well the application meets the requirements of the user and consumer, resulting in a good overall experience. User Availability: Defines the proportion of time that the system is functional and working. Performance: Indication of the responsiveness of the system. Reliability: The ability of the system to remain operational over time Quality Run-time Scalability: Ability of a system to handle increasing load or to be readily enlarged. Attributes Security: Capability of a system to prevent malicious or accidental actions Conceptual Integrity: Defines the consistency and coherence of the overall design Maintainability: Ability of the system to undergo changes with a degree of ease. Design Reusability: The capability for components and subsystem to be suitable for use in other applications and in other scenarios. Testability: How easy it is to test the application SIT ICT2112 - TOPIC 2 - AY24/25, T2 13 GENERAL DESIGN PRINCIPLES GENERAL DESIGN PRINCIPLES 1. Modularisation 2. Abstraction 3. Encapsulation 4. Coupling 5. Cohesion 6. Separation of interface and implementation 7. Sufficiency 8. Completeness SIT ICT2112 - TOPIC 2 - AY24/25, T2 15  PRINCIPLE #1: MODULARISATION Modularisation is the process of continuous decomposition of the software system until fine-grained components are created. When you modularise a design, you are also modularising the requirements, SIT ICT2106 ICT2112 - TOPICprogramming and test cases. WEEK 2 - AY21/22, AY24/25, T2 16  DESIRABLE PROPERTIES FOR DECOMPOSITION Check relationships between concepts and components for: Cohesion: The reason that elements are found together in a module – Not critical but useful. Coupling: Strength of interconnection between modules – hierarchies and couplings of modules are there for the sake of being there. Complexity Correctness: Formal and appropriateness for the solution. Very difficult to justify usually due to perspective. Correspondence: The mapping between the problem, solution, requirements, design and implementation. SIT ICT2112 - TOPIC 2 - AY24/25, T2 17  DECOMPOSITION STRATEGIES Information hiding ▪ Make anticipation of areas in your code that changes ▪ Areas that changes frequently in an implementation is best dealt with in isolation. ▪ This technique allow the semantics of a module to remain unchanged when implementations are replaced. Layering ▪ Focusing on information hiding modules is not enough. ▪ Consider the concepts of abstract machines. SIT ICT2112 - TOPIC 2 - AY24/25, T2 18  PRINCIPLE #2: ABSTRACTION Abstraction is “a view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information” SIT ICT2112 - TOPIC 2 - AY24/25, T2 19  ABSTRACTION Abstraction can be employed to extract essential characteristics of: Procedures Data or behaviour SIT ICT2112 - TOPIC 2 - AY24/25, T2 20  PROCEDURAL ABSTRACTION Simplifies reasoning about behavioural operations containing a sequence of steps SEND (client, server, message) 1. Client retrieves the server’s information, 2. opens a TCP/IP connection, 3. sends the message, waits for response, and 4. closes the connection SIT ICT2112 - TOPIC 2 - AY24/25, T2 21  DATA ABSTRACTION Simplifies reasoning about structural composition of data objects SEND(client, server, message) MESSAGE is an example of the data abstraction; the details of a MESSAGE can be deferred to later stages of the design phase. SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 22  MODULARISATION & ABSTRACTION EXAMPLE Assuming you are part of a team developing a library books management system. Your task is to design and develop the user rights management module. Where do you start? On your own, try to use the design principles of modularisation and abstraction to design your part on user rights management. SIT ICT2112 - TOPIC 2 - AY24/25, T2 23  MODULARISATION & ABSTRACTION EXAMPLE Assuming you are part of a team developing a library management system. Your task is to design and develop the user rights management. Where do you start? Gather requirements Modularisation ▪ Identify the types of roles a user play. E.g., librarian, user, types of students, etc. ▪ List down what are the rights intended to be assigned to different users ❖ Ask your 5 Whys ❖ Why can a user include a new book? ❖ Why can a user wave a fine?.... SIT ICT2112 - TOPIC 2 - AY24/25, T2 24  MODULARISATION & ABSTRACTION EXAMPLE Assuming you are part of a team developing a library management system. Your task is to design and develop the user rights management. Where do you start? Abstraction ▪ Group users with common rights together ▪ Group rights based on user roles ▪ Identify if there are new roles introduced from the groupings ▪ Discuss with your stakeholders about your findings ▪ Work out categories for your decisions ▪ Refine your design with your new categories SIT ICT2112 - TOPIC 2 - AY24/25, T2 25  MODULARISATION & ABSTRACTION EXAMPLE Assuming you are part of a team developing a library management system. Your task is to design and develop the user rights management. Where do you start? Try the exercise again during your own time to use the design principles of modularisation and abstraction to design your part on user rights management. SIT ICT2112 - TOPIC 2 - AY24/25, T2 26  PRINCIPLE #3: ENCAPSULATION Encapsulation deals with providing access to services of abstracted entities by exposing only the information that is essential to carry out such services while hiding details of how the services are carried out. Information hiding: Internal details (state, structure, behaviour) become the object’s secret SIT ICT2112 - TOPIC 2 - AY24/25, T2 27  ENCAPSULATION & INFORMATION HIDING One can think of information hiding as the principle and encapsulation as the technique Encapsulation is the public interface that defines how an object can be used, and how its data is derived. Information Hiding prevents an external object from using the derived data altogether SIT ICT2112 - TOPIC 2 - AY24/25, T2 28  Fence up to protect what is in it SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 29  ENCAPSULATION & INFORMATION HIDING class Automobile extends Vehicle { public final static int EMPTY = 0; public final static int FULL = 1; public int tank = EMPTY; } Neither Encapsulation nor Information Hiding SIT ICT2112 - TOPIC 2 - AY24/25, T2 30 ENCAPSULATION & INFORMATION HIDING class Automobile extends Vehicle { public final static int EMPTY = 0; public final static int FULL = 1; The status of the tank private int tank = EMPTY; is now encapsulated, but NOT HIDDEN public int getTankStatus() { from the rest of the return this.tank; } system. public void setTankStatus( int status ){ this.tank = status; } } SIT ICT2112 - TOPIC 2 - AY24/25, T2 31  class Automobile extends Vehicle { private final static int EMPTY = 0; private final static int FULL = 1; A simple interface fully private int tank = EMPTY; Encapsulates and Hides Information: fillUp() and private int tank() {…} depleteOzone(). private void tank( int status ) {…} No other object in the public void fillUp() { tank( FULL ); system can use, or know } the state of, the gas tank. public void depleteOzone() throws GasExhaustedException { if( tank() == FULL ) { tank( EMPTY ); } else { throw new GasExhaustedException(); } } } SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 32 class Loan{ private int duration; //private variables examples To encapsulate the Loan creation logic, create a of encapsulation method, say createLoan(). This method creates private String loan; private String borrower; Loan object internally. In this case, you only need private String salary; to modify createLoan() method instead of all //public constructor can break encapsulation instead client code. use factory method private Loan(int duration, String loan, String borrowe Notice that you can see all member variables that r, String salary){ are made private, so they are well encapsulated. this.duration = duration; You can only change or access the variables this.loan = loan; this.borrower = borrower; directly inside this class. this.salary = salary; } If you want to allow the outside world to access //no argument constructor omitted here these variables, how would you implement it? // create loan can encapsulate loan creation logic Create a getter and setters like the getLoan() that public Loan createLoan(String loanType){ allows you to do any kind of validation, security //processing based on loan type and then returning check before return loan so it gives you complete loan object control of whatever you want to do and a single return loan; channel of access for the client which is } controlled and managed. } Source: https://javarevisited.blogspot.com/2012/03/what-is- encapsulation-in-java-and-oops.html SIT ICT2112 - TOPIC 2 - AY24/25, T2 33  MODULARIZATION, ABSTRACTION & ENCAPSULATION Focus on essential Enforce that we only expose characteristics of entities essential information SIT ICT2112 - TOPIC 2 - AY24/25, T2 34  PRINCIPLE #4: COUPLING Refers to the manner and degree of interdependence between software modules. Measurement of dependency between units. Understanding the level of coupling between objects help us make more informed decision to effectively reduce the coupling between them. The The higher higher the the coupling dependency SIT ICT2112 - TOPIC 2 - AY24/25, T2 35 COUPLING: DEGREE OF DEPENDENCE AMONG COMPONENTS No dependencies Loosely Highly coupled-some coupled- dependencies many dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 component is connected 36  LEVEL OF COUPLING Content Common Control Stamp Data TIGHT COUPLING LOOSE COUPLING More interdependency Less interdependency More coordination Less coordination More information flow Less information flow SIT ICT2112 - TOPIC 2 - AY24/25, T2 37 CONTENT COUPLING Definition: A module directly references the content of another module 1. Module p modifies a statement of module q 2. Module p refers to local data of module q (in terms of a numerical displacement) 3. Module p branches to a local label of module q SIT ICT2112 - TOPIC 2 - AY24/25, T2 38 COMMON COUPLING Using global variables (i.e., global coupling) All modules have read/write access to a global data block Modules exchange data using the global data block (instead of arguments) Single module with write access where all other modules have read access is not common coupling SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 39 COMMON COUPLING - EXAMPLE while( global_variable > 0 ){ If function_a(), switch( global_variable ){ function_b(), case 1: function_a(); break; etc. can modify the case 2: function_b(); break; value of global... variable, then it can case n:... } be extremely difficult global_variable++; to track the } execution of this loop SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 40 CONTROL COUPLING One module controlling the flow of another by passing the slave method information of what to do. Coupling at a level of controlling a method. E.g., you pass a flag that tells a method what to do SIT ICT2112 - TOPIC 2 - AY24/25, T2 41 STAMP COUPLING Occurs when too much information is passed to a function. typedef struct rectangle RECTANGLE CalcArea (RECTANGLE r) { { int length; r.area = r.width * r.length; int width; return r; int area; } int perimeter; int color; double diagonal; We are passing an entire RECTANGLE to char symbol; this function, even though the function really } RECTANGLE; does not need to see or modify all of the members. SIT ICT2112 - TOPIC 2 - AY24/25, T2 42 DATA COUPLING Two modules are data coupled if they Process communicate by passing parameters and Results no extra data are passed. mark grade Data coupling exhibits the properties that all parameters to a module are either simple data types, or in the case of a Calculate record being passed as a parameter, Grade all data members of that record are used/required by the module. SIT ICT2112 - TOPIC 2 - AY24/25, T2 43 DATA COUPLING – MORE EXAMPLE typedef struct rectangle int CalcArea(int width, int length) { { int length; int area; int width; area = width * length; int area; return area; int perimeter; } int color; double diagonal; char symbol; } RECTANGLE; This is a better way to write the previous program. Here we will be passing and returning only primitive data types. They are all that is really needed by the functions and now the functions are more general, too. SIT ICT2112 - TOPIC 2 - AY24/25, T2 44  PRINCIPLE #5: COHESION The manner and degree to which the tasks performed by a single software module are related to one another. Measures how well design units are put together for achieving a particular tasks. Understanding the degree of cohesion between objects helps us make more informed decision to effectively improve the cohesion between them. SIT ICT2112 - TOPIC 2 - AY24/25, T2 45  COUPLING & COHESION Cohesion is defined as the degree to which all elements of a module, class, or component work together as a functional unit. High cohesion is good, and low cohesion is bad. Coupling is defined as the degree of interdependence between two or more classes, modules, or components. Tight coupling is bad, and loose coupling is good. SIT ICT2112 - TOPIC 2 - AY24/25, T2 46  LOOSE COUPLING - HIGH COHESION In essence, high cohesion means keeping parts of a code base that are related to each other in a single place. Low coupling, at the same time, is about separating unrelated parts of the code base as much as possible. SIT ICT2112 - TOPIC 2 - AY24/25, T2 47  High Cohesion DEGREE OF COHESION Low Cohesion SIT ICT2112 - TOPIC 2 - AY24/25, T2 48 COINCIDENTAL COHESION This is the weakest form of cohesion. Its element have no meaningful relationship. SIT ICT2112 - TOPIC 2 - AY24/25, T2 49 PROCEDURAL COHESION A module has procedural cohesion if all the operations it performs are related to a sequence of steps performed in the program. For example, if one of the sequence of operations in the program was “read input from the keyboard, validate it, and store the answers in global variables”, that would be procedural cohesion. SIT ICT2112 - TOPIC 2 - AY24/25, T2 50  Module A operationA(){ readData(data,filename1); processAData(data); storeData(data,filename2); } PROCEDURAL readData(data,filename){ f = openfile(filename); COHESION readrecords(f, data); closefile(f); EXAMPLE } storeData(data,filename) {...} processAData(data) {...} SIT ICT2112 - TOPIC 2 - AY24/25, T2 51 INFORMATIONAL COHESION Information cohesion describe a module performing a number of operations, each operation with a unique entry point and independent code, and all operations are performed on the same data. In information cohesion, each function in a module must perform exactly one action. SIT ICT2112 - TOPIC 2 - AY24/25, T2 52  INFORMATIONAL COHESION The Object-oriented approach naturally produce designs with informational cohesion Each object in general has its own source code/file Each object operates on its own data which are defined within the object. Each member function of the object should perform one unique action/operation/function. SIT ICT2112 - TOPIC 2 - AY24/25, T2 53  INFORMATIONAL COHESION EXAMPLE class Airplane class Airplane{ private double speed, altitude; public void takeoff() {…} public void fly() {…} public void land() {…} } SIT ICT2112 - TOPIC 2 - AY24/25, T2 54  TYPES OF CODE FROM A COHESION & COUPLING PERSPECTIVE Source: http://enterprisecraftsmanship.com/2015/09/02/ cohesion-coupling-difference/ SIT ICT2112 - TOPIC 2 - AY24/25, T2 55  POORLY SELECTED BOUNDARIES as the result of High Coupling Low Cohesion The problem here is that they are selected improperly and often do not reflect the actual semantics of the domain. SIT ICT2112 - TOPIC 2 - AY24/25, T2 56  DESTRUCTIVE DECOUPLING as the result of low coupling, low cohesion It sometimes occurs when a programmer tries to decouple a code base so much that the code completely loses its focus: SIT ICT2112 - TOPIC 2 - AY24/25, T2 57  HOW TO DECOUPLE YOUR DESIGN? Divide and Conquer strategy Use what you have learned in OO Programming ▪ Inheritance ▪ Polymorphism Other techniques introduced in this module. SIT ICT2112 - TOPIC 2 - AY24/25, T2 58  PRINCIPLE #6: SEPARATION OF INTERFACE AND IMPLEMENTATION This principle involves defining a component by Interface specifying a public interface (known to the client of the component) that is separate Implementation from the details of how the component is realised. SIT ICT2112 - TOPIC 2 - AY24/25, T2 59  SEPARATION VS. ENCAPSULATION How is this principle different from Encapsulation? SIT ICT2112 - TOPIC 2 - AY24/25, T2 60  SEPARATION VS. ENCAPSULATION “During encapsulation, interfaces are created to provide public access to services provided by the design unit while hiding unnecessary details, which include implementation. While encapsulation dictates hiding the details of implementation, the principle of separation dictates their separation, so that different implementation of the same interface can be swapped to provide modified or new behaviour.” SIT ICT2112 - TOPIC 2 - AY24/25, T2 61  Sufficiency measures PRINCIPLE #7 & #8: how well the designed units are at providing only the SUFFICIENCY & services that are sufficient for COMPLETENESS achieving the intent (no more). Completeness measures how well-designed units provide the required services to achieve the intent (no less). SIT ICT2112 - TOPIC 2 - AY24/25, T2 62  Completeness and sufficiency Apple has really come up with lots of smart ideas to improve simple app like photo editing which reduces the number of clicks required and still get SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 the work done. 63  PRACTICAL DESIGN CONSIDERATIONS Design for minimising complexity Design for change SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 64  MANAGING SOFTWARE COMPLEXITY Design system so that developers only need to face a small fraction of the overall complexity. Modular Design Approach SIT ICT2106 ICT2112 - TOPIC WEEK 2 - AY21/22, AY24/25, T2 65 BEST MODULES (COMPONENTS) ARE DEEP The best modules are normally those that provide powerful functionality and have simple interfaces Deep modules have good abstraction ❖ Only a small fraction of its internal complexity is known to its users Module depth = Cost Vs. Benefit ❖ Benefit – provided by the module’s functionality ❖ Cost – is the module’s interface Module (component) interface represents the complexity that it imposes on the rest of the system. SIT ICT2112 - TOPIC 2 - AY24/25, T2 66  Interface (Cost: less is better) Functionality (Benefit: more is better) Deep Component Shallow Component SIT ICT2112 - TOPIC 2 - AY24/25, T2 67