Please enable JavaScript.

Coggle requires JavaScript to display documents.

SWD, SWD, SWD, image, swd - Coggle Diagram

- - - - Software architecture specifies a high-level of abstraction of a software system by employing decomposition, composition, architectural styles, and quality attributes.
      - Every software architecture must describe the collection of software components and the connections and interactions between these components.
      - It must also specify the deployment configuration of all components and connections. Additionally, a software architectural design must conform to the functional and non-functional requirements of the software project.
    - - There are many effective ways to describe the software architecture formally or informally.
      - Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle.
      - It comes with descriptions of components and connectors, accompanied by other descriptions that provide common intuitive interpretations.
  - - - Class Diagram
        
        Definition
        
        Class diagram is UML structure diagram which shows structure of the designed system at the level of classes and interfaces, shows their features, constraints and relationships - associations, generalizations, dependencies, etc.
        
        Purpose
        
        Analysis and design of the static view of an application.
        
        Describe responsibilities of a system.
        
        Base for component and deployment diagrams.
        
        Forward and reverse engineering.
        
        Notation
      - Component Diagram
      - Package Diagram
      - Deployment Diagram
    - - Use Case Diagram
      - Activity Diagram
      - State Machine Diagram
      - Sequence Diagram
    - - As OMG states that “the Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.”
  - - - Represent by:
        
        Use case diagram
      - Consider
        
        System Consistency and validity
      - Viewer
        
        All the views of their views and evaluators
      - Uses
        
        The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.
      - Description
        
        Shows the design is complete by performing validation and illustration
    - - Description
        
        Shows the installation, configuration and deployment of software application
      - Consider
        
        Nonfunctional requirement regarding to underlying hardware
      - Viewer
        
        System installers
        
        system administrators
        
        System engineer
        
        Operators
      - Represent by:
        
        Deployment diagram
      - Uses:
        
        The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer as well as the physical connections between these components. This view is also known as the deployment view.
    - - Consider
        
        Functional requirements
      - Viewer
        
        Designer
        
        Analysts
        
        End-User
      - Description
        
        Shows the component (Object) of system as well as their interaction
      - Represent by:
        
        Communication diagrams
        
        Sequence diagrams
        
        Object diagrams
        
        State diagrams
        
        Class diagrams
      - Uses:
        
        The logical view is concerned with the functionality that the system provides to end-users.
    - - Consider
        
        Software Module organization (Software management reuse, constraint of tools)
      - Viewer
        
        Software project managers
        
        Programmer
      - Description
        
        Gives building block views of system and describe static organization of the system modules
      - Represent by:
        
        Component diagram
        
        Package diagram
      - Uses:
        
        The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view.
    - - Consider
        
        Non Functional Requirements
      - Viewer
        
        Developers
        
        Integrators
      - Description
        
        Shows the processes / Workflow rules of system and how those processes communicate, focuses on dynamic view of system
      - Represent by:
        
        Activity diagram
        
        Communication diagram
        
        Sequence diagram
      - Uses:
        
        The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the run time behavior of the system. The process view addresses concurrency, distribution, integrator, performance, and scalability,...
- - - - Architecture design developers
        
        Software architect, software designer & system analyst:
        
        They map the software system requirements into architecture design
        
        They apply various design strategies to divide and conquer the complexities
        
        • Jobs of Software Architect:
        
        System static partition and decomposition
        
        Establishing dynamic control between subsystems
        
        Considering and evaluating all alternative architectural styles
        
        Analysis of trade-off on quality attributes
      - Why software architecture design is important
        
        Poor design:
        
        May result in deficient product (does not meet system requirements)
        
        Is not adaptive to future requirement changes
        
        Not reusable
        
        Exhibits unpredictable behaviour or perform badly
        
        Good design:
        
        Reduces the risks associated with software production
        
        Helps development team works together in an orderly fashion
        
        Makes the system traceable for implementation and testing, and leads to software products that have higher quality attributes.
      - Two Steps in Software Design
        
        Architecture Design:
        
        Describe user accessible components and the interconnections among them that are visible to stakeholders
        
        Is front strategy for detailed design
        
        Detailed Design/Tactical Design
        
        Specify the internal details of each component and might introduce new invisible components to the stakeholders
      - What is architectural design?
        
        It defines the relationship between major structural elements
        
        It also define the styles and design patterns used to achieve requirements.
        
        Also the constraints that affects the way architecture can be implemented
    - - Describes high and low level design:
        
        Components of the system
        
        Modules of each components
        
        Detailed information of each module
        
        Data attributes
        
        Operations
        
        Developer
        
        DB oriented application - data dictionary:
        
        Tables, columns and definition of terms.
      - A sample outline of SDD:
        
        Design overview, purpose and scope
        
        Decomposition description (module, data, and process)
        
        Dependency and connection
        
        Attributes
        
        User interfaces
        
        Detailed design
    - - What
        
        An architecture style (also known as an "architecture pattern") abstracts the common properties of a family of similar designs.
        
        It contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
        
        It governs runtime interaction of flow control and data transfer.
      - Key components
        
        Elements that perform functions required by a system
        
        Connectors that enable communication, coordination, and cooperation among elements
        
        Constraints that define how elements are integrated to form the system
        
        Attributes that describe the advantages and disadvantages of the chosen structure
      - Purposes
        
        Saves cost and time on design
        
        Architecture style represents layout topology of elements
        
        Once overall structure determined, rest are easy
      - Some architecture styles
        
        Data Flow: Batch sequence, Pipe & Filter, Process Control
        
        Data Centered: Repository and Blackboard
        
        Object Oriented
        
        Hierarchy: Layered, Virtual Machine Main/Subroutine
        
        Asynchronous Communication: Event-Based, Buffered Messaging
        
        Interaction Oriented: MVC, PAC
    - - Implementation Attributes
        
        Maintainability & Extensibility: The ability to modify the system and conveniently extend it
        
        Testability: Whether the system allows easy debugging
        
        Portability: Can the system be deployed on different platforms
        
        Scalability: Can system adapt to increase of requests
        
        Flexibility: Ease of modification of system to cater to a different environment
        
        Interoperability
        
        Universal accessibility and ability to exchange data among internal components and the outside world
        
        Requires loose dependency of infrastructure
      - Runtime Attributes
        
        Security: The ability to defend against attacks
        
        Performance: Time efficiency and resource efficiency
        
        Usability: Completeness, correctness, compatibility and user friendliness
        
        Availability:
        
        If system is available 24/7
        
        Can be enhanced by replication
      - Business Attributes
        
        Time to market: The time it takes from requirement analysis to the product is released
        
        Cost: Expense of the building, maintaining, and operating the system
        
        Lifetime: The period of time that the product is alive before retirement
    - - Definition
        
        The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principle guiding its design and evolution
      - Role of software architecture:
        
        Highlights early design decisions
        
        Shows how system is structured
        
        Covers functional and non-functional requirements
        
        Blueprint guideline for development
    - - Think about abstract design before thinking about concrete design
      - Think of What to Do before How to Do It
      - Think of non-functional requirements early in design process
      - Think of reusability and extensibility
      - High Cohesion and Loose Coupling
      - Tolerate refinement of design
      - Avoid ambiguous design and over-detailed design
