Please enable JavaScript.

Coggle requires JavaScript to display documents.

Nhóm 3_ 3 - Coggle Diagram

- - - - • Figure out semantics of connections
        
        o Local: relatively easy
        
        o Communication semantics important
        
        o Remote: many different call semantics
      - • Think about INTERFACE, not the implementation
    - - • 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.
      - • Before the design phase, we have:
        
        o Use case modeling
        
        o Business concept modeling
  - - - • Productivity
      - • Composability
      - • Reusability
      - • Adaptability
      - • Scalability
      - • Reliability and many others
    - - • 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
      - • Usually consists of a set of class files
        
        o Abstract Interface
        
        o Concrete Implementation Classes
    - - • It may require services from other components
      - • It remains self-contained and substitutable as long as it interface is unchanged.
      - • A component is a deployable software package that can provide services to its client
      - • Examples: COM/DCOM, JavaBean, .Net, Web Services, Grid Services
      - • 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 UML component can be mapped to any target technology component
  - - - o Reusability of components
      - o Independency and flexible connectivity of components
      - o Productivity
      - o Many OO design tools available
      - o System maintenance and evolution
    - - o Sometime it is difficult to find suitable components to reuse.
      - o Adaptation of components is always an issue.
  - - - • Component-based Architecture is used to
        
        o Each sub-problem is associated with a component
        
        o Interface plays an important role
        
        o Divide a problem into sub-problems
      - • Motivation
        
        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 Components are highly reusable
        
        o Increases overall reliability
        
        o Can greatly reduce development cost
    - - • 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
- - - - The most commonly distributed system architecture
      - It has two communicating processes
        
        So, it is decomposed into two major subsystems:
        
        Server
        
        Client
        
        Server process receives the request, carries it out, and sends a reply to the client
        
        Running on different processors
      - Two tier: client and server
        
        Front-end tier focuses on the user interaction
        
        Back-end tier focuses on business logic and database management
      - pros/cons
        
        Advantages:
        
        Responsibility separation such as user interface presentation and business logic processing
        
        Reusability of server components
        
        Disadvantages:
        
        Security complications
        
        Server availability and reliability
        
        Lack of heterogeneous infrastructure to deal with the requirement changes
        
        Testability and scalability
  - - - Middle-end tier - Business logic tier
        
        Manages business logic and execution
      - Back-end tier - DB management tier
        
        Handles database
      - Front-end tier - User interface presentation tier
    - - Advantages of multi-tier over two-tier architecture.
        
        Enhanced reusability and scalability by adding the middle tier
        
        Have portable and nonproprietary design and implementation
        
        Middle layer can provide multi-threading support
        
        Middle layer is easy to change
        
        Reduces traffic on the network
      - Cons
        
        Difficulty in testing due to lack of testing tools
        
        Adding multiple servers in the system makes the server reliability and availability even more critical
  - - - Encapsulates low-level system specific networking functions like client proxy and provides high level APIs to mediate between the server and the broker
      - It receives and unpacks the requests, unmarshals the arguments, and calls the appropriate service.
      - It is also generated by service interface compilation and deployed at server side
      - When receives the result back from the server, it also marshals results before sending it back to the client
    - - Hide implementation details when two brokers interoperates
      - Can translate requests and parameters from one format to another
      - Optional component
    - - To the client, a remote object appears like a local one.
      - The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server.
      - Mediates between the client and the broker and providing additional transparency between them.
      - The stud is generated at compilation time and deployed at client side to be used as a proxy for client
    - - Connects components using designated protocol standards such as
        
        OIIP
        
        SOAP
        
        TCP/IP
      - The request carries data in a message document or method invocation format.
    - - It stores all servers’
        
        registration information, their functionalities and location information
      - It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.
      - It coordinates communications, passing on request and returning replies
  - - - Each service component is independent from other services due to the stateless service feature.
      - The implementation of a service will not affect the application of the service as long as the exposed interface is not changed.
      - Loosely-coupled connection: Loose-coupling is the key attribute of SOA.
      - It makes SOA software much easier to evolve and update.
    - - 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.
      - SOA services can be extensively reused within a given domain or product line, and even among legacy systems.
      - A connection can be established statically or dynamically.
- - - - Definition & Properties
        
        • More and more SW involve user input/output interaction, so specific user interfaces to software design.
        
        • Interaction oriented SW architecture decomposes the system into
        
        o Data module
        
        o Control module
        
        o View presentation module
        
        • 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.
        
        • 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 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.
        
        • Concept for View:
        
        o Multiple views can exist for a single model for different purposes.
        
        o The View renders the model into a form suitable for interaction, typically a user interface element.
        
        • 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)
      - MVC-I
        
        • Simplified System
        
        o Controller/View: Takes care of input/output, interface to model
        
        o Model: In charge of business logic
      - 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 has three components
        
         Presentation
        
         Abstraction
        
         Control
        
        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
        
        • 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
    - - Architectural Decision Procedure
        
        (2) 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
        
        (3) Compute the weighted sum
        
        (1) Determine the required quality attributes in requirement analysis
      - Evaluating Architecture Style
        
        • Largely depends on designers’ expertise
        
        • However, tools available
        
        o Engineering handbook
        
        o Qualitative Evaluation of Architecture Styles
      - Quality Attributes
        
        • Common Quality Attributes
        
        o Portability (hardware independence, installability)
        
        o Reliability (error tolerance, availability)
        
        o Functionality (completeness, interoperability)
        
        o Usability (user interface, learnability)
        
        o Efficiency (time and space)
        
        • Used to make architectural decision