Please enable JavaScript.

Coggle requires JavaScript to display documents.

INTRODUCTION TO SOFTWARE ARCHITECTURE, 4 + 1 ViewModel - Coggle Diagram

- - - - Highlights early design decisions
      - Shows how system is structured
      - Covers functional and non-functional requirements
      - Blueprint guideline for development
    - - Analysis of trade-off on quality attributes
      - System static partition and decomposition
      - Establishing dynamic control between subsystems
      - Considering and evaluating all alternative
        architectural styles
  - - - Connectors that enable communication,
        coordination, and cooperation among elements
      - Constraints that define how elements are integrated
        to form the system
      - Elements that perform functions required by a
        system
      - Attributes that describe the advantages and disadvantages of
        the chosen structure
    - - Each architecture style has its advantages, disadvantages, and potential risks. Choosing the right style to satisfy required functions and quality attributes is very important
      - Quality attributes are identified in the requirement
        analysis process
      - Depends on how quality attributes are satisfied
    - - An architecture style (also known as an "architecture pattern") abstracts the common properties of a family of similar designs.
      - It governs runtime interaction of flow control and data
        transfer
      - It contains a set of rules, constraints, and patterns of how to
        structure a system into a set of elements and connectors
    - - Architecture style represent
      - Once overall structure determined, rest are easy
      - Save time & cost on design
  - - - is to build a modal that meet all customer requirement and lead to successful implementation
    - - Who is responsible for develop structure design ?
        That is Software architect and designer
        
        They map Software Requirement into Architecture
        design
        
        They apply various design strategies to divide and
        conquer the complexities.
      - It define the relationship between major
        structural elements
      - It also define the style of design pattern used to achieve requirement
      - Also the constraint that effect the way
        architecture can be implements
      - The architecture of system is it's skeleton. It is
        a highest level of a system.
      - Software architecture is more about the design of the entire system, while software design emphasizes on module/component/class level
    - - Poor Design
        
        May result deficient product
        
        Not Reusable
        
        Is not adaptive to future requirement changes
      - Good Design
        
        Reduce risk associate with SW production
        
        makes the system traceable for implementation and testing, and
        leads to software products that have higher quality attributes
        
        Helps development team works together in an
        orderly fashion
    - - Design (architecture and detail) ==> SDD
      - Implementation
      - Specification Analysis => SRS
      - Testing and maintenance
    - - Functional Requirement
        
        Serve as contract between Developer and customer
      - Non-Functional Requirement
      - System constraint and pre-condition
    - - Component of the systemt
      - Module of each Component
      - Software Design Description (SDD): an overall representation of the software to be build
      - Detail information of each module
        
        Operation
        
        Data attribtute
        
        Developer
    - - Architectural Design
        
        Describe user accessible components and the interconnection among them that are visible to stackholder
      - Detail / Tactical Design
        
        Specify the internal detail of each component to
        stack holder, into design
      - Architectural Design is font strategy for
        detail Design
  - - - Security
      - Performance
      - Availability
      - Usability
    - - Cost
      - Lifetime
      - Time to market
    - - Testability
      - Portability
      - Maintainability & Extensibility
      - Scalability
      - Fexibility
      - Interoperability
        
        Universal accessibility and ability to exchange data among
        internal components and the outside world
    - - Reliability & Performance
      - Scalability vs Performance
      - Space and time
  - - - Balance the quality attributes, and consider
        eterogeneous architecture styles when necessary
      - The earlier the better
      - Speed, Reliability, Security have to be considered
        first
      - Otherwise, very hard to change your design to
        reflect these requirements
      - t is not possible to find a design that meets all
        quality attributes.
    - - Try to promote high cohesion within each element and loose-coupling between elements.
      - One component (module) should be assigned ONE functionality only
      - Design should be logically clear
      - The less correlation between modules, the better!
      - Easy to debug and maintainance
      - Also allows great extensibility
    - - Never expect to have software design completely perfect within one step.
      - We may need to use prototyping and iteration to refine the software design
    - - Nail down the interface but leave room of change for
        implementation
      - Always start with abtraction
      - Use multiple abstraction level if nessesary
      - Using an abstract architectural design of a system to communicate with stakeholders helps avoid overhauling the system design in later stages of the software development cycle.
      - Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
    - - Ambiguous design lack constraints
      - Over-detailed design restricts implementation
    - - Clarify priority of all requirements before design
      - System requirements (functional and non-functional requirements) must be nailed down before design starts
    - - User requirement can change frequency
      - Extensibility is very important
      - Leave room for expansion
      - Always try hard to make SW extensible in the future
      - we need to consider how to reuse existing software components to
        increase the reliability and cost-effectiveness of new systems
