Software Designing - Software Engineering
4 likes1,428 views
The document outlines essential concepts in software design, emphasizing the importance of modeling, architecture, and modularity for effective problem-solving and implementation. It discusses design principles such as abstraction, information hiding, cohesion, and coupling while also defining various architectural styles, user interface considerations, and web application design. Additionally, it highlights the significance of proper communication among modules and the necessity of designing for flexibility and maintainability.
![ Refactoring
reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior
it does not alter the external behavior of the code [design] yet improves
its internal structure
Importance
To improve quality of software
Improving the quality of the code, working becomes easier addition of new
code and maintenance of the code becomes easy
Improves the code over the period of time
Play important role in splitting long functions into reasonably small sub
functions
Helps in creating reusable codes
Error handling is much easier and within control](https://image.slidesharecdn.com/seunit5dssigning-170426075540/85/Software-Designing-Software-Engineering-15-320.jpg)
Software Designing - Software Engineering
- 2. INTRO Goal is to produce a model or repesentation Designer should Stock all material of design like components, component solutions & knowledge Choose elements from stock that meet requirements Alternatives are also considered & accepted/rejected for final confirmation
- 3. Design Process To achieve intended goal of software – successful implementation Always refers to finding solution or problem solving Includes algorithms, diagrams, formulae designs, low level design etc. Follow semi standard methods like UML for modelling the software Use different diagrams like activity, use case and sequence Use of design patterns and architectural guides (if required)
- 4. Design Concepts Abstraction For modular solution many level of abstraction is possible High level solution – solution stated in the language of the problem environment lower levels of abstraction - used for detailed description data abstraction is actually a collection of data that describes a data object
- 5. Architecture Software architecture is the complete structure or arrangement of the program components in such a way that they interact with each other data structures may be used by these components these components are the building blocks of the overall structure of the application being developed architectural design can be represented using one or more of a number of different models Patterns a design pattern describes a design structure that solves a particular design problem within a specific context
- 6. Modularity consists of software architecture and design patterns defined as the modularization of a single attribute (main module) of software into number of small parts (smaller modules) such that these parts can be easily managed Consider C(x) – function of a problem x that define its complexity E(X) - function of a problem x that define efforts required to solve that problem Let there are two problems p1 and p2 for which, If C(p1) > C(p2) then E(p1) > E(p2)
- 7. interesting characteristic is uncovered through observations and experimentation C(p1 + p2) > C(p1) + C(p2) complexity of two combined problems p1 and p2 is greater than the complexity when the problems are considered separately From previous equations it follows, E(p1 + p2) > E(p1) + E(p2) That leads to a strategy called divide and conquer always easy to solve a complex problem when it is divided in small sub-problems that are easily manageable
- 8. the effort (cost) to develop an individual software module does decrease as the total number of modules increases For large size problem, the number of modules will be increased and the effort (cost) associated with integrating the modules also increases • M is number of modules that would result in minimum development cost, but there is no any proper and sophisticated method to predict M • divide the problem into modules, but utmost care must be taken to stay in the region of M
- 9. five criteria defined for an effective modular system Modular decomposability : complex problem may be solved very easily by decomposing into smaller sub problems Modular composability : Different modules and components are integrated to produce a new system Modular understandability : While integrating a system, if each of the individual modules or components are understood well, then it become very easy to build the system once again Modular continuity : to minimize side effect of changes it’s always better to make changes module-wise instead of making changes system- wise Modular protection : for any abnormal condition within a module, the effects are within that module only. Thus the side effects are minimized and problems will not spread outside that module
- 10. Information Hiding modules of the larger problem must be specified and designed properly so that information (i.e. algorithms and data) present within a module is not available to other modules that do not require such information To achieve effective modularity that have proper necessary communication among modules Refinement uses a top-down strategy the procedural details of a program are refined in various levels hierarchy is generated by modularizing the statements of a program
- 11. Functional Independence Its a type of modularity and related to the concepts of abstraction and information hiding In this, each module addresses a specific sub function of requirements and has a simple interface Independence is assessed by two criteria Cohesion : a relative functional strength of a module Coupling : relative interdependence among modules
- 12. Cohesion extension of the concept of information hiding a module performs only one task within a software procedure (or required only little interaction with other procedures of the software) module that performs different tasks that are loosely related to each other are termed as coincidentally cohesive module that performs tasks that are related logically is logically cohesive When a module contains tasks that are related by the fact that all must be executed with the same span of time, the module exhibits temporal cohesion Procedural cohesion exists when processing elements of a module are related and are executed in a specific order
- 13. When all the processing elements do concentrate on only one area of a data structure, then communicational cohesion is available High-end cohesion is characterized by a module that performs one single and unique procedural task Coupling is a measure of inter-relationship among various modules in a software structure always depends on the interface complexity among modules to make bit easy to understand, connectivity between different modules of software is made simple by minimum possible coupling Simple connectivity avoid “Ripple Effect” - (errors occurring at one particular location in the system and propagating through a system)
- 14. Types of Coupling Low data coupling (a – c) Data passed Stamp coupling (a - b) Data Structure passed Control Coupling (d - e) Control flag passed High level of coupling (external coupling) Modules tied to external environments High (common) Coupling (c – g – k ) Modules refer a global data area
- 15. Refactoring reorganization technique that simplifies the design (or code) of a component without changing its function or behavior it does not alter the external behavior of the code [design] yet improves its internal structure Importance To improve quality of software Improving the quality of the code, working becomes easier addition of new code and maintenance of the code becomes easy Improves the code over the period of time Play important role in splitting long functions into reasonably small sub functions Helps in creating reusable codes Error handling is much easier and within control
- 16. Design Classes Each of the software team should define a set of design classes Classes should describe the elements of problem domain and that should focus the customer requirement It should, Refine the analysis classes that are implemented Create a new set of design classes that must support the business solutions
- 17. Design Principles s/w design must be in such a way that the system is easily traceable to the analysis model software design must not reinvent the wheel (i.e. repetition of the same tasks), since the time is limited and the resources are also limited, the design should use the existing ideas and patterns design must be in such a way that it minimizes the intellectual distance between the application or the system and the related problems design must demonstrate uniformity and integration of different components to their interfaces
- 18. design structure must be flexible to accommodate modification design must withstand against abnormal data, abnormal events and abnormal operating conditions design should not be the coding, and coding should not be the design design should be able to evaluate the quality design must be reviewed to minimize the conceptual errors
- 19. Architectural Design architecture of a program or computing system is actually the structures of the system that consists of following attributes Software Components Externally visible property of s/w component Relationships among this components It’s a representation that enable s/w engineer to analyse, Analyse the effectivness of the design Consider architectural alternatives Reduce the associated risks
- 20. Importance of architectural design enables communication between all stakeholders involved in the development of the system emphasizes early design decisions that will have a deep influence on all software engineering tasks (success mantra for the system) builds a small, intellectually model that will help the system to integrate its component
- 21. Architectural Styles It explains the system category that consist of, set of components (i.e. a database or the computational modules) that perform a function required by the system set of connectors used for communication, coordination, and cooperation between the components constraints used to define the integration of various components into system semantic models used to understand the overall properties of a system with the help of analysis of its elements
- 22. Data Centered Architecture Data stored – accessed by various components of the system Access a central repository Independent of other component changes and update
- 23. Data Flow architectures When i/p data are to be transformed through series of computational components to get o/p data Pipe and filter pattern transmit data from one component to next Each filter designed to expect data i/p of certain form and produce o/p in specified form Doesn’t require working knowledge of neighbouring filter
- 24. Call & Return architecture Enables program structure that is easy to modify and scales No of sub style Main Program/Sub Program Arch. : decomposes function into control hierarchy where main program invokes no of other components Remote Procedure Call Archi. : component of main program / subprogram are distributed across multiple computers on n/w Object Oriented Architecture Component encapsulate data and operations Component communication happen via message passing
- 25. Layered Archi. No of different layers are defined having operations that progressively become closer to solution
- 26. Other Architectures Publisher Subscriber Architecture Client Server Architecture Peer to Peer Architecture Event Based s/w Architecture
- 27. Component Level Design comes after architectural design is completed It’s an alternative approach to the architectural design approach Defines data structures, algorithms, interface characteristics & comm mechanism Three different view of a component design Objet Oriented view (defines attributes and operations) ConventionalView (component with – processing logic + data Structures + interface) Process RelatedView (focus on the reusability of the existing software components)
- 29. User Interface Design Creates an effective communication between user and system Many factors are considered before designing UI Type of the user, age, education level, purpose of the s/w Provided at h/w as well as s/w level Need good understanding of user needs Types of UI - Command Interpreter & GUI Benefits of good UI Higher revenue Increased user efficiency and satisfaction Reduced development costs Reduced support costs
- 30. Design rules for UI Place the user in Control Define the interaction modes in such a way that the user is not forced to perform unnecessary or undesired actions The interaction should be flexible User interaction should be interruptible and undoable The different levels of difficulty in interaction for different classes of users must be customized Hide complexities from the casual user direct interaction with objects that appear on the screen
- 31. Reduce the User’s Memory Load Reduce the demand for short-term memory Define shortcuts that can easily remembered Established meaningful defaults information should be disclosed in a progressive fashion Make the Interface Consistent
- 32. UI Design Models User Profile Model Novices (no syntactic but little semantic knowledge) Knowledgeable, intermittent users (low syntactic & reasonable semantic knowledge) Knowledgeable, frequent users (Good Syntactic and semantic knowledge) Design Model Implementation Model User’s System Perception
- 33. Web Application Design WebApp Design involves technical and non technical acts like, Establishing look and feel of web app Great UI Defining overall architectural structure Developing content and functionality that resides within his architecture Planning the navigation that occurs within the WebApp
- 34. WebApp Design Quality Requirement
- 35. WebApp Interface Design Main objectives Establish a consistent window into the content an functionality that provided by the interface Guide the user with series of interactions with the WebApp Organize the navigation option and content available to the user
- 36. Aesthetic Design (graphic design) Is an artistic endeavour that complements technical aspects of WebApp Design Content Design Focus on two different task (addressed by individuals) Design representation for content objects and relationship between them developed Conducted by copywriters, graphic designers & others who generate the content to be used within WebApp
- 37. Architectural Design (in parallel with previous phase) Tied to the goals Content to be presented Users who visit the WebApp Navigation philosophy established within the WebApp Decisions made during this phase has strong influence on Navigation Designing Navigation Design Define the navigation pathways that enable user to access components and functions of the WebApp (pages, functions, scripts and other pages)
- 38. Component Level Design ModernWebApps deliver sophisticated processing functions that perform localized processing (to generate content and navigation dynamically) Computation or data processing capability Provide sophisticated database query and access Establish data interface with external components
- 39. END