System Design

[anitsh]

A paradigm is a distinct set of concepts or thought patterns, including theories, research methods, postulates, and standards for what constitutes legitimate contributions to a field.

Design paradigm refers to exemplary design solutions that create "design trends", the second meaning refers to what a group of people expects from a type of design solutions. It is used within the design professions, including architecture, industrial design and engineering design, to indicate an archetypal solution.

A system is an entity with a well-defined behavior in terms of output it produces and which is a function of the input it receives, the passage of time and its internal logic. By “well-defined behavior” we mean that the output produced by the system is previ- ously agreed upon and unambiguously distinguishable from output that does not qualify as well-defined behavior. The well-defined behavior of a system is called the system specification. A system interacts with its environment by receiving input from it and delivering output to it. It may be possible to decompose a system into constitu- ent (sub)systems. In CBSE terms a system is a component that may consists of the assembly of a number of smaller components. In OO terms a system is a composi- tion of objects, each of which may be itself a composition of smaller objects.

Resource:

• [ ] #200 Fitness Function in System Design
• [ ] - https://www.ibm.com/topics/software-development
• [ ] - https://en.wikipedia.org/wiki/Software_design
• [ ] - https://wiki.c2.com/?SoftwareDevelopment
• [ ] - https://wiki.c2.com/?SevenPrinciplesOfSoftwareDevelopment
• [ ] - https://www.bredemeyer.com/howto.htm
• [ ] - http://sunnyday.mit.edu/16.355/metrics.pdf
• [ ] - https://mitsloan.mit.edu/ideas-made-to-matter/design-thinking-explained
• [ ] - https://www.cs.colorado.edu/~kena/classes/5828/s10/presentations/softwaredesign.pdf
• [ ] - https://stackoverflow.com/questions/704855/software-design-vs-software-architecture
• [ ] - https://hackernoon.com/why-software-design-is-important-9ecbea883bbb
• [ ] - https://medium.com/the-andela-way/system-design-in-software-development-f360ce6fcbb9
• [ ] - https://cheatography.com/nataliemoore/cheat-sheets/system-design
• [ ] - https://techlead.academy/p/systems-thinking-fundamentals
• [ ] - https://iankoenig.com/blog/2009/03/21/the-difference-between-architecture-and-design
• [ ] - https://medium.com/@david.vancouvering/writing-a-high-level-design-26280ee88480
• [ ] - https://blog.pramp.com/how-to-succeed-in-a-system-design-interview-27b35de0df26
• [ ] - https://medium.com/machine-words/writing-technical-design-docs-71f446e42f2e
• [ ] - https://gist.github.com/codeanit/459cfd474c9e2e4e59cdf59242884d9b
• [ ] - https://sdg.csail.mit.edu
• [ ] - https://en.wikipedia.org/wiki/Systems_engineering
• [ ] - https://en.wikipedia.org/wiki/Systems_design
• [ ] - https://en.wikipedia.org/wiki/Systems_analysis
• [ ] - https://twitter.com/ruthmalan/status/1292515986592215040
• [ ] - https://medium.com/@johnpcutler/sensor-responder-or-in-between-6378d6589e50
• [ ] - https://en.m.wikipedia.org/wiki/OODA_loop
• [ ] - https://en.m.wikipedia.org/wiki/Sense_and_respond
• [ ] https://en.wikipedia.org/wiki/Planned_obsolescence [This feature should be a part of the design. Why? Read]
• [ ] https://github.com/donnemartin/system-design-primer
• [ ] http://highscalability.com/
• [ ] https://github.com/lei-hsia/grokking-system-design
• [ ] https://www.freecodecamp.org/news/how-to-system-design-dda63ed27e26/
• [ ] https://hackernoon.com/anatomy-of-a-system-design-interview-4cb57d75a53f
• [ ] Why Google stores billions of lines of code in a single repository
• [ ] https://www.infoq.com/articles/whats-the-next-step-for-data-management
• [ ] https://ruthmalan.com/Journal/2019/201902OReillySAConPresentationAll.htm
• [ ] https://www.pmi.org/learning/library/complex-system-development-strategy-9943
• [ ] Evaluating the Software Design of a Complex System of Systems - Software Engineering Institute, Carnegie Mellon
• [ ] https://github.com/eileen-code4fun/SystemDesignInterviews
• [ ] https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews
• [ ] https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
• [ ] https://www.mitre.org/publications/technical-papers/systems-engineering-competency-model
• [ ] https://architectelevator.com/architecture/it-complexity