- - - - A software project typically implement in multiple files.
        
        Binary software component modules
        
        Deployment Description
        
        Library files
        
        Others Resource Files
        
        Executable files
      - Static Connector may exhibit some
        attribute
        
        Direction
        
        Synchronization
        
        Sequence
      - At SW deploy time
        
        The main software elements are source code files
        
        Each modules has assigned functional and nonfunctional attributes
        
        API defined for modules separates module’s interface and implementation
        
        The connectors at this level are in the form of module dependency
        
        Module A is connected to module B, if, A needs to invoke some methods in B during execution.
      - Managing Static Structural
        Representations
        
        Static structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability
        
        It plays a crucial role in the management of large software systems because it deals with the packaging of software modules in order to facilitate system construction and maintenance through a clear portrayal of intermodule relations.
        
        The SW static Structure
        
        refers to the organization of physical software modules and their interrelations
        
        This structure play a critical roles in software architecture design
        
        Managing static structures
        involves layers of:
        
        Abstraction for encapsulation
        
        Refinement showing visibility
        
        two kinds of static hierarchical
        relations
        
        A linear client-server relation is formed when a component provides
        primitive abstractions to another component
        
        A tree-like hierarchy of refinement relations is formed when an abstraction is implemented, and recursively divides into subcomponents. A refinement relation specifies how a module (parent) is decomposed into a refinement module (child)
    - - Software runtime structure serve as technical backbone of architecture
        design and provide a basic from which other structure are derived
      - Software Runtime Element
        
        Several code structure elements may implement or support a
        single runtime element
        
        The same element in a code structure can implement or
        support multiple runtime elements
      - These elements may run on the same computer or
        on multiple computers across a network
      - Runtime Connector Properties
        
        Runtime connectors inherit attributes from their source-code structure counterparts, with a few extra attributes
        
        Multiplicity
        
        One element can be connected to multiple elements if it
        needs to invoke methods of multiple elements at runtime.
        
        Distance and connection media
        
        Two connected element may communicate in the same thread, in the same process , on the same computers, or on different computers across a network
        
        Universal Invokable
        
        A connector with this attribute set to true allows any external software system to invoke the methods at the connector’s target, irrespective of hardware/software platform, and programming languages
        
        Importance to heterogeneous system
        
        seft-description
        
        A connector with this attribute set to true allows any external software system to invoke its target method without pre-installation of any software specific to the method.
        
        it allows clients to choose service providers dynamically.
      - Consist of these Element
        
        Threads
        
        WebServices
        
        Processes
        
        Distribute Object
  - - - Rule 1: Reetrant
        
        A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program
        
        A computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing.
        
        Reentrant describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users
      - Make thing simple
        
        Vertical Layer : Each upper layer calls the functionality of lower layers
        
        Horizon Layer: Business logic divided into a sequence of stages
      - Handle Bottle-neck first
        
        (1) Wrap it as a separate and highly independent module
        
        (2) Improving its efficiency by replication
        
        (3) Depending on computing needs, allocate cluster or multi-CPU computers for bottle-neck modules in deployment
  - - - Proposing a concrete architecture that best support the details design and implementation of a specific project
    - - Design alternative that can support functional and
        non-functional requirement specifications
    - - What are popular building elements?
      - What are popular connectors?
      - What are popular structures?
  - - - Big gap between Requirement specification &
        Software Architecture
    - - Refine design base on changing
        requirement
  - - - Environment Resource
      - Message
      - Method
      - Variable
    - - Protocal-based
        
        A protocol-based connector can implement multiple operation
        types with a single binding signature
      - Signature-based
        
        Usually method invocation
        
        Signature: the method name plus the list of parameter types
        
        Method parameter indicates operation type
    - - One-Initiator
        
        It only allows one of the two connected elements initiates
        the request, but not another way around
      - Two Initiator
        
        either of the two elements can make the
        request
    - - Programmed
        
        A method call will be made at a time
        specified at programming time
      - Event-driven
        
        One element will function as an event source
        
        All elements that need be notified of the event will register as listeners of the event source
        
        When the event happens, all the registered listener elements will be notified for potential reaction
    - - Non-Blocking
        
        A non-blocking connector allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
      - Blocking
        
        A blocking connector allows one of its incident elements to send a request to another and wait for a response.
        
        The element will be blocked from further execution until it receives a response
    - - Depend on connector
        span
        
        Local
        
        Network
      - Typical Examples
        
        Distributed Remote
        Method Invocation (RMI)
        
        Remote Procedure Call
        (RPC)
        
        Local method invocation,
        function call (local)
      - Network Connectors need more efforts
        
        Invocation semantics (tricky)
        
        Reliability (hard)
        
        Security (problematic, e.g. RPC)
        
        However, desperately needed by distributed computing environments.
    - - Heterogeneous
        
        Both Element can be on
        different platform
      - Homogeneous
        
        Both Element must be on the
        same platform
    - - Should be refine within design process
      - Connector refinement is heavily influenced by project's deployment environment
      - Usually determines the quality attribute of a system
        
        Availability
        
        Security
        
        Reliability
        
        Efficiency
      - Can be classify into many categories
      - Connect the modules of system