- - - - A software architect’s responsibility
        
        Proposing a concrete architecture that best supports:
        
        The detailed design
        
        Implementation
        
        Understand the software architecture's design space to design alternatives that can support functional and non-functional requirement specifications
        
        Make the decision by balancing on quality attributes
    - - Software architecture in multiple Perspectives
        
        Software Static Structure
        
        What & Role
        
        Definition: The software static structure refers to the organization of physical software modules and their interrelations
        
        Roles
        
        This structure play a critical roles in software architecture design.
        
        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.
        
        Components
        
        A software project is typically implemented in multiple files. This includes
        
        Executable files
        
        Library files
        
        Binary software component modules
        
        Deployment descriptors
        
        Others resources files
        
        At software development 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.
        
        At deployment time:
        
        The elements are binary versions of the project modules and files.
        
        Several source code modules may be packaged into the same deployment unit
        
        The connectors in the deployment structures are basically the same as those for the source module structures
        
        Managing Static Structural Representations
        
        Managing static structures involves layers of:
        
        Abstraction for encapsulation
        
        Refinement showing visibility
        
        Two kinds of static hierarchical relations:
        
        Linear client-server relation
        
        Tree-like hierarchy of refinement relation
        
        Software Run-time Structure
        
        Role
        
        Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
        
        Elements
        
        Processes
        
        Threads
        
        Web services
        
        Distributed objects
        
        Connectors
        
        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
        
        Copper/optical
        
        Wired/wireless LAN
        
        Decides the system performance and reliability
        
        Universal invocable:
        
        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
        
        Important for heterogeneous system.
        
        Self-descriptive:
        
        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.
        
        Management structure (or Deployment structure)
      - Different structures use different elements and connectors, and have different performance attributes
    - - At runtime, element is a self-contained component of a system
        
        Has well-defined functions
        
        Usually interface is public and fixed, and
        
        Implementation can change with the time
        
        Connected with each other via connector
      - Software Architects Job
        
        Map functional requirements to software elements
        
        Some rules on designing software elements:
        
        Rule 1: Re-entrant
        
        Rule 2: Handle Bottleneck First
        
        Rule 3: Make Things Simple
    - - Definition & Properties
        
        Connects the modules of a system
        
        Should be refined within the design process.
        
        Connector refinement is heavily influenced by a project’s deployment environment
        
        Usually determines the quality attributes of a system:
        
        Efficiency
        
        Reliability
        
        Availability
        
        Security
        
        Can be classified into many categories
      - Connector types – Based on synchronization
        
        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.
        
        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.
      - Connector types – Based on initiator
      - Connector types – Based on information carrier
      - Connector types – Based on implementation type
      - Connector types – Based on connector’s active time
    - - Traditional Water-Fall Approach: big gap between requirement specification & software architecture
      - Iterative Refinement: refine designs based on changing requirement
- - - - Object Oriented Approach
        
        • Object Oriented Software Engineering:
        
        o Object Oriented Analysis
        
        o Object Oriented Design
        
        o Object Oriented Programming
        
        • A very popular design approach since 1980’s, applies to many of the software architecture styles
        
        • Object oriented principles
        
        o Encapsualation: Often called information hiding. Separate interface from implementation. By hiding the implementation details that are likely to change -> allows for flexibility in design, easy teamwork working.
        
        o Inheritance: A class can inherit from its base class. Inheritance allows software reuse, hence improving the effectiveness of software development
        
        o Polymorphism: Refer to ability of an object to behave differently and assume different forms based on its inheritance hierarchy
        
        • Use of object oriented paradigm :
      - . Object Oriented Paradigm
        
        COMPONENTS
        
        Class
        
        Class consists of:
        
        • Public interface
        
        • Detailed implementation
        
        Definition of class usually consists of
        
        • “name” of the class: possibly included in a package or namespace
        
        • List of attributes
        
        • List of operations. Special operations: constructor, destructor, etc
        
        Accessibility Principle
        
        When assigning accessibility of an attribute (operation): expose as least information as possible
        
        . RELATIONSHIPS
        
        Relationship Among Classes
        
        • Instance Level Relationships:
        
        Association
        
        Aggregation
        
        Composition
        
        • Class Level Relationships
        
        o Generalization
        
        Realization
        
        • General Relationship
        
        Dependency
        
        External Link
        
        • A link is the basic relationship among objects.
        
        • It is represented as a line connecting two or more object boxes.
        
        • It can be shown on an object diagram or class diagram
        
        • A link is an instance of an association.
        
        • It creates a relationship between two classes
        
        Instant Level Relationships
        
        Association relationship:
        
        • An association is a connection between classes, a semantic connection (link) between objects of the classes involved in the association.
        
        • An association is normally bidirectional
        
        Aggregation relationship:
        
        • Aggregation is a special case of association.
        
        • A kind of “whole-part” relationship
        
        • Parts do not have to share the same lifespan as owner
        
        • In UML, aggregation is represented using a hollow diamond arrowhead
        
        Composition relationship:
        
        • Composition is a stronger variant of the "owns a“ relationship
        
        • Composition is more specific than aggregation
        
        • Requirement: the lifespan of “components” and “owner” involved in a composition relationship must be same.
        
        • Is represented using a solid diamond arrowhead
        
        Differences between Composition and Aggregation:
        
        • When attempting to represent real-world whole-part relationships, the composition relationship is most appropriate. Ex: An engine is part of a car
        
        • When representing a software or database relationship, an aggregation relationship is best
        
        Class Level Relationships
        
        Generalization relationship:
        
        • The generalization relationship is also known as the inheritance or "is a" relationship.
        
        • Subclass is considered to be a specialized form of super class. Super class is considered as 'Generalization' of subclass
        
        • The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line
        
        Inheritance vs Composition/Aggregation
        
        • Use inheritance only if derived class IS-A base class. E.g., HouseOwner is a Person
        
        • Composition/Aggregation is used to model HAS-A relationship. E.g., HouseOwner has a House
        
        • Careful about inheritance, sometimes, weakens the encapsulation principle