System Design Interview

• [ ] https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews
• [ ] https://blog.pragmaticengineer.com/system-design-interview-an-insiders-guide-review
• [ ] https://www.hackerearth.com/blog/developers/8-steps-to-acing-your-next-system-design-interview
• [ ] https://www.palantir.com/how-to-ace-a-systems-design-interview
• [ ] https://github.com/DovAmir/awesome-design-patterns
• [ ] https://www.youtube.com/c/SystemDesignInterview/featured
• [ ] https://courses.systeminterview.com/courses/system-design-interview-an-insider-s-guide
• [ ] https://blog.pragmaticengineer.com/system-design-interview-an-insiders-guide-review
• [ ] https://blog.avanscoperta.it/2020/03/26/remote-eventstorming Software Design Process
• [ ] https://www.mitre.org/publications/technical-papers/the-mitre-systems-engineering-guide |
• [ ] https://interviewdaemon.medium.com/system-design-instagram-photo-sharing-social-network-90ce2e7ad312

Reference

344 #462 #176

[anitsh]

Software engineers apply engineering principles to build software and systems to solve problems. They use modeling language and other tools to devise solutions that can often be applied to problems in a general way, as opposed to merely solving for a specific instance or client. Software engineering solutions adhere to the scientific method and must work in the real world, as with bridges or elevators. - IBM

A System Is A State Machine. Garbage In - Garbage Out

Software Design

Software design is the process of defining software methods, functions, objects, and the overall structure and interaction of code so that the resulting functionality will satisfy users requirements.

The software design process is a sequence of steps that enables the designer to describe all aspects of the software for building. Creative skill, past experience, a sense of what makes "good" software, and an overall commitment to quality are examples of critical success factors for a competent design. It is not always a straightforward procedure. Basic design principles enable the software engineer to navigate the design process.

There are many different ways of designing software, almost all of which involve coming up with an initial design and refining it as necessary. Different developers prefer different amounts of design up front or during implementation phase. Generally the overall design should be well thought out and reviewed before coding starts. It is easier to try out different designs up front and discover problems early in the development cycle than to make a major design change after much of the code has been written.

Primarily, all Software Design has two primary items to deal with:

• Abstraction of the Data Structure
• Communication with other parts (Bounded Contexts) of the system

Difference: Software Design and Analysis

The main difference between software analysis and design is that the output of a software analysis consists of smaller problems to solve. Additionally, the analysis should not be designed very differently across different team members or groups. In contrast, the design focuses on capabilities, and thus multiple designs for the same problem can and will exist. Depending on the environment, the design often varies, whether it is created from reliable frameworks or implemented with suitable design patterns. Design examples include operation systems, webpages, mobile devices or even the new cloud computing paradigm.

Software Design Concepts

The Design Concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are as follows:

• Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. It is an act of Representing essential features without including the background details or explanations.

• Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts.

• Modularity - Software architecture is divided into components called modules.

• Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost.

• Control Hierarchy - A program structure that represents the organization of a program component and implies a hierarchy of control.

-Structural Partitioning - The program structure can be divided into both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure.

• Data Structure - It is a representation of the logical relationship among individual elements of data.

• Software Procedure - It focuses on the processing of each module individually.

• Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.

Aspects To Consider When Designing Software

There are many aspects to consider in the design of a piece of software. The importance of each consideration should reflect the goals and expectations that the software is being created to meet. Some of these aspects are:

• Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself.

• Extensibility - New capabilities can be added to the software without major changes to the underlying architecture.

• Modularity - the resulting software comprises well defined, independent components which leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project.

• Fault-tolerance - The software is resistant to and able to recover from component failure.

• Maintainability - A measure of how easily bug fixes or functional modifications can be accomplished. High maintainability can be the product of modularity and extensibility.

• Reliability (Software durability) - The software is able to perform a required function under stated conditions for a specified period of time.

• Reusability - The ability to use some or all of the aspects of the preexisting software in other projects with little to no modification.

• Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with resilience to low memory conditions.

• Security - The software is able to withstand and resist hostile acts and influences.

• Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users.[6]

• Performance - The software performs its tasks within a time-frame that is acceptable for the user, and does not require too much memory.

• Portability - The software should be usable across a number of different conditions and environments.

• Scalability - The software adapts well to increasing data or added features or number of users.

Software Design Classifications Bases On Programming Paradigms