- - - - Composite Structure Diagram
        
        Purpose
        
        internal structure of a classifier - internal structure diagram,
        
        classifier interactions with environment through ports
        
        a behavior of a collaboration - collaboration use diagram
        
        Show
        
        Internal Structure Diagrams
        
        Purpose
        
        shows internal structure of a classifier
        
        Element
        
        class
        
        connector
        
        port
        
        part
        
        usage
        
        Collaboration Use Diagrams
        
        Behavior
        
        dependency
        
        connector
        
        collaboration specialization
        
        collaboration
        
        part
      - Component Diagram
        
        Element
        
        component
        
        provided interface
        
        interface
        
        usage
        
        component realization
        
        port
        
        artiface
        
        required interface
        
        connector
        
        class
        
        Purpose
        
        shows components, provided and required interfaces, ports
        
        relationships between above
        
        Used in
        
        Component-Based Development (CBD) to describe systems with
        Service-Oriented Architecture (SOA)
      - Package Diagram
        
        Element
        
        package
        
        packageable element
        
        dependency
        
        element import
        
        package import
        
        package merge
        
        Purpose
        
        Shows packages and relationships between the packages
      - Profile
        Diagram
        
        Note
        
        Metamodel for different
        
        platforms
        
        Java Platform, Enterprise Edition (Java EE) or Microsoft .NET
        Framework
        
        domains
        
        business process modeling, service-oriented architecture,
        medical applications, etc.
        
        can be dynamically applied to or retracted from a model
        
        can also be dynamically combined so that several profiles will be
        applied at the same time on the same mode
        
        Graphical nodes and edges
        
        profile
        
        stereotype
        
        metaclass
        
        reference
        
        profile application
        
        extension
        
        Purpose
        
        deploy
        
        describes lightweight extension mechanism to the UML by defining custom stereotypes
        
        tagged values\
        
        constraints
      - Object Diagram
        
        Notes
        
        (UML 2.5) no definition of object diagram
        
        (UML 1.4.2) a class diagram with objects and no classes
        
        Element
        
        instance specification
        
        object
        
        link
        
        slot
        
        Purpose
        
        slots with value specifications
        
        instance specifications of classes and interfaces (objects)
        
        links (instances of association)
      - Deployment Diagram
        
        Element
        
        device
        
        execution
        
        deployment
        
        deployment target
        
        artifact
        
        environment
        
        communication path
        
        node
        
        deployment specification
        
        Note
        
        could describe architecture
        
        instance level (similar to class diagrams and object diagrams)
        
        specification level (also called type level)
        
        Common Type
        
        Instance level deployment diagram
        
        Network architecture of the system
        
        Specification level deployment diagram
        
        Implementation (manifestation) of components by artifacts
        
        Purpose
        
        shows architecture of the system as deployment (distribution) of
        software artifacts to deployment targets
      - Class Diagram
        
        Purpose
        
        Shows structure of the designed system, subsystem
        
        Show features,constraints and relationships - associations,
        generalizations, dependencies, etc.
        
        level of classes and interfaces
        
        Common types
        
        diagram of implementation classes
        
        domain model diagram
        
        Element
        
        feature
        
        association
        
        dependency
        
        constraint
        
        class
        
        inteface
        
        generalization
      - Show
        
        Static structure
      - Represent
        
        The elements the meaningful of a
        system concepts
    - - Activity Diagram
        
        Purpose
        
        object flow with emphasis on the sequence and conditions of the
        flow
        
        shows flow of contro
        
        Nodes and edges
        
        object
        
        activity edge
        
        is an abstract class for the directed connections along which
        tokens or data objects flow between activity nodes
        
        Include
        
        control edges
        
        object flow edges
        
        used to show data flow of object and data tokens between action
        nodes
        
        The weight
        
        1 more item...
        
        Interrupting Edge
        
        expressing interruption for regions having interruptions. It is
        rendered as a lightning-bolt.
        
        partition
        
        is activity group for actions that have some common
        characteristic
        
        Constraints
        
        instance
        
        attribute and value
        
        part
        
        classifier
        
        control
        
        action
        
        activity
        
        Nodes
        
        action
        
        control
        
        object
        
        is a parameterized behavior represented as coordinated flow o
        actions
        
        UML allows behaviors to produce tokens that are activities and
        which can in turn be executed at the runtime
        
        actions
        
        Invocations of behavior, such as activities.
        
        Communication actions, such as sending of signals.
        
        Occurrences of primitive functions, such as arithmetic functions.
        
        Manipulations of objects, such as reading or writing attributes or
        associations.
      - Interaction Diagram
        
        Types
        
        sequence diagrams
        
        focuses on the message nterchange between a number of lifelines
        
        Nodes and adges
        
        lifeline
        
        represents an individual participant in the interaction
        
        interaction use
        
        allows to use (or call) another interaction
        
        state invariant
        
        represents a runtime constraint on the participants of the
        interaction
        
        execution specification
        
        represents a period in the participant's lifetime
        
        message
        
        combined fragment
        
        destruction occurrence
        
        continuation
        
        timing diagrams
        
        Notes
        
        Duration Constraint
        
        is an interval constraint that refers to a duration interval
        
        Lifeline
        
        represents an individual participant in the interaction
        
        Time Constraint
        
        is an interval constraint that refers to a time interva
        
        Destruction Occurrence
        
        is a message occurrence which represents the destruction of the
        instance described by the lifeline
        
        State or Condition Timelin
        
        could show states of the participating classifier or attribute, or
        some testable conditions
        
        Purpose
        
        show interactions when a primary purpose of the diagram is to
        reason about time
        
        communication diagrams
        
        Purpose
        
        shows interactions between objects and/or parts (represented as
        lifelines) using sequenced messages in a free-form arrangement
        
        Nodes and Edges
        
        lifeline
        
        represents an individual participant in the interaction
        
        frame
        
        Communication diagrams could be shown within a rectangular
        frame with the name in a compartment in the upper left corner
        
        message
        
        shown as a line with sequence expression and
        arrow above the line
        
        interaction overview diagrams
        
        Elements
        
        merge node
        
        flow final node
        
        activity final node
        
        join node
        
        fork node
        
        decision node
        
        initial node
        
        could be used on the interaction overview diagrams
        
        duration constraint
        
        time constraint
        
        interaction
        
        interaction use
        
        Purpose
        
        provide overview of the flow of control where nodes of the flow
        are interactions or interaction uses
      - State Machine Diagram
        
        Purpose
        
        shows discrete behavior of a part of designed system through
        finite state transitions
        
        Types
        
        behavioral state machine
        
        specify discrete behavior of a part of designed system through
        finite state transitions
        
        Behavioral State
        
        Vertex
        
        pseudostate
        
        State is a vertex which models a situation during which some
        (usually implicit) invariant condition holds
        
        state
        
        Final State
        
        Pseudostate
        
        Region
        
        Behavioral Transition
        
        Kinds
        
        3 more items...
        
        State in behavioral state machines models a situation during
        which some (usually implicit) invariant condition holds
        
        protocol state machine
        
        is a specialization of behavioral state machine and is used to
        express usage protocol or lifecycle of a classifier
        
        Elements
        
        protocol state
        
        present an external view of the class that is exposed to its clients
        
        pseudostates
        
        protocol transition
        
        is specialization of (behavioral) transition used for the protocol
        state machines which specifies a legal transition for an operation
        
        shows which operations of the classifier may be called in each state of the classifier, under which specific conditions, and satisfying some optional postconditions after the classifier transitions to a target state
      - UseCase Diagram
        
        Purpose
        
        describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors)
        
        Business Use Case Diagrams
        
        Elements
        
        business boundary
        
        business use case
        
        extend relationships
        
        include
        
        business actor
        
        represent business function, process, or activity performed in the
        modeled business
        
        Notes
        
        UML 2.5 FTF - Beta 1 [UML 2.5 FTF - Beta 1]
        
        UML 2.0 to 2.4 specialization of a class diagram
        
        System Use Case Diagrams
        
        Purpose
        
        the functionality offered by a subject – what the system can do
        
        requirements the specified subject poses on its environment
        
        (external) requirements, required usages of a system under design or analysis (subject) - to capture what the system is supposed to do
        
        Elements
        
        use case
        
        actor
        
        include
        
        extend relationships
        
        subject
