Software Design Principles and Definitions: A Comprehensive Overview
This executive summary provides insights into software design principles, definitions, types, and processes essential for software engineers. It covers key concepts such as abstraction, coupling, cohesion, decomposition, encapsulation, and more to guide the design of efficient and maintainable software systems.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
SWEBOK Software Design Executive Summary Developed By: Devon X. Dalrymple Created: 2022-08-27 Slide Deck: #4
Knowledge Area: Software Design Describes the terms, processes, strategies, and notations a software engineer can use to turn a set of detailed requirements into an implementable design
Software Design Definitions and Types Process of analyzing requirements to produce a high-level description of the software and further detailing it to get a detailed description that is able to be implemented Other types: aka High-Level Design Top-level organization of the software App, client-server, command-based, menu driven, etc., is identifiable from this Not concerned with the inner details Component A unit of the software that has a known interface and dependencies *Examples: Class; Module; Function Architectural Design Decomposition design: Maps software into component pieces Specify each part of the software in enough detail for a programmer to implement it Interfaces of each component Detailed Design Family Pattern design: Find common components for building a family of related products *Depends upon the paradigm used Design documents should include the rationale for each design choice if not immediately obvious: - Aids implementing developers and long- term maintainers Invention design: Performed during the requirements process to conceptualize and specify software to handle the requirements
Design Principles Abstraction Outer view of a component (no inner details the what but not how) Design Principles Definition: Comprehensive key notions that provide the basis for various software design approaches and concepts Coupling How dependent different components are of each other Cohesion How well components/modules work together and internally Decomposition/Modularization Break the software s design into smaller components that fulfill their responsibilities without unrelated responsibilities Interface/Implementation Separation The implementation is dependent on the interface, but the interface can have its implementation changed without problems Encapsulation and Information Hiding Store internal details so that they exist in the component they affect and hiding direct connections to them from other components Sufficient and Complete Software Captures any important characteristic of an abstraction described in the design and doing nothing else Primitiveness Build the design of components around easy-to-implement patterns Separation of Design Concerns or areas of interest to at least one stakeholder) - Use different views of information or sections to show stakeholders the few things at a time that they are interested in
Aspects Concurrency Decomposes the design into processes, tasks, and threads so that the software is more atomically divided and so it runs much more efficiently Aspects Definition: Properties that affect the performance or semantics of software components systemically Control and Handling Events How to organize and control the flow of data and how events are handled using invocations and call backs Data persistence How to store the data in a way that it can be accessed and manipulated over long periods of time; long lived data Distribution of Components Distributing software across the hardware used and working between and inside the two types using middleware Exception and Error Handling How the software is designed to handle the problems that may occur due to unexpected circumstances Interaction and Presentation (Not about user interfaces) organizing and providing structure to user interactions along with presenting the information (like using MVC or MVVM) Security How to prevent unauthorized CRUD (Create-Read-Update-Delete) operations along with reducing the likelihood that CRUD operations are prevented, and dealing with attacks so that little damage is done
Software Structure and Architecture Software Architecture: The general set of structures/layout used with software components in order to detail the type of software components, their properties, and their relationships among one another This Photo by Unknown Author is licensed under CC BY This Photo by Unknown Author is licensed under CC BY Logical Shows information relevant to fulfilling the functional requirements Views Definition: Partial look at a specific part of a system s architecture omitting irrelevant details to that specific part Companies generally create related software systems for their business model while reusing parts of their design and code, these groups of similar software systems are called product lines or program families Process Shows information relevant to implement concurrency where able Physical Shows information relevant to distributing the software across various operating systems, environments, and hardware Development Shows the software design as individual units with their representation and how they are dependent to one another Other sources may make use of different names for the above
List of Common Architecture Styles General Distributed Interactive Adaptable Uncategorized Layers Pipes Filters Blackboard Client-Server (common for Web) Three-Tiers Broker Model-View- Controller Model-View-View Model Presentation- Abstract-Control Reflection Microkernel Batch (common for really old systems) Interpreters Process-Control Rule Based
List of Common Design Patterns Each of these have a situation that they are useful for, these patterns provide common solutions to these common situations, however, while each has its benefits, each also have a set of tradeoffs which should be taken into consideration. These are not at the same level as architecture styles and are for more detailed designs Creational: Builder Factory Singleton Prototype Structural: Adapter Bridge Composite Decorator Fa ade Flyweight Proxy Behavioral: Command Interpreter Iterator Mediator Memento Observer State Strategy Template Visitor
User Interface Design User Interface (UI) Design Design focused on making a good-looking and very capable but usable user interface so that users can complete their tasks efficiently (short amount of effort) and effectively (the correct thing is done) This Photo by Unknown Author is licensed under CC BY-NC-ND UI Design Principle Definition Software should be easy to learn so that the user becomes productive more quickly Learnability Form a compromise between user interaction and how the interface looks Should use terms and concepts from the people who will use the software are familiar with User Familiarity o o o o it works The interface should be consistent on how each action is handled to prevent unnecessary confusion Consistency The behavior of each part of the UI should avoid surprising users with how Minimal Surprise There should be ways to prevent or undo a user s mistakes Recoverability Interface should give relevant and meaningful feedback when issues occur User Guidance The interface should be usable for different types of users and for users with different capabilities (blind, poor eyesight, deaf, colorblind, etc.) User Diversity
Primary Styles for User Interaction Question-Answer Form Fill-In The user provides a question to the system and the system provides the answer The user types the necessary information into a form and submits it to the system Direct Manipulation Command Language The user uses a pointing device like a mouse and directly drag-and-drops or otherwise manipulate the data The user interacts with the system using the system s command language Menu Selection Natural Language The user selects the desired action through a list of menus and submenus The user interacts with the system by using their voice, hand signs, typed sentences, etc.
Tips for Presenting Information Color Guidelines Color assisting in finding the right button Show indication of items loading Make storyboards when designing to get customer feedback and save time later Only use a small list of colors This process is iterative Primary (Submit) Circular Progress Indicator Change color when software status changes See how users currently perform their tasks to make the design like the old (users typically do not handle change well) If an action takes longer than five seconds, the user may become impatient and accidentally perform the wrong action Warning (Delete File) Put thought into the color chosen for different actions Repeating Progress Bar Metaphors Or mappings between software features and a related real-world thing (like icons: trash can for delete) should be consistent throughout the application Measure response time from the time the user performs the action until the system responds visually Make colors contrast well for those with colorblindness Secondary Action (Cancel) Widget Loading Shimmer Use more than just color to indicate a type of information
Internationalization and Localization Definition: The process surrounding adding support for regional differences such as currency, date, number system, language, and layout. Internationalization is supporting a wide range of regions where localization tailors the user interface to match things specific to that region Locales affect proper visual item placement (for instance: a locale for Arabic speaking countries would have a right-to-left structure [hamburger icon on the right and the left would have the tabs or other icons in a navbar A way to handle language support is to have a JSON-like file for each language/region supported with the key being used to select the correct value (translated text) from the specific file to display the text to the user Different countries speak different languages, use different date formats, and have different currency and number systems Much easier to implement early rather than early on Hand gestures, symbols, or concepts may be inappropriate to show in different countries (for countries where Hinduism is common, don t show pictures of hamburgers; different countries have variations of the middle finger)
Analyzing Design Quality Software Design Reviews Types of reviews that determine the design quality of types of design documentation (ex. Architecture Reviews) Measures: Values used to apply a quantitative value to an area of the software design Types - Size, structure, and quality of the design Categorizing Measures: Structured Design Measures Using a structure chart or hierarchical diagram to see how the design is functionally decomposed Object-Oriented Design Measures: Class diagrams are made, and measures are applied to the properties of the classes These word endings help indicate that something is a design quality - ilities Maintainability Portability Scalability Statis analysis Use tools to evaluate a design (more formal) like a fault-tree analysis or automated cross-checking of documents Testability - nesses Correctness Robustness Simulations or Prototypes Visual representations of the design if implemented
Structural Aspect Design Notations What are Design Notations? They are techniques to describing the organization of a design Structural Aspect Notations Architecture Description Languages (ADLs) Formal language used to describe an architecture using terms like component and connector Class Diagrams and object diagrams Show the structure of classes or example values of objects and indicate the relationships between classes or objects Component Diagrams Represent the components that implement the interfaces set by the design documents Help indicate other types of software behavior CRCs or Candidate/Class, Responsibility, Collaborators Allow brainstorming of a candidate class's roles (key goal), responsibilities (what they know or perform to complete the goal), possible patters or stereotypes, and what other candidates/classes that it would communicate with, all in an index card Some are for architectural documents, some are for detailed designs, and some for both Deployment Diagrams Show the layout and interfaces between physical and software systems at a high level Entity-Relationship Diagram Use to indicate database entities with what information they hold, the type of each piece of information, and how they relate to other entities using a various relationship types
Detailed Design Notations Detailed Design Notations: Have more information on the behavior that occurs during an event or similar Communication Diagrams How groups of objects interact with one another Detailed Design Notations Data Flow Diagrams (DFDs) (The below are all data flow diagrams) Show how data flows between elements, and is modified by them Decision Table/Diagrams Used when combinations of complex conditions are used to determine a result Are more useful during the detailed design stage Flowcharts Indicate different types of activity pathways depending on the type of flowchart Sequence Diagrams Show interactions between a group of objects ordering them by the order that they are used and showing how messages a sent to and from each object State Transition or State Chart Diagrams How the control flow is changed from state to state and its effect on the component s behavior Have a higher inclusion of rationale in the notation Formal Specification Languages Text languages that use basic mathematic notions to represent actions, calculations, etc. Program Design Languages (PDLs) and Pseudo Code Write the behavior of a procedure/method/function in a way similar to the implementation but more readable by people
Methods and Strategies for Software Design Note: Concise Definitions: Divide and Conquer Breaking the software design into smaller more manageable portions and then doing them one-by-one Top-Down Starting from general components and extracting the specific components from those general components Bottom-Up Start with specific components and generalize them over the design process Function-Oriented: Object-Oriented: Methods are more specific than strategies since they provide a set of notations to design with - Identity major software functions and refine and elaborate them into a hierarchical top-down structure - Scope of Effect vs. Scope of Control - Fan-In vs. Fan-Out - Noun-Verb: Noun => Object; Verb => Method; Adjective => Attribute - Design by responsibility - Focus on identify inheritance structures Design Strategies Data Structure: Component-Based Design: - Find the components by their well-defined interface and dependencies - Handle trust management - A component with higher trust levels should avoid dependence on lower trust level components or services Instead of functions or objects, design based on the data structures or database mappings that the program will manipulate Top-Down and Bottom-Up find possibilities to reduce code duplication and set up inheritance or similar structures
Bibliography [1] Institute of Electrical and Electronics Engineers, Guide to the Software Engineering Body of Knowledge, 3rd ed., Piscataway, New Jersey, 2014, pp. 2-1'- 2-12'.