- - - - . Architecture View Models
        
        . THE 4+1 VIEW MODEL
        
        Components:
        
        • Properties:
        
        o The user interface view is also established during this process.
        
        o The views are interconnected; thus, based on the scenarios view, we can start with logical view, and then move to development or process view and, finally go to physical view
        
        o It covers all aspects of a software architecture for all stakeholders
        
        o Each view provides a window for the different aspects of the system
        
        o The view is an architecture verification technique for studying and documenting software architectural design.
        
        • 2 extended views
        
        o The scenario view is coherent with other four views, whereas the user interface view complies with the scenario view and is supported by the other four views.
        
        o The user interface (UI) view: for end users of the software system, describes the graphical interface to verify and validate the user interface requirements; these have significant impact on the system usability and other quality attributes.
        
        o The scenario view describes the scenarios that capture the most important aspects of the functional requirements and that drive the system design and system validation.
        
        • 4 essential views
        
        Scenarios:
        
        Represent by:
        
        1 more item...
        
        Consider
        
        1 more item...
        
        Viewer
        
        1 more item...
        
        Uses
        
        1 more item...
        
        Description
        
        1 more item...
        
        Physical view:
        
        Description
        
        1 more item...
        
        Consider
        
        1 more item...
        
        Viewer
        
        4 more items...
        
        Represent by:
        
        1 more item...
        
        Uses:
        
        1 more item...
        
        Logical view
        
        Consider
        
        1 more item...
        
        Viewer
        
        3 more items...
        
        Description
        
        1 more item...
        
        Represent by:
        
        5 more items...
        
        Uses:
        
        1 more item...
        
        Development view
        
        Consider
        
        1 more item...
        
        Viewer
        
        2 more items...
        
        Description
        
        1 more item...
        
        Represent by:
        
        2 more items...
        
        Uses:
        
        1 more item...
        
        Process view
        
        Consider
        
        1 more item...
        
        Viewer
        
        2 more items...
        
        Description
        
        1 more item...
        
        Represent by:
        
        3 more items...
        
        Uses:
        
        1 more item...
        
        Properties:
        
        • The 4+1 view model standardizes the software design documents and makes it easy to understand by all stakeholders
        
        • The 4+1 view model is a multiple-view model that addresses different aspects and concerns of the system.
        
        • The 4+1 view model was originally introduced by Philippe Kruchten in 1995
        
        • Stakeholders can use a corresponding view to find what they need in the software architecture.
        
        • Software designers can organize the description of their architectural decisions in different views.
        
        DEFINITION & PROPERTIES
        
        • Specific views models provide partial representations of the software architecture to a specific stakeholder such as system users, the analyst/designer, the developer/programmer, the system integrator, the system engineer, etc
        
        • There is no single view that can present all aspects of complex software to stakeholders.
        
        • A model is a complete, simplified description of a system from a particular perspective or viewpoint.
    - - CLASS DIAGRAM
        
        OBJECT DIAGRAM
        
        • Many other behavioral diagrams (sequence diagram, communication diagram, and interaction diagram) can make references to the object diagram
        
        • It is derived from the corresponding class diagram and it is a concrete example of the class diagram at runtime
        
        • This diagram shows a snapshot of class instance connection and interaction.
        
        • Each rectangle box in the diagram represents an object, which is an instance of some class
        
        • The object diagram is used to describe a sample subset of objects in the system at a point of time
        
        • Objects are the instances of classes.
        
        Relationships
        
        • In UML multiplicity notations, 1 stands for one instance, 0 stands for no instance, 0..1 stands for zero or one instance, and 1..* stands for at least one instance
        
        • Typical multiplicity types include one to one, one to many, and many to many mappings.
        
        • For each relationship, multiplicities between classes can be denoted.
        
        • They all can be represented graphically in a class diagram.
        
        • There are three main different relationships among classes: inheritance, aggregation, and association.
        
        Classes
        
        • A class interface provides the behavioral contracts that the class must support
        
        • One important part of a class diagram is the interface of each class.
        
        • Popular accessibility modifiers include private, public, protected, and default
        
        • The accessibility (visibility) of each attribute and operation can also be specified.
        
        • Class diagrams describe each individual class with its type, interface, properties, and methods
        
        Properties
        
        • A class diagram is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle
        
        • Class diagrams can be derived from use case diagrams or derived from text analysis on the given problem domain
        
        • It is the foundation diagram of the system design and it is the most frequently used UML diagram as well
        
        •This diagram provides a static view of the system. It captures the vocabulary of the designed system
    - - UML for Software Architecture
        
        Properties
        
        The dynamic software architecture describes the behavior of objects (i.e., instances of classes) in the system such as object collaboration, interaction, activity, and concurrency
        
        •UML provides several modeling diagrams that can be grouped into two major categories : Structural (static) and Behavioral (dynamic)
        
        • UML is a typical object oriented analysis and design notational tool that provides many useful diagrams that can be used to map requirement specifications to architectural designs and from these to coding
        
        • UML offers a standard way to draw a system’s blueprints, including conceptual notions such as business processes and system functions as well as concrete designs such as programming language statements, database schemas, and reusable software components
        
        Definition
        
        As OMG states that “the Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system
    - - Ways to describe software architecture
        
        • It comes with descriptions of components and connectors, accompanied by other descriptions that provide common intuitive interpretations
        
        •Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle
        
        •There are many effective ways to describe the software architecture formally or informally.
    - - •It must also specify the deployment configuration of all components and connections. Additionally, a software architectural design must conform to the functional and non-functional requirements of the software project
      - • Every software architecture must describe the collection of software components and the connections and interactions between these components
      - •Software architecture specifies a high-level of abstraction of a software system by employing decomposition, composition, architectural styles, and quality attributes.