- - - - For example, we are hiding the name and dob attributes of
        person class in the below code snippet.
      - Encapsulation is the mechanism of hiding of data implementation by restricting access to public methods. Instance variables are kept private and accessor methods are made public to achieve thi
    - - Abstract means a concept or an Idea which is not associated with any particular instance. Using abstract class/Interface we express the intent of the class rather than the actual implementation. In a way, one class should not know the inner details of another in order to use it, just knowing the interfaces should be good enough.
      - Another real-life example of abstraction?
        Think about how you use your phone:
        You interact with your phone by using only a few buttons. What’s going on under the hood? You don’t have to know — implementation details are hidden. You only need to know a short set of actions.
    - - Inheritances expresses “is-a” and/or “has-a” relationship between two objects. Using Inheritance, In derived classe we can reuse the code of existing super classes. In Java, concept of “is-a” is based on class inheritance (using extends) or interface implementation (using implements)
      - For example, FileInputStream "is-a" InputStream that reads
        from a file.
    - - Take a look at a sketch of geometric figures implementation They reuse a common interface for calculating surface area and perimeter: If you have a function which operates with a figure by using its parameter you don’t have to define it three times — once for a triangle a circle, and a rectangle
      - It means one name many forms. It is further of two types — static and dynamic. Static polymorphism is achieved using method overloading and dynamic polymorphism using method overriding. It is closely related to inheritance. We can write a code that works on the superclass, and it will work with any subclass type as well.