Just as software engineering (as a process) is defined by differing methodologies, so the programming languages (as models of computation) are defined by differing paradigms. Some languages are designed to support one paradigm (Smalltalk supports object-oriented programming, Haskell supports functional programming), while other programming languages support multiple paradigms (such as Object Pascal, C++, Java, JavaScript, C#, Scala, Visual Basic, Common Lisp, Scheme, Perl, PHP, Python, Ruby, Wolfram Language, Oz, and F#). For example, programs written in C++, Object Pascal or PHP can be purely procedural, purely object-oriented, or can contain elements of both or other paradigms. Software designers and programmers decide how to use those paradigm elements.

In object-oriented programming, programs are treated as a set of interacting objects. Hence, the software is designed as in the context of objects.

It is good to know some of the programming paradigms there are:

• Imperative programming - is a Software design Classification that uses statements that change a program's state. Imperative programming focuses on describing how a application operates.

  • Procedural which groups instructions into procedures
  • Object-oriented Programming which groups instructions together with the part of the state they operate on

• Declarative programming in which the programmer merely declares properties of the desired result, but not how to compute it

  • Functional Programming in which the desired result is declared as the value of a series of function applications
  • Logic programming is a type of programming paradigm which is largely based on formal logic. Any program written in a logic programming language is a set of sentences in logical form, expressing facts and rules about some problem domain
  • Mathematical programming in which the desired result is declared as the solution of an optimization problem
  • Reactive programming is the practice of programming with asynchronous data streams or event streams. Observer Software design pattern
  • Functional Reactive programming the combination of functional and reactive paradigms. In other words, it is reacting to data streams using the functional paradigm. FRP is not a utility or a library — it changes the way you architect your applications and the way you think about your applications

Software Design Principles

Grady Booch defined Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation(PHAME) as the fundamental software design principles in his book Object-Oriented Analysis and Design with Applications, 2004.

Alan M. Davis suggests a set of principles for software design in his book `201 Principles of Software Development, 1995, which have been adapted and extended in the following list:

• The design process should not suffer from "tunnel vision." A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.

• The design should be traceable to the analysis model. Because a single element of the design model can often be traced back to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.

• The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited; design time should be invested in representing (truly new) ideas by integrating patterns that already exist (when applicable).

• The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain.

• The design should exhibit uniformity and integration. A design is uniform if it appears fully coherent. In order to achieve this outcome, rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.

• The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle.

• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well-designed software should never "bomb"; it should be designed to accommodate unusual circumstances, and if it must terminate processing, it should do so in a graceful manner.

• Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than the source code. The only design decisions made at the coding level should address the small implementation details that enable the procedural design to be coded.

• The design should be assessed for quality as it is being created, not after the fact. A variety of design concepts and design measures are available to assist the designer in assessing quality throughout the development process.

• The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model.

The software design should be reviewed for compliance with overall design objectives, including:

• A clear understanding of the user environment, requirements, and system analyst specifications.
• Use of best practices in software design, including effective design strategies, modularity, performance, and extensibility
• Clear process flows, data integration, and data models.

Plan on spending as much time as necessary to answer any questions before turning the design over for programming. The more time spent in the early planning phases will help to create easier coding and save time later in the software programming phase.

Software Modeling

The Software Design Model can be compared to an architect's plans for a house. It begins by representing the totality of the thing that is to be built (e.g., a three-dimensional rendering of the house); slowly, the thing is refined to provide guidance for constructing each detail (e.g., the plumbing lay). Similarly, the design model that is created for software provides a variety of different views of the computer software. By software modeling we do not mean expressing a scientific theory or algorithm in software. This is what scientists traditionally call a software model. What we mean here by software modeling is larger than an algorithm or a single method. Software modeling should address the entire software design including interfaces, interactions with other software, and all the software methods. Software models are ways of expressing a software design. Usually some sort of abstract language or pictures are used to express the software design. For object-oriented software, an object modeling language such as UML is used to develop and express the software design. There are several tools that you can use to develop your UML design. In almost all cases a modeling language is used to develop the design not just to capture the design after it is complete. This allows the designer to try different designs and decide which will be best for the final solution. Think of designing your software as you would a house. You start by drawing a rough sketch of the floor plan and layout of the rooms and floors. The drawing is your modeling language and the resulting blueprint will be a model of your final design. You will continue to modify your drawings until you arrive at a design that meets all your requirements. Only then should you start cutting boards or writing code. Again the benefit of designing your software using a modeling language is that you discover problems early and and fix them without refactoring your code.

[anitsh]

Component-based Software Engineering

• [ ] https://en.wikipedia.org/wiki/Component-based_software_engineering