- - - - • Whole system as transformation of successive sets of data.
      - • System decomposed into modules
      - • Connection can be
        
        o IO Stream
        
        o Files, Buffers, Pipes
      - • No interaction between modules
      - • Modules do not need to know identity of each other
      - • Block diagram:
    - - • Many sub-categories exist
        
        o Batch Sequential
        
        o Pipe & Filter
        
        o Process Control
      - • Adopting which one depends on the nature of the problem
      - 5.2. BATCH SEQUENTIAL
        
        • Properties:
        
        o Traditional data processing model
        
        o Widely used in 1950’s – 1970’s
        
        o Example: mainframe computers using COBOL
        
        • Implementation: usually done in batch processing language or shell script
        
        • Applicable design domains: data are batched
        
        • Benefits:
        
        o Simple division between sub-systems
        
        o Each sub-system can be a stand-alone
        
        • Limitation:
        
        o No interactive interface
        
        o No concurrency and low throughput
        
        o High latency
      - 5.3. PIPE & FILTER
        
        Comparing to batch sequential
        
        • Similarities:
        
        o Independent modules
        
        o Data connectors
        
        • Difference
        
        o Connectors are stream oriented
        
        o Concurrent processing
        
        Basic concepts
        
        • Filter: independent data stream transformer
        
        o Reads data from input data stream
        
        o Process data and write to output stream
        
        o Does not wait for batched data as a whole
        
        o Does not even have to know identity of i/o streams
        
        • Pipe: data conduit
        
        o Moves data from one filter to another
        
        o Two types: character or byte streams
        
        • Data Source
        
        • Data Sink
        
        Data Flow Methods
        
        • Push only (Write only)
        
        o A data source may push data in a downstream
        
        o A filter may push data in a downstream
        
        • Pull only (Read only)
        
        o A data sink may pull data from an upstream
        
        o Filter may pull data from an upstream
        
        • Pull/Push (Read/Write)
        
        o A filter may pull data from an upstream and push transformed data in a downstream.
        
        Classification of Filters
        
        • Active Filter:
        
        o pulls in data and push out the transformed data (pull/push)
        
        o It works with a passive pipe that provides read/write mechanisms for pulling and pushing.
        
        • Passive filter
        
        o Lets connected pipe to push data in and pull data out.
        
        o The filter must provide read/write mechanisms in this case.
        
        Advantages & Disavantages
        
        Advantages:
        
        • Concurrency is high.
        
        • Reusability is easy – plug and play.
        
        • Modifiability: Low due to coupling between filters
        
        • Simplicity: Clear
        
        • Flexibility: High, very modular design
        
        • Lower latency
        
        Disavantages:
        
        • Not suitable for dynamic interactions
        
        • Data standards (ASCII, XML?)
        
        • Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
        
        • Difficult to configure a P&F system dynamically.
        
        • Error handling issue
      - 5.4. PROCESS CONTROL MODEL
        
        Properties
        
        • Composed of:
        
        o Sub-systems
        
        o Connectors
        
        • Two types of sub-systems:
        
        o executor processor unit
        
        o controller unit
        
        • System depends on: Control Variables
        
        Data
        
        • Controlled variable: target controlled variable
        
        o E.g., Speed in a cruise control system
        
        o E.g., Temperature in an auto H/A system.
        
        • Input variable: measured input data
        
        • Manipulated variable: can be adjusted by the controller
        
        • General architecture
        
        Applicable Domains
        
        • Embedded software system involving continuing actions.
        
        • Needs to maintain an output data at a stable level.
        
        • The system has a set point which is the goal the system will reach and stay at that level.
        
        Pros and Cons
        
        • Benefits:
        
        o Better for situations where no precise formula for deciding the manipulated variable
        
        o Can be completely embedded
        
        • Limitations:
        
        o Requires more sensors to monitor system states
- - - - • Data-centered architecture is characterized by a centralized data store that is shared by all surrounding software components
      - • Consists of two types of components:
        
        o Data store
        
        o Software component agents
      - • The connection between the data module and the software components is either implemented by explicit or implicit method invocation
      - • Software components do not communicate directly but via data store
      - • The shared data module provides
        
        o Insertion
        
        o Deletion
        
        o Update and
        
        o Retrieval
      - • Classified into two categories (based on Flow Control Strategy)
        
        o Repository
        
        o Blackboard
    - - Properties
        
        • Data store is passive
        
        • Clients of the data store are active
        
        o Its clients taking control of flow logic
        
        o Client may access the repository
        
         Interactively
        
         Batch transaction
        
        • Example: Database management system
      - Variants of Data Repository
        
        Virtual repository:
        
        • Built up on the top of multiple physical repositories
        
        • Most DB allows users to create views that are virtual repositories since they do not exist physically.
        
        • Benefits:
        
        o Simplify the overall complexity of overall database structure
        
        o Security management in terms of scope of data of manipulation for different users
        
        Distributed repository system (distributed database system):
        
        • All data are distributed over all sites linked by network
        
        • Data are replicated in order to improve reliability and local accessibility
        
        • Concerns
        
        o Vertical or horizontal partitions
        
        o Synchronization of duplicated data
        
        o Cost of data transmission
        
        o Collaboration (two-phase transaction commitment)
      - Application Domain
        
        • Suitable for large complex information system
        
        • Data transactions drive the control flow
      - Pros & Cons
        
        Benefit:
        
        • Data integrity: easy to backup and restore
        
        • System scalability and Reusability of agents: reduce the overhead of transient data between software components
        
        Cons:
        
        • Data store reliability and availability
        
        • High dependency between data structure of data store
        
        • Overhead cost of moving data on network
    - - Definition & Properties
        
        • Flow of logic is determined by the current data status
        
        o The clients of a blackboard system are called
        
         Knowledge sources
        
         Listeners or subscribers
        
        o A new data change may trigger events so that the knowledge sources take actions to respond to these events. These actions may result in new data and change in logic flow …
        
        • Data store is active
        
        • Clients are inactive/passive
        
        • Example:
        
        o Knowledge-based AI system
        
        o voice and image recognition system
        
        o Security system
        
        o Business resource management systems
      - Blackboard system & Components
        
        • Blackboard system:
        
        o A common knowledge base, the "blackboard", is iteratively updated by a diverse knowledge sources,
        
        o starting with a problem specification and ending with a solution.
        
        • Last Blackboard arch. developed in 1970’s, mainly used for
        
        o Speech recognition
        
        o Weather forecast
        
        • Consists of three partitions
        
        o Blackboard: used to store data (Hypothesis and fact)
        
        o Knowledge Source: stores domain specific knowledge
        
        o Controller: initiating the blackboard and knowledge sources
        
        • How it works: data driven – a change in the data stored in Blackboard triggers one or more knowledge source might lead to more changes
        
        • Properties:
        
        o Each knowledge source is relatively independent
        
        o They don’t need to interact with each other
        
        o Only interact and respond to the blackboard subsystem
      - Application Domain
        
        • Suitable for solving immature and complex AI problems
        
        • The problem spans multiple disciplines, each of which has complete different knowledge expertise
        
        • Optimal, partial, or approximate solution is acceptable
        
        • Exhausted searching is impossible
      - Pros & Cons
        
        Pros:
        
        • Scalability: easy to add new knowledge source
        
        • Concurrency: all knowledge sources can work in parallel
        
        • Reusability of knowledge source agents
        
        Cons:
        
        • Tight dependency between the blackboard and knowledge source
        
        • Synchronization of multiple agents is an issue
        
        • Debugging and testing of the system is a challenge.
