Chapter 4 - Software Design Basics - StudentCopy.pdf
Document Details
Uploaded by FondPiano4891
Full Transcript
Chapter 4 Software Design Basic OBJECTIVES Define software design and understand different design levels Describe the concepts of modularization, concurrency, coupling and cohesion. Understand different interface design and GUI Tools Software design is a proces...
Chapter 4 Software Design Basic OBJECTIVES Define software design and understand different design levels Describe the concepts of modularization, concurrency, coupling and cohesion. Understand different interface design and GUI Tools Software design is a process to transform user Software requirements into some suitable form, which Design helps the programmer in software coding and implementation. Software Design Levels Software design is done in three levels : Architectural Design is the highest abstract version of the system. 1. Architectural Design 2. High-level Design High Level Design breaks the ‘single entity- 3. Detailed Design multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other. Detailed Design defines logical structure of each module and their interfaces to communicate with other modules. Modularization is a technique to divide a software system into multiple discrete and Modularization independent modules, which are expected to be capable of carrying out task(s) independently. Advantages of Modularization 1. Smaller components are easier to maintain 2. Program can be divided based on functional aspects 3. Desired level of abstraction can be brought in the program Modularization 4. Components with high cohesion can be re-used again 5. Desired from security aspect 6. Concurrent execution can be made possible Concurrency is implemented by splitting the software into multiple independent units of Coupling execution, like modules and and executing them in parallel. Cohesion The quality of a “design of modules” and their interaction among them can be measured using coupling and cohesion. Coupling and Cohesion - Coupling and cohesion are principles used to measure whether the design was well divided into modules. Coupling - is the strength of interdependence between software modules. The more dependent is module A to module B internals, the stronger is the coupling between A and B. Strong coupling implies the modules involved are harder to understand because they must be understood together, harder to change because these changes will impact more than one module, and harder to correct because the problem may be spread over the tightly coupled modules. Cohesion - is an intra-module measure. Cohesion is the strength of relation between tasks performed by a module. The different types of cohesion are Functional cohesion, Sequential cohesion, Communicational cohesion, Temporal cohesion, Procedural cohesion, Logical cohesion, Coincidental cohesion. A good system design will have strong (high) cohesion and weak (low) coupling. Coupling: Degree of dependence among components No dependencies Loosely coupled-some dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components Highly coupled-many dependencies to which the component is connected. Types of coupling Content coupling (high)Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module).Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. – Component modifies another’s code, e.g., jumps (goto) into the middle of a routine. Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable).Changing the shared resource implies changing all the modules using it. More than one component share data such as global data structures. External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices. Two components share something externally imposed, e.g., – External file – Device interface – Protocol – Data format Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag). Component passes control parameters to coupled components. Stamp coupling (Data-structured coupling) occurs when modules share a composite data structure and use only a part of it, possibly a different part (e.g., passing a whole record to a function that only needs one field of it).This may lead to changing the way a module reads a record because a field that the module does not need has been modified. Component passes a data structure to another component that does not have access to the entire structure. Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation). Data coupling occurs when modules share data through, for example, parameters. Each data is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root). Component passes data (not data structures) to another component. Example: Customer billing system – The print routine takes the customer name, address, and billing information as arguments. Message coupling (low). This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing (see Message passing). No coupling - Modules do not communicate at all with one another. Type of Coupling High Coupling Content Avoid Common External Control Loose Stamp Message Try to achieve Low Data Uncoupled 8 8 Types of Cohesion Coincidental cohesion Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class). Logical cohesion Logical cohesion is when parts of a module are grouped because they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines). Temporal cohesion Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user). Procedural cohesion Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file). Communicational/informational cohesion Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information). Sequential cohesion Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data). Functional cohesion Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. Lexical analysis of an XML string). Cohesion types: Coincidental cohesion Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class). Logical cohesion Logical cohesion is when parts of a module are grouped because they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines). Ex: Read from tape, disk, network Temporal cohesion Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user). Ex-Modules that perform activities like “initialization”, “clean-up”, and “termination” Procedural cohesion Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file). Ex: Open Database, Read data, modify and then close Communicational/informational cohesion Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information). Ex: Read the record, modify it ,print the same record Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data). Ex: Reads the data and process it Sequential cohesion Functional cohesion is when parts of a module are grouped because they all contribute to a single well- defined task of the module (e.g. Lexical analysis of an XML string). is the strongest cohesion. Functional all the elements of the module are related to performing a single function. Cohesion Ex: calculate average Cohesion types Range of Functional Informational High Cohesion Cohesion Communicational Procedural Temporal Logical Coincidental Low Reduced module complexity (they are simpler, having fewer operations). Advantages Increased system maintainability- because logical changes in the domain of Cohesion affect fewer modules, and changes in one module require fewer changes in other modules. Increased module reusability, because application developers will find the component they need more easily among the cohesive set of operations provided by the module. Let’s try: Before the customer can order for a food desired, the customer must first do the registration of his/her personal details n the Talabat.com. After registration, the customer can now log-in using the username and password provided by the system. The customer will now fill-in the registration details and providing the username and password. Once the record has been submitted, the customer can now order the foods to the restaurant listed in the system. Identify the type of cohesion used in the food ordering module. Justify your answer. User interface is the front-end Software application view to which user interacts in order to use the User software. Interface UI provides fundamental platform Design for human-computer interaction. UI can be graphical, text-based, audio-video based, depending upon the underlying hardware and software combination. UI can be hardware or software or a combination of both. Software User Interface Design The software becomes more popular if its user interface is: Consistent on Responsive in Clear to Attractive Simple to use all interfacing short time understand screens UI is broadly divided into two categories: Command Line Interface Graphical User Interface Software User Interface Design USER INTERFACE CATEGORIES 1. Command Line Interface (CLI) - 1. CLI PROVIDES A COMMAND PROMPT, THE PLACE WHERE THE USER TYPES THE COMMAND AND FEEDS TO THE SYSTEM. 2. Graphical User Interface - GUI PROVIDES A SET OF COMPONENTS TO INTERACT WITH SOFTWARE OR HARDWARE. CLI provides a command GUI provides a set of prompt, the place where components to interact the user types the CLI VS GUI command and feeds to with software or hardware. the system. Command Line Command Prompt is a text-based Interface (CLI) notified that is mostly shows the context in which the user is working. Cursor is horizontal line or a vertical bar of height of line, to represent position of character while typing. Command is an executable instruction. Graphical User Interface GUI provides a set of components to interact with software or Window an area where contents of application are hardware. displayed. Tabs allows application appear on the screen as separate window. Menu is an array of standard commands, group together and placed at a visible place. Icon a small picture representing an associated application. Cursor is a pointer in GUI system. Application Specific GUI Components Most application window uses the constructs supplied by operating systems. The dialog box is a child window that contains message for the user and request for some action to be taken. The textbox provides an area for user to type and enter text-based data. The buttons are used to submit inputs to the software. The radio button displays available option for selection. The checkbox functions similar to list box. The list box provides list of available items for selection. Application Specific GUI Components The dialog box is a child window that contains message for the user and request for some action to be taken. The textbox provides an area for user to type and enter text-based data. The buttons are used to submit inputs to the software. The radio button displays available option for selection. The checkbox functions similar to list box. The list box provides list of available items for selection. Design Verification User Interface Design Activities By structured verification approach, reviewers can detect defects that might be caused by overlooking some conditions. Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come handy to build GUI: FLUID GUI Implementation User Interface AppInventor (Android) Tools Design LucidChart Activities Wavemaker 1. The process of GUI design and Implementation is Visual Studio alike SDLC. 2. Any model can be used for GUI implementation among Waterfall, Iterative or Spiral Model. GUI Design GUI User Task & Requirement Analysis Analysis implementat Testing Gathering ion User Interface Golden Rules 1. Strive for Consistency 2. Enable frequent users to use short-cuts 3. Offer Informative feedback 4. Design Dialog to Yield Closure 5. Offer simple error handling 6. Permit Easy Reversal of Actions 7. Support Internal Locus of Control 8. Reduce short-term memory load Let’s Try: 1. Refer the below given diagram and identify the coupling between Pairs AX of Modules into the given A Y table: Y B BZ ZC Let’s Try: Analyze the given diagram and identify the types of coupling Modules A B available between the X modules: Y Let’s Try: 1. You are assigned as the Software Engineer for “E-Services for Water and Electricity Installation” in Muscat Municipality. The modules are: (1) Registration Module that allows the applicant to register data such as: name, mobile number, e-mail address, username and password; (2) Log-in Module, and (3) Payment that allows applicant to pay through a debit or credit card after selecting the type of card either master or visa. The card details will be validated by the Bank and will automatically send an OTP (One- Time Password) to the applicant; Construct/draw the graphical user interface for the “Payment Module” on the above scenario, Provide at least four (4) menu items. ID Full Name Address Phone number The END Username Password Four basic design principles are applicable to component-level design and have been widely adopted when object-oriented software engineering is applied. The underlying motivation for the application of these principles is to create designs that are more amenable to change and to reduce the propagation of side effects when changes do occur. You can use these principles as a guide as each software component is developed. SOLID is an acronym that stands for five key design Basic Principles principles: Single responsibility principle : “a class should have one, and Design only one, reason to change.” Open-closed principle : “ A module (component) should be open for extension but closed for modification”. Liskov substitution principle : “ Subclasses should be substitutable for their base classes” Interface segregation principle : “Many client-specific interfaces are better than one general purpose interface” Dependency inversion principle : “ Depend on abstractions. Do not depend on concretions” References… http://www.tutorialspoint.com/ Recommended books : Sommerville, Ian, Software engineering. — 10th ed, Pressman, Roger S, Software engineering: a practitioner’s approach / Roger S. Pressman.8th ed