- - - - An actor does not necessarily represent a specific physical entity
        but merely a particular role of some entity
      - A person may play the role of several different actors and,
        conversely, a given actor may be played by multiple different
        person
    - - Model high-level interaction between active objects in a system
      - Model the interaction between object instances within a
        collaboration that realizes a use case
      - Model the interaction between objects within a collaboration that
        realizes an operation
      - Either model generic interactions (showing all possible paths through the interaction) or specific instances of a interaction (showing just one path through the interaction)
  - - - Model message passing between objects or roles that deliver the
        functionalities of use cases and operations
      - Support the identification of objects (hence classes), and their attributes (parameters of message) and operations (messages) that participate in use cases
      - Model mechanisms within the architectural design of the system
      - Capture interactions that show the passed messages between
        objects and roles within the collaboration scenario
      - Model alternative scenarios within use cases or operations that
        involve the collaboration of different objects and interactions
    - - The top and the bottom of the rectangle are aligned with the
        initiation and the completion time respectively.
      - In communication diagram focus of control is explicit and thus,
        can be represented by the message nest numbering.
- - - - Helpful for developers and other team members too
      - Business Analysts can use class diagrams to model systems
        from business perspective
      - Shows static structure of classifiers in a system
    - - Class Operations
        
        (~) Package
        
        (-) Private
        
        (+) Public
        
        (#) Protected
      - Class Relationships Type
        
        Simple Association: A structural link between two peer classes
        
        Aggregation: A special type of association. It represents a "part
        of" relationship
        
        Inheritance (or Generalization): Represents an "is-a" relationship
        
        Composition: A special type of aggregation where parts are
        destroyed when the whole is destroyed.
        
        Dependency: Exists between two classes if changes to the
        definition of one may cause changes to the other
      - Relationship - Roles
        
        A role is a directional purpose of an association.
        
        Roles are written at the ends of an association line and describe the purpose played by that class in the relationship.
  - - - Before you create a class diagram, You might create an object diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.
      - During the analysis phase of a project, You might create a class diagram to describe the structure of a system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram.
  - - - Show internal structure of a classifier - internal structure diagram
      - Show a behavior of a collaboration - collaboration use diagram.
      - Show classifier interactions with environment through ports,
- - - - help to understand the structure of existing systems and then
        build new ones.
      - it is used for component based system...which include
        constructed component that can be reused or replaced.
- - - - You can describe those details in other UML diagram types and
        documents, and have them be linked from use cases.
      - Use cases represent only functional requirements of a system.
    - - Specify the context of a system
      - Capture the requirements of a system
      - Developed by analysts together with domain experts
      - Validate a systems architecture
      - Drive implementation and generate test cases
  - - - Who it is for?
      - What it expects from the system?
      - Why it is important (optional?)?
    - - Avoid the appearance of false completeness and clarity
      - The simple and consistent format saves time when capturing and prioritizing requirements while remaining versatile enough to be used on large and small features alike.
      - Keep yourself expressing business value by delivering a product
        that the client really needs
      - Avoid introducing detail too early that would prevent design
        options and inappropriately lock developers into one solution
      - Get to small enough chunks that invite negotiation and
        movement in the backlog
      - Leave the technical functions to the architect, developers,
        testers, and so on