- - - - • Services at lower level provides more specific functionality down to fundamental utility services such as:
        
        o I/O services, transaction, scheduling, security services, etc.
      - • Middle layers provide more domain dependent functions such as:
        
        o Business logic, core processing, etc
      - • Upper layers provide more abstract functionality in the form of user interfaces such as:
        
        o Command line interpreter, GUI, Shell programming
      - • Plus Point:
        
        o Any changes to a specific layer may affect only its adjacent upper layers.
        
        o So, no ripple effects of change
    - - Definition & Properties
        
        • Probably the oldest and most widely used architecture.
        
        • Purpose: encourage re-use of modules
        
        • Idea:
        
        o System decomposed into sub-routines
        
        o A “main” program calls sub-routines and accomplishes task
      - Subroutine Calls
        
        Function Call Supported by Assembly
        
        • Protect old register values by pushing to stack
        
        • Set parameters in register
        
        • Call the subroutine
        
        o Jump, Long Jump, Call instruction
        
        o Software Interrupt
        
        Function Call Supported by High Level Language
        
        • Much more convenient
        
        • Much more tricky!
        
        • Parameter passing
        
        o Pass by value
        
        o Pass by reference
      - Main/Subroutine Design
        
        Data Flow Diagram (DFD):
        
        • Two types of flow:
        
        o Transform Flow: input data get processed and results in output data (sequential)
        
        o Transaction Flow: depending on input data, take different control actions (branch)
        
        • Mapping Process:
        
        o Identify transform and transaction flows
        
        o Map each flow into a subroutine
        
        o Generally: a main process controls the overall flow
      - Pros & Cons
        
        • Benefits:
        
        o Easy to decompose the system
        
        o Can still be used in sub-system of OO Design
        
        • Limitation:
        
        o Globally shared data are vulnerable
        
        o Tight coupling may cause ripple impacts as compared to OO design
    - - Definition & Properties
        
        • A variant of main-subroutine architecture
        
        • Supports fault tolerance and system reliability
        
        • Parallel computing and accuracy of computation
        
        • In this architecture:
        
        o The slaves provide replicated services to the master
        
        o The master selects a particular result among slaves by certain selection strategies.
        
        o Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
        
        • Parallel computing and accuracy of computation
      - Applicable domain
        
        Where reliability is crucial
    - - Definition & Properties
        
        • Idea:
        
        o functionality grouped into layers
        
        o upper layer invokes func. in lower layer
        
        • Physical implementation:
        
        o Functions in one layer usually organized in one package
        
        o Some times deployed as services
      - Applicable Design Domains
        
        • For systems that can be divided between portions providing generic services to the application of the system
        
        • For applications which have classes that are close related each other
      - Pros & Cons
        
        • Benefits:
        
        o Incremental software development
        
        o Enhanced independence of upper layer to lower layer
        
        o Enhanced reusability and interchangeability
        
        o Component-based technology is a suitable
        
        o Promotion of portability
        
        • Limitations:
        
        o Lower runtime performance
        
        o Many applications can not fit this architecture
        
        o Exception and error handling
    - - Definition & Properties
        
        • Variation of Layered Approach
        
        • Idea: Provide a virtual interpretation layer that separates application & physical machine layer. i.e., Software/Components run on simulation layer
      - Applicable Design Domain
        
        • Suitable for solving a problem by simulation or translation
        
        • Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language
      - Pros & Cons
        
        • Benefits:
        
        o Portability and machine platform independency
        
        o Simplicity of the software development
        
        o Simulation for non-native and disaster working model
        
        • Limitations:
        
        o Slow execution of the interpreter
        
        o Additional overhead due to the new layer
