Please enable JavaScript.

Coggle requires JavaScript to display documents.

SoftwareArchitechure - Coggle Diagram

- - - - As long as the server can handle all the requests it receives in a reasonable time, more clients can be added and start making requests.
        
        By extending this further with an N-Tier architecture, with more tiers, the scalability is incredible. You only need to look at the success of the World Wide Web to see how far this scalability can go.
- - - - The defining feature of implicit invocation is that a functions are not in direct communication with each other. All communication between them is mediated by an event bus.
        
        To achieve this structure, we first bind an event and an event consumer via the event bus. That is, each event consumer registers with the event bus to be notified of certain events. When the event bus detects an event, it distributes the event to all appropriate event consumers.
        
        This loose coupling of functions makes it easier to evolve and scale the system. Adding new functionally for an existing event is as simple as registering a new event function pair to the event bus and adding a new event consumer.
  - - - We say a system has race conditions when the behavior of the functions depend on the order in which they are called
        
        A simple binary semaphore may consist of a variable that toggles between two values, available and unavailable. Available indicates that the shared data is not in use, and unavailable indicates that the shared data is in use by a function
      - In this architectural style, events and functions do not occur in a predictable way. There are no guarantees of exactly when an event will be handled, how long it will take to be handled, or when an event generator will emit an event.
- - - - Where individual design patterns and principles are concerned primarily with functional software issues, software architecture must also consider non-functional requirements.
        design patterns can improve a system's maintainability, reusability, and performance, but they don't address qualities such as testability, usability, and availability.
        
        Software architecture addresses these qualities by carefully structuring and coordinating design patterns in order to construct a unified system
        
        The architecture of a system is qualified by how well the entire combination of software elements work together to provide functionality and handle potential system issues
        
        In addition, the architecture is also qualified by how well the design addresses user experience and ease of development
        
        Software architecture is not inherently good or bad. That is to say that an architectural design doesn't have inherent qualities that make it a good architecture or a bad architecture. Software architecture is designed to address a set of requirements. These requirements are used to address a problem or need.
        
        For example, an online web based game will use an event-based architecture over a repository-based architecture in order to facilitate communications between players. This doesn't mean that a repository-based architecture is bad just because of its inherent design. It is bad because it simply isn't the correct design for the software environment.
        
        In fact, your system will most likely use a combination of architectural designs. The requirements for modern systems are complex and there may not be a clear cut software architecture that is capable of addressing all the requirements.
        
        The quality of a system is determined by quality attributes. They are measurable properties of a system used to gauge a system's design, run time performance, and usability
        
        See Images
        
        Analyzing and Evaluating
        
        how do we perform the measurement? All quality attributes use quality attribute scenarios to determine if a system is able to meet the requirements that are set for the quality attribute. There are two types of scenarios, general and concrete
        
        1 more item...
        
        Architecture Trade-off Analysis Method
        ATAM
        
        3 more items...
- - - - Call Tree: this will lead to directed graph and structure is hierarchal
      - Data is stored as variables
- - - - Interpreters can be used to run scripts and macros. Systems can use an interpreter to drive programmable actions specified by the user. Scripts are often used for automating common tasks.
- - - - The frequency or how often the loop runs, depends on the desired level of control and the sensitivity of the system
        For example, controlling a self-driving car has much tighter timing constraints than controlling a room's temperature
- - - - if only a small amount of communication is passed through, the you can continue using layers. The layered architecture can be relaxed by allowing for pass-through
    - - Layered architecture follows the principle of least knowledge. Each layer only interacts directly with adjacent layers
      - Layers also use abstraction
- - - - It ensures loose and flexible coupling of components, the filters. Each filter runs independently of other filters, only focusing on its input and output data, which allows you to easily add newly developed filters or move filters around in a system to achieve different results
      - Another advantage is that filters can be treated as black boxes. Users of the system do not need to know the inner workings of each filter
      - Finally, a main advantage of this type of architecture is reusability. Each filter can be called and used over and over again with different inputs. Filters can be repeatedly used in different applications for different purposes.
      - Drawbacks
        
        One disadvantage is that it may reduce performance due to excessive overheads in filters
        
        For this type of architecture, each filter will receive input, parse that input into some data structure, perform transformations, and then send data out. The next filter will do the same thing, parse the input into a data structure, do transformations, and send data to another filter, which will also do the same thing. If each and every filter has to do this process with similar parsing at output stages, that's a lot of overhead.
        
        While one filter is working hard to process the large amount of data, other filters may be starved waiting for their inputs.
        
        The last important disadvantage for this type of architecture is that it cannot be used for interactive applications. The data transfers and transformations will take time depending on the amount of data transmitted. So this type of architecture is not suitable for applications that require rapid responses
- - - - Every time a new message is ready to be published, the publisher makes a procedure call to each subscriber to deliver the new message. This can become a lot of work for the publisher as the number of subscribers grow
      - This is achieved by introducing a connector to distribute and possibly filter the messages to the subscribers. The connector could be an event bus or a network protocol. The connector creates more distance between publishers and subscribers and relieves work for the publisher. These connectors may provide complex filtering of messages before they are delivered to the subscribers.