- - - - • Also called publisher-subscriber or producer-consumer patterns , where
        
        o Subscribers are interested in some events or messages issued by a publisher
        
        o Consumers are interested in some events or messages issued by a producer
      - • Two different modes:
        
        o Non-buffered
        
        o Buffered
    - - Properties
        
        • The non-buffered event-based implicit invocation architecture breaks the software system into two partitions:
        
        o event sources
        
        o event listeners
        
        • The event registration process connects these two partitions.
        
        • There is no buffer available between these two parties.
      - Observer pattern
        
        • The Observer pattern is another name used for this type of architecture.
        
        • Subscribers is an event listener and register themselves with the event source
        
        • Once an event is fired off by an event source, all corresponding subscribers are notified, which then take corresponding actions.
      - Applicable Domains
        
        • Suitable for interactive GUI component communication and IDE tools.
        
        • Suitable for applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications.
        
        • Suitable for the implementation of state machines.
        
        • Suitable when event handlings in the application are not predictable.
      - Pros & Cons
        
        • Benefits:
        
        o Framework availability: Many vendor APIs such as Java AWT and Swing components available.
        
        o Reusability of components: Easy to plug-in new event handlers without affecting the rest of the system.
        
        o System maintenance and evolution: Easy to update both of event sources and targets.
        
        o Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at run-time.
        
        o Possibility of parallel execution of event handlings.
        
        • Limitations:
        
        o Difficult to test and debug the system: hard to predict and verify responses and the order of responses from the listeners.
        
        o The event source cannot be determined: when a response finished or the sequence of all responses.
        
        o Reliability and overhead of indirect invocations may be an issue.
        
        o There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
    - - Properties
        
        • The buffered message-based software architecture breaks the software system into three partitions:
        
        o Message producers
        
        o Message consumers
        
        o Message service providers
        
        • They are connected asynchronously by either a
        
        o message queue : one-to-one
        
        o message topic: one-to-many
        
        • This architecture is also considered data-centric
      - Message-based systems
        
        Message:
        
        • A message is a structured data with a message id, message header, property, and a body.
        
        • A typical example of a message is an XML document.
        
        • Messaging is a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.
        
        Messaging mechanism:
        
        • A messaging client can produce and send messages to other clients, they can also consume messages from other clients.
        
        • Each client must register with a messaging destination in a connection session provided by a message service provider for creating, sending, receiving, reading, validating, and processing messages.
        
        Messaging system properties:
        
        • In a message-based system, also referred to as Fire & Forget system, a sender sends out a message and it does not care much of the response from the receivers except for guaranteed message delivery; it is typically implemented as a Message-Oriented Middleware (MOM) providing a reliable message service on a distributed system.
        
        • Messaging systems are used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication.
        
        • The messaging system architecture is just a peer-to-peer client-server architecture.
        
        • The high degree of independency between components within the messaging system is one of its most important features.
        
        • Its high scalability, interoperability in heterogeneous networks, and reliability also make the messaging system more popular.
      - Point-to-Point Messaging (P2P) Mechanism
        
        • The message queue architecture is a point-to-point structure between producer and consumer.
        
        • A P2P messaging architecture is composed of message queues, senders, and receivers.
        
        • Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queues.
        
        • The queue retains all messages they receive either until the messages are consumed or until the messages expire.
        
        • Each message has only one consumer, i.e., the message will be “gone” once it is delivered.
        
        • This approach allows multiple message receivers but one and only one of them will get the message as determined by the message service provider.
        
        • A sender and a receiver of a message have no timing dependencies, that is, the receiver can still get the message even it was not available when the sender sent the message
        
        • P2P messaging requires every message sent to the message queue must be processed successfully by a consumer.
        
        • It is much more reliable than simple event-listener based system we discussed earlier.
      - Publish-Subscribe Messaging (P&S) Mechanism
        
        • The P&S messaging architecture is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board.
        
        • Message topic publishers and subscribers are not aware of each other.
        
        • One difference between P&S from P2P is that each topic message can have multiple consumers.
        
        • The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system.
        
        • Publishers and subscribers have a timing coupling dependency. • A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription, which is able to receive any topic messages sent while the subscribers are not active or not ready yet.
      - Applicable Domains
        
        • Suitable for a software system where the communication between a producer and a receiver needs buffered message-based asynchronous implicit invocation for performance and distribution purposes.
        
        • The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced.
        
        • The provider wants the application to run whether or not all other components are up and running simultaneously.
        
        • The application business model allows a component to send information to another and to continue to operate on its own without waiting for an immediate response.
      - Pros & Cons
        
        • Benefits:
        
        o Providing high degree of anonymity between message producer and consumer.
        
        o The message consumer does not know who produced the message (user independence), where the producer lives on the network (location independence), or when the message was produced (time independence).
        
        o Supporting for concurrency among consumers and between producer and consumers.
        
        o Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
        
        o Supporting batch processing.
        
        o Providing scalability and reliability of message delivery; reliability mechanisms include
        
         Control level setting of message acknowledgement
        
         Message persistence setting without loss Message priority level setting
        
         Message expiration setting
        
        • Limitations:
        
        o Capacity limit of message queue. This is not an inherent limitation but an implementation issue that can be eased if the queue is implemented as a dynamic data structure (e.g., linked lists).
        
        o Increased complexity of the system design and implementation
        
        o Complete separation of presentation and abstraction by control in each agent generate development complexity since communications between agents only take place between the control of agents.
        
        o However, there is an absolute limit based on available memory. It is also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents.
        
        o In an event-based invocation system the event handler must be ready in order to be able to intercept an event and take an action upon that event.
        
        o A message receiver can still receive messages even if it is not running at the time the message was sent.
        
        o This architectural style is commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture
- - - - Definition & Properties
        
        • Separation of user interactions from data abstraction and business logic
        
        o Many view presentation in different data formats
        
        o Multiple views is supported for the same data set.
        
        o Even for a specific view presentation, the view or interface may need to change so often, so the loose coupling between data abstraction and its presentation is helpful. This is supported in this style.
        
        • Interaction oriented SW architecture decomposes the system into
        
        o Data module
        
        o Control module
        
        o View presentation module
        
        • Key ideas:
        
        o Decompose user-interaction software
        
         Data module
        
         Flow control module
        
         View presentation module
        
        o Benefits:
        
        Loose coupling for exchangeability
        
        Maintainability & extensibility
      - Modules
        
        • Data module
        
        o Provides data abstraction
        
        o All core business logic on data processing
        
        • Control module
        
        o Flow of control of view presentation
        
        o Communication between modules
        
        o Job dispatching
        
        o Certain data initialization
        
        o System configuration
        
        • View presentation module
        
        o Visual or audio data output presentation
        
        o Provide user interface when necessary
      - Categories
        
        • Model View Controller (MVC)
        
        • Presentation Abstraction Control (PAC)
    - - Properties
        
        • Widely used in web applications
        
        o E.g., MS ASP.Net, Java Swing
        
        o First introduced in 1980’s SmallTalk
        
        • Key Idea
        
        o Model: model of application’s logic
        
        o View: deal with graphic representation
        
        o Controller: contains the interface between model and view
        
        • Note:
        
        model does not (and should not) know view and controller. It should not depend on the other two components.
      - Model, View, Controller
        
        • Concept for Model:
        
        o The Model manages the behavior and data of the application domain.
        
        o The model responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)
        
        • Concept for View:
        
        o The View renders the model into a form suitable for interaction, typically a user interface element.
        
        o Multiple views can exist for a single model for different purposes.
        
        o A view port typically has a one to one correspondence with a display surface and knows how to render to it.
        
        • Concept for Controller:
        
        o The Controller receives user input and initiates a response by making calls on model objects
        
        o A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
      - 9.2.1.MVC-I
        
        • Simplified System
        
        o Controller/View: Takes care of input/output, interface to model
        
        o Model: In charge of business logic
      - 9.2.2.MVC-II
        
        • Completely separated Controller & View
      - Applicable domain
        
        • Suitable for where multiple views needed for a single data model and the graphics interfaces prone to data changes.
        
        • There are clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications.
      - Pros & Cons
        
        • Benefits:
        
        o Easy to plug in new or change interface views,
        
        o Very effective for developments (team working by different professionals)
        
        • Limitations:
        
        o Does not fit agent-oriented application such as robotics applications
        
        o Multiple pairs of controllers and views make data model change expensive
        
        o The division between the View and the Controller is not very clear in some cases
    - - Properties
        
        • PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements.
        
        • Key ideas:
        
        o PAC: hierarchy structure for interacting or cooperating agents
        
        o Each agent responsible for one function
        
        o Sometimes all agents share the same control: provides interaction between agents
        
        o Within each agent there are no direct connections between the abstraction component and presentation component
        
        o Each agent has three components
        
        Presentation
        
        Abstraction
        
        Control
        
        • Usage:
        
        o PAC is suitable for distributed systems where all agents are distantly distributed and each agent has its own functionalities with data and interactive interfaces.
        
        o Sometimes, middle level agents, the interactive presentations are not required.
      - Applicable domain
        
        • Suitable for where there are many cooperating agents in a hierarchical structure.
        
        • The coupling among the agents is expected very loose
      - Pros & Cons
        
        • Benefits:
        
        o Supporting multi-tasking, multi-viewing
        
        o Supporting agent reusability and extensibility
        
        o Easy to plug in new agent or replace an existing agent
        
        o Supporting concurrency
        
        • Limitations:
        
        o Overhead due to the control bridge
        
        o Difficult to design agents
      - Difference of MVC and PAC
        
        • They differ in their flow of control and organization
        
        • PAC is an agent based hierarchical architecture, whereas MVC does not have any clear hierarchical architecture.
        
        All three modules are connected together.
- - - - • Heterogeneous architecture styles are used to combine benefits of multiple styles and to ensure quality and appropriateness.
      - • Many ways to have heterogeneous architecture:
        
        o Hierarchical:
        
        Components composed using on architectures
        
        Each component internally using a different one
        
        o Mixture of Architectures
        
        E.g., filter of a pipe & filter arch. accesses central DB
    - - Similarly, the responsibility of a good
        software architect is not to work out one feasible solution, but to determine which architecture best suits the business needs
      - A number of architecture styles have been covered, including the data flowarchitectures, data centric architectures, hierarchical, implicit asynchronous communication, interaction-oriented, distributed, andcomponent-based architectures
      - Architecture Style Heavily Depends on Requirement Analysis
    - - • Used to make architectural decision
      - • Common Quality Attributes:
        
        o Efficiency (time and space)
        
        o Functionality (completeness, interoperability)
        
        o Portability (hardware independence, installability)
        
        o Reliability (error tolerance, availability)
        
        o Usability (user interface, learnability)
      - Architectural Decision Procedure
        
        Determine the required quality attributes in requirement analysis
        
        Quantify the quality attributes
        
        • Many can be directly quantified. E.g., time efficiency by throughput, latency, etc.
        
        • Many should be assigned qualitative values first, then quantified. E.g., “Excellent”: 100, “Average”: 50
        
        Compute the weighted sum
    - - Evaluating Architecture Style
        
        • Largely depends on designers’ expertise
        
        • However, tools available
        
        o Engineering handbook
        
        o Qualitative Evaluation of Architecture Styles
    - - Many approaches available
        
        ATAM (Architecture Trade-off Analysis Method)
        
        SAAM (Software Architecture Analysis Method)
        
        ARID (Active Reviews for Intermediate Designs)
      - SAAM (Software Architecture Analysis Method )
        
        Idea: Evaluate design against Scenarios
        
        Scenario
        
        Similar but different from use case
        
        Can contain situations not included in the scope of the project
        
        Example:
        
        Given an online registration system
        
        Sample scenario: what if the internal registration form is changed?
        
        It tests the “modifiability” of the system
        
        The SAAM analysis process generally consists of three stages
        
        Define a collection of design scenarios that cover the functional and nonfunctional requirements. Quality attributes should be
        reflected
        
        Perform an evaluation on all candidate architecture designs, using the collection of scenarios.
        
        Perform an analysis on the interaction relationship among scenarios.
    - - Business Ideology:
      - Consumer order online
      - Benefits:Low inventory cost & maximize efficiency
      - Requirement 1
        
        Web portal provided to customers
        
        Order can be highly customized
        
        Allows configuration of products step by step
        
        Customer can
        
        check out shopping cart
        
        or save the shopping cart for later use
        
        Credit card the only acceptable payment method.
        
        The web portal should be able to serve 10000 customers simultaneously.
      - Requirement 2
        
        A subsystem be provided to product designers.
        
        When product released, the designer can input the basic configuration of the product
        
        When the specification of the new product is done, the corresponding web pages should be automatically generated
        
        Inventory DB and the subsystem for assembly lines should also incorporate the information immediately
      - Requirement 3
        
        A subsystem should be developed to assist assembly lines.
        
        Each worker on an assembly line is equipped with a computer system which shows the job details that the worker has to perform.
      - Requirement 4
        
        An automatic inventory management system should be developed to trace the inventory.
        
        An automatic scheduler reports the estimated number of parts required every day.
        
        The reports, if approved by business mangers, are converted to parts orders to suppliers.
      - Requirement 5
        
        The whole OCVS system should bridge information among all departments to maximize the efficiency of the organization.
        
        The involved departments include
        
        order processing department
        
        manufacture and shipping department
        
        product design engineers
        
        business strategy makers
      - Requirement 6
        
        Expandable
        
        new products can be easily added
        
        can expand to serve more customers.
        
        cost of system increases linearly
        
        Modifiable
        
        Allows modification of internal representation of products and configuration process over the time.
        
        The business rules (e.g., parts usage prediction), web pages of products, and configuration process will go through frequent changes.
        
        availability and reliability
        
        time efficiency,
- - - - Definition & Properties
        
        • Component-based Architecture is used to
        
        o Divide a problem into sub-problems
        
        o Each sub-problem is associated with a component
        
        o Interface plays an important role
        
        • Motivation
        
        o Components are highly reusable
        
        o A component encapsulates the functionality and behaviors of a software element into a reusable and self-deployable binary.
        
        o Use of COTS or developed in-house components
        
        o Increases overall reliability
        
        o Can greatly reduce development cost
      - Component-based Architecture vs Object Oriented Architecture
        
        • A component-oriented represents a higher level of abstraction than an equivalent OO design. The component-oriented design defines components and connections between them instead of classes and connections between classes
        
        • Advantages:
        
        o Reduced time in market
        
        o Lower development costs by reuse of the existing components
        
        o Increased reliability with reuse of the existing components
    - - Definition & Properties
        
        • A component is a modular (cohesive), deployable (portable), replaceable (plug-and-play), and reusable set of well-defined functionalities that encapsulates its implementation and exports it as a higher-level interface.
        
        • A component is a deployable software package that can provide services to its client
        
        • It may require services from other components
        
        • It remains self-contained and substitutable as long as it interface is unchanged.
        
        • Examples: COM/DCOM, JavaBean, .Net, Web Services, Grid Services
        
        • A UML component can be mapped to any target technology component
      - Why use components?
        
        • Reusability
        
        • Productivity
        
        • Composability
        
        • Adaptability
        
        • Scalability
        
        • Reliability and many others
      - Implementation
        
        • Usually consists of a set of class files
        
        o Abstract Interface
        
        o Concrete Implementation Classes
        
        • Note:
        
        o Some IDE tools support visualization of components, e.g., VS Studio .Net Toolset
        
        o However, it does not mean that each component should have such a visual representation
        
        • Separation of Interface and Implementation allows changeability
    - - 11.3.1 Principles of Component-Based Architecture
        
        • Figure out semantics of connections
        
        o Communication semantics important
        
        o Local: relatively easy
        
        o Remote: many different call semantics
        
        • Think about INTERFACE, not the implementation
      - 11.3.2 Component Level Design
        
        • Before the design phase, we have:
        
        o Use case modeling
        
        o Business concept modeling
        
        • Use case diagrams:
        
        o Describes user interactions with the system which indicate all necessary operations of the component
        
        o We can map use case diagram to the provided service interfaces of the first-cut component specification
        
        • Collaboration diagram:
        
        o Is an identifiable slice of functionality that describes a meaningful service involving several concepts.
        
        o A collaboration diagram is used for the implementation of a use case
        
        o For each use case U, there will be a collaboration diagram “encapsulated” in a component C.
        
        • Business concept diagram:
        
        o Depicts the relationships of the business process entities in the domain
        
        o Extract business process entities that can exist independently without any associated dependency on other entities.
        
        o Recognize and discover these independent entities as new components.
    - - • Suitable for where the interface contracts between sub-systems are clear.
      - • Suitable for loose coupling between the components and many reusable components are available
      - • Suitable for the class library system organization. .NET class library and Java API themselves are built in component architecture
    - - • Benefits:
        
        o Reusability of components:
        
        o System maintenance and evolution:
        
        o Productivity
        
        o Many OO design tools available
        
        o Independency and flexible connectivity of components
      - • Limitations:
        
        o Sometime it is difficult to find suitable components to reuse.
        
        o Adaptation of components is always an issue.
- - - - Definition & Properties
        
        • Distributed System is a collection of computational and storage devices connected through a communications network. Components are distributed
        
        • Many models available, each has pros and cons
        
        • Two important issues:
        
        o Topology: the way components connected
        
        o Mode: the method they communicate with each other
      - Architectures
        
        • Client/Server
        
        • Multi-tier
        
        • Broker
        
        • Service Oriented
    - - Definition & Properties
        
        • Has two communicating processes, running on different processors. Decomposed into two major subsystems:
        
        o Client
        
        o Server
        
        • The most commonly distributed system architecture
        
        • Server process receives the request, carries it out, and sends a reply to the client
      - Pros & Cons
        
        • Advantages:
        
        o Responsibility separation such as user interface presentation and business logic processing
        
        o Reusability of server components
        
        • Disadvantages:
        
        o Lack of heterogeneous infrastructure to deal with the requirement changes
        
        o Security complications
        
        o Server availability and reliability
        
        o Testability and scalability
    - - Structure
        
        At least 3 tiers
        
        • Front-end tier - User interface presentation tier
        
        • Middle-end tier - Business logic tier: Manages business logic and execution
        
        • Back-end tier - DB management tier: Handles database
      - Pros & Cons
        
        • Advantages:
        
        o Enhanced reusability and scalability by adding the middle tier
        
        o Middle layer is easy to change
        
        o Have portable and nonproprietary design and implementation
        
        o Middle layer can provide multi-threading support
        
        o Reduces traffic on the network
        
        • Cons:
        
        o Difficulty in testing due to lack of testing tools
        
        o Adding multiple servers in the system makes the server reliability and availability even more critical
    - - Properties
        
        • Transparently distribute aspects of the software system to different nodes
        
        o An object can call methods of another object without knowing that this object is remotely located.
        
        o CORBA is a well-known open standard that allows you to build this kind of architecture.
        
        • Key Idea:
        
        o Service provider register services through broker
        
        o Clients discover services through broker
        
        o Clients submit requests to broker
        
        o Broker massages requests from clients and relay results from service provider
      - Components
        
        • Broker
        
        o Provide service registration
        
        o It coordinates communications, passing on request and returning replies
        
        o It stores all servers’ registration information, their functionalities and location information
        
        o It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.
        
        • Stub (client-side proxy):
        
        o Provide “stub” version of remote services, responsible for massaging messages
        
        o Mediates between the client and the broker and providing additional transparency between them.
        
        o To the client, a remote object appears like a local one.
        
        o The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server.
        
        o The stud is generated at compilation time and deployed at client side to be used as a proxy for client
        
        • Bridges (optional):
        
        o For interaction with brokers
        
        o Hide implementation details when two brokers interoperates
        
        o Can translate requests and parameters from one format to another
        
        • Network:
        
        o For interaction with brokers
        
        o Connects components using designated protocol standards such as TCP/IP, OIIP, SOAP
        
        o The request carries data in a message document or method invocation format.
      - Pros & Cons
        
        • Advantages
        
        o Server component implementation and location transparency,
        
        o Changeability and extensibility,
        
        o Feasibility of run time changes of server components (add or remove server components)
        
        • Disadvantages:
        
        o Inefficiency due to the overhead of proxies
        
        o Low fault tolerance
        
        o Difficulty testing
    - - Properties
        
        • A Service Oriented Architecture (SOA) starts with a businesses process.
        
        • In this context, a service is a business functionality that is well-defined, self-contained, independent from other services, and published and available to be used via a standard programming interface.
        
        • Software manages business processes through a SOA with well-defined and standard interfaces that can build, enhance, and expand their existing infrastructure more flexible.
        
        • SOA services can be extensively reused within a given domain or product line, and even among legacy systems.
        
        • Loose coupling of service–orientation provide great flexibility for enterprises to make use of all available service recourses regardless of platform and technology restrictions.
        
        • The connections between services are conducted by common and universal message oriented protocols such as the SOAP Web service protocol, which can deliver requests and responses between services loosely.
        
        • A connection can be established statically or dynamically.
      - Pros & Cons
        
        • Advantages:
        
        o Loosely-coupled connection: Loose-coupling is the key attribute of SOA.
        
        o Each service component is independent from other services due to the stateless service feature
        
        o The implementation of a service will not affect the application of the service as long as the exposed interface is not changed.
        
        o It makes SOA software much easier to evolve and update.
        
        o Interoperability: Technically any client or any service can access other services regardless of their platform, technology, vendors, or language implementations.
        
        o Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier.
        
        o SOA based business application development comes much more efficient in term of time and cost.
        
        o Scalability: Loosely coupled services make themselves easy to scale.
        
        o The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute.