软件体系结构

《软件体系结构》课程复习笔记。

1_Overview

  • Architecture is a set of principal design decisions about a software system
  • [Software architecture’s] two elements:
    • One is the highest-level breakdown of a system into its parts;
    • the other, decisions that are hard to change.
  • accidental difficulties: can be eliminated
  • essential difficulties: can be lessened, but not eliminated
    • complexity: buy v.s. build, Incremental/Evolutionary/Spiral Development, Great designers
    • conformity (software needs to conform to its OS & hardware), changeability, intangibility
  • advantages of using architecture:
    • Intellectual control
    • Conceptual integrity
    • Effective basis for knowledge reuse
    • Realizing experience, designs, and code
    • Effective project communication
    • Management of a set of variant systems
  • Software Architecture Quality Metrics: Availability, Reliability, Modifiability, Performance, Security, Testability, Usability, Supportability
    • Vertical scalability comes from adding capacity (memory, CPUs) to existing servers. Horizontal scalability comes from adding servers.
    • Security:

image
image

  • Scalable, available architectures are typically service-based architectures with collections of cooperating, communicating services.
  • To achieve capabilities, an architect creates an architecture with the following goals in mind.
    • Modularity: Separate the code into self-sufficient, highly cohesive, low-coupling pieces.
    • Protection and exposure: Guard expensive resources to prevent inappropriate use. Shared resources are usually expensive to access. Protection mandates controlled exposure using visibility access classes.
    • Component extensibility: Modify or add functionality without impacting the existing functionality. Subclass & Composition
    • Roles and responsibilities
    • Contracts: the client-visible API.
      • Contract-based – Action and data are explicitly defined in the contract.
      • Message-based – Action and data are packaged in the request. The contents of the message are parsed to identify the requested function.
    • Pluggable behavior

2_Architectures_In_Context

  • Requirements -> Design -> Implementation -> Analysis and Testing -> Evolution -> Development Process
  • design strategies:
    • Object-oriented design
      • Pros: UML modeling notation; Design patterns
      • Cons:
        • Provides only One level of encapsulation (the object); One notion of interface; One type of explicit connector (procedure call); Even message passing is realized via procedure calls.
        • OO programming language might dictate important design decisions
        • OOD assumes a shared address space
    • Domain-specific software architectures (DSSA)
      • Capturing and characterizing the best solutions and best practices from past projects within a domain.
  • Implementation Strategies: Generative techniques, Frameworks, Middleware, Reuse-based techniques
    , Writing all code manually

image

  • Lifecycle Models:
    • The V-model which is a development of waterfall and explicitly includes architectural design as a stage.
    • Iterative models focus on project risk management. Here architecture that gives us vision of how development tasks are interrrelated will play a key role as well as ensuring quality requirements are met.迭代模型
    • Agile – here some decisions are more stable than others and the more stable ones concern architectures.敏捷开发

3_Basic_Concepts

  • The blueprint – focussing on Structure, Component Behaviour, Component Interaction and how that influences Quality Attributes of Systems
  • Use good modular structure: hide information, separate concerns, good robust interfaces that are unlikely to change.
  • Structure depends on perspective/viewpoint: at least static (captures e.g. dependency in code), dynamic (captures e.g. dependency in data flow), deployment (captures e.g. dependency on resources)
  • prescriptive architecture: how the system should be; descriptive architecture: how the system has been built.
  • Architectural drift is introduction of principal design decisions into a system’s descriptive architecture do not violate any of the prescriptive architecture’s design decisions.
  • Architectural erosion is the introduction of architectural design decisions into a system’s descriptive architecture that violate its prescriptive architecture.
  • Architectural recovery is the process of determining a software system’s architecture from its implementation-level artifacts(Source code, Executable files, Java .class files)
  • A software component is an architectural entity that encapsulates a subset of the system’s functionality and/or data, restricts access to that subset via an explicitly defined interface, has explicitly defined dependencies on its required execution context. Components typically provide application-specific services.
  • A software connector is an architectural building block tasked with effecting and regulating interactions among components. In many software systems connectors are usually simple procedure calls or shared data accesses. Connectors typically provide application-independent interaction facilities
  • An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software system’s architecture.
  • An architectural style is a named collection of architectural design decisions that are applicable in a given development context, constrain architectural design decisions that are specific to a particular system within that context, elicit beneficial qualities in each resulting system.
    • REST style (Representational State Transfer) – HTTP
      • Uniform Interface between clients and servers
      • Stateless: No client context stored on server between requests. All state is carried in the request URL.
      • Clients should be able to cache responses to requests
      • Layered architecture: Clients cannot tell if they are connected directly to the server or thro’ a proxy
      • Code on demand (optional): Server should be able to extend the client’s functionality thro’ client-side scripts
  • An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.
  • style v.s. pattern
    • Style: Provides a set of guiding principles in adopting solutions. Requires considerable effort to apply. Architect needs to justify the design choices based on the architectural style.
    • Pattern: Provides concrete solutions, although parameterized to the specific problem. Requires very little manual effort or justification to apply. Usually applies to specific systems (e.g., GUI-based systems)

4_Architectural views

  • The logical view is the object model of the design (when an object-oriented design method is used), The process view captures the concurrency and synchronization aspects of the design,The physical view describes the mapping(s) of the software onto the hardware and reflects its distributed aspect, The development view describes the static organization of the software in its development environment. The description of an architecture—the decisions made—can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view.

  • The logical architecture primarily supports the functional requirements. They exploit the principles of abstraction, encapsulation, and inheritance. We can use the UML approach for representing the logical architecture, by means of class diagrams and class templates. an application that is very data-driven may use some other form of logical view, such as E-R diagrams.(实体、属性和联系)
    • The main artifact of the logical view is the design model;
    • The design model gives a concrete description of the functional behavior of the system. It is derived from the analysis model.
      • The design model consists of collaborating classes, organized into subsystems or packages.
      • Artifacts involved in the design model may include:
        • class, interaction, and state diagrams
        • the subsystems and their interfaces described using package diagrams
    • The analysis model gives an abstract description of the system behavior based on the use case model.




UML图



E-R图

  • The process architecture takes into account some non-functional requirements, such as performance and availability. A process is a grouping of tasks that form an executable unit.
    • Major tasks communicate via a set of well-defined inter-task communication mechanisms; Minor tasks may communicate by rendezvous or shared memory.

  • The development architecture focuses on the actual software module organization on the software development environment. The development architecture of the system is represented by module and subsystem diagrams, showing the ‘export’ and ‘import’ relationships.

  • The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability.
  • The Deployment View:actual deployment

  • scenarios serve two main purposes:(+1 view)
    • as a driver to discover the architectural elements during the architecture design as we will describe later
    • as a validation and illustration role after this architecture design is complete, both on paper and as the starting point for the tests of an architectural prototype.

  • From the logical to the process view: a mapping of classes (and their objects) onto a set of tasks and processes of the process architecture.
  • From the logical to the development view: does not have a one to one correspondence with the logical view.(additional constraints must be considered)
  • From process to physical: Processes and process groups are mapped onto the available physical hardware, in various configurations for testing or deployment.
  • The scenarios relate mostly to the logical view, in terms of which classes are used, and to the process view when the interactions between objects involve more than one thread of control.

  • Use Case View (or scenarios)
  • Use case model: illustrates the system’s intended functions (use cases), its surroundings (actors), and relationships between the use cases and actors (use case diagrams).
    • use case relationships:
      • Association: a relationship that represents communication between an actor and a use case; can be navigable in both ways or in only one way.
      • Inheritance: Generalization or specialization relationships that may exist between actors.
      • Between use cases: uses and extends
        • A functionality shared by multiple use cases can be placed in a separate use case which is related to these uses cases by a uses relationship.
        • An extends relationship is used to show: Optional behavior, Behavior that is only run under certain conditions such as triggering an alarm; Different flows which may be run based on actor selection

textual description of use case:

Flow of Events for Check PIN Use Case

Main flow of events: The use case starts when the system prompts the User for a PIN number. The User can now enter a PIN number via the keypad (E1). The User commits the entry by pressing the Enter button (E2). The system then checks this PIN number to see if it is valid (S1, E3). If the PIN number is valid, the system acknowledges the entry, thus ending the use case.

Subflows:
S1: The system invokes Validate use case.

Alternative flow of events:
E1: The User can clear a PIN number any time before committing it and reenter a new PIN number.
E2: The User can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the User’s account.
E3: If the User enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancels the entire transaction, preventing the User from interacting with the ATM for 30 minutes.

  • class diagram: Provide a picture or view of some or all the classes/interfaces in the model.

    • Entity classes:
      • model information and associated behavior that is generally long lived
      • may reflect a real-world entity, or may be needed to perform tasks internal to the system
      • are application independent: may be used in more than one application.
    • Boundary classes:
      • handle the communication between the system surroundings and the inside of the system
      • can provide the interface to a user or another system
    • Control classes:
      • model sequencing behavior specific to one or more use cases.
      • typically are application-dependent classes.
  • object diagram: Shows a set of objects and their relationships at a point in time; shows instances and links

  • Package Diagrams: Package: Independent unit of functionality that consists of a collection of related classes and/or other subsystems. Offer interfaces and uses interfaces provided by other subsystems.

  • communication

    • there are three kinds of synchronization: Sequential, Guarded, Concurrent
  • Interface (in component), node (deployment). Nodes are locations upon which components are deployed.
  • component&connector
    • Conceptual: components are set of responsibilities and connectors are flow of information
    • Execution: components are execution units (processes) and connectors are messages between processes
    • Implementation: components are libraries, source code, files, etc and connectors are protocols, api calls, etc.

5_ia_ea_ca

  • Conceptual Architecture: Focuses on domain-level responsibilities

  • Execution Architecture: Focuses on the system runtime structure
    • Synchronous communication: the calling components waits for a response of the called component
    • Asynchronous communication: the calling component does not wait for a response
    • Callback: The calling component receives a response asynchronously by setting a means by which the called component can send response later


  • Implementation Architecture: Focuses on how the system is built
    • Application components & Infrastructure components (container component)
      • Application components: are responsible for implementing domain-level responsibilities
      • Infrastructure components: are needed to make the system run but are not related to the application functionality
    • connectors represent a “uses” relation: API call, callback, network protocol, OS signals


Element Conceptual Implementation Execution
Components Domain-level responsibilities Implementation module Unit of concurrent activity
Connectors Information flow “Uses” relationship Invocation
Views single split Multiple
  • Conceptual: components are set of responsibilities and connectors are flow of information
  • Execution: components are execution units (processes) and connectors are messages between processes
  • Implementation: components are libraries, source code, files, etc and connectors are protocols, api calls, etc.

Conceptual vs. Execution vs. Implementation:


6_Patterns & Styles

  • MVC: Model-View-Controller
  • SCC: Sense(sensor)-Compute-Control
  • Data-flow styles
    • Pipe and filter: steps might run concurrently processing parts of data incrementally, very flexible, easy to add and remove components (helps evolvability)
      • Components are filters, Connectors are pipes
      • Data flows in streams: good for processing of images, audio, video, …
    • Batch sequential: each step runs to completion before the next step starts
  • Data-centered architectures (focused on data integrity), The term refers to systems in which the access and update of a widely accessed data store is their primary goal.
    • blackboard: the system sends notification and data to subscribers when data of interest changes, and is thus active
      • Two kinds of components
        • Central data structure — blackboard
        • Components operating on the blackboard
    • repository: a client sends a request to the system to perform a necessary action
    • Resource-Oriented Architecture
  • layer architectures : layers communicate down, The higher layer sees the lower layers as a set of services, Often, a layer communicates ONLY with the layer below it. Connectors are protocols of layer interaction.
    • Abstraction layer architectures
    • N-tier architectures
  • Notification architectures
    • publish/subscribe
      • Components: Publishers, subscribers, proxies for managing distribution
      • Connectors: Typically a network protocol is required.
    • point-to-point
    • Event based: Components communicate with the event buses, not directly to each other.
      • Components: Independent, concurrent event generators and/ or consumers
      • Connectors: Event buses (at least one)
  • Network-Centred Style: Focus on communication
    • Client-Server
      • Components are clients and servers
      • Connectors are RPC-based network interaction protocols
    • Peer to peer
  • Remote Invocation Architectures
    • Web services
    • Broker: The broker hides the communication from the components of the system. Support for distributed systems
    • Interpreters: parses and executes input commands, updating the state maintained by the interpreter
  • GUI Architectures (Interactive)
    • Model-­View­‐Controller
      • Both controller and view, depend on the model. Controller and view are part of the UI
    • Presentation-­Abstraction-­Control
    • Difference between MVC and PAC
      • The Controllers of MVC focus on the input from and the output to Views,
      • While the Controllers of PAC focus on the communication and coordination among agents and the ones inside agents.
      • PAC divides the systems into layered and loose coupled agents,
      • While MVC focuses on the separation of Models and Views, in which there are no layered agents.
  • Adaptable Architectures
    • micro-­kernel
    • reflection
  • Transaction-Processing Architectures: A process reads a series of inputs one by one. Each input describes a transaction – a command that typically (for example) might change some data stored by the system.
  • Others
    • process control
    • rule-­based: Inference engine parses user input and determines whether it is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query.
  • Heterogeneous Architectures
  • Attribute Driven Design (ADD) can be used to design an architecture to satisfy both quality and functional requirements

7_Frameworks

  • J2EE Architecture
    • JSPs and servlets handle the presentation.
    • EJBs handle the business logic.
    • Three basic tiers in the J2EE platform: Client tier, Middle tier, Backend tier
      • Client tier
      • Web tier (presentation): Servlets and JSPs provide a means to separate presentation logic from content.
      • EJB tier (business): hosts the following: Application-specific business objects, System-level services (such as transaction management, concurrency control, and security). The EJB tier is a critical link between the web tier and the EIS integration tier.
      • EIS Integration tier (integration): provides the information infrastructure for an enterprise.


  • Model-View-Controller (MVC) pattern
  • Model-View-Presenter (MVP) pattern
  • Model-View-ViewModel (MVVM) pattern: Model does not know anything about the UI, View is a UI element (e.g. a Window). “Something” somehow fills the gap. VM Only knows about the Model.


Passive View

Supervising Controller Pattern

  • Model – Data, View – Presentation Layer, C or VM or P – Glue Logic

8_OO Design Principles

  • Open-Closed Principle: Open for extension, closed for modification.
  • Liskov Substitution Princple: Anywhere you specify a base type, you should be able to use an instance of a derived type.
  • Single Responsibility Principle: An entity should have only single reason to change (responsibility). separation of concerns
  • Law of Demeter: Methods should not invoke methods of other objects’ members
  • Divide and conquer
  • High Cohesion
  • Low Coupling
  • Enterprise Architecture Principles: reuse, Buy rather than build

9_Quality Attributes

  • QA focus on non-functional requirements.
  • Two basic types of scaling:
    • Vertically, by increasing the computing power of a single machine (scale up)
    • Horizontally, by adding more machines (scale out)

  • Runtime QA
    • PURS (performance, usability, reliability, security)
    • Performance: time performance, memory, disk, or network utilization
      • factors: Choice of algorithms, Database design, Communication, Resource management
      • tactics: Control resource demand (reduce demand on resources), Manage resources (work more efficiently)
    • Usability: human factors, easy to learn, easy to use, … Usability requires that the system responds to user actions within a certain period of time.
    • Reliability: availability, safety, … measures the failure rate of the system, specified by mean time to failure MTTF. A related measure: mean time between failures MTBF, MTTR is mean time to repair. MTBF = MTTF + MTTR, Availability = MTTF/MTBF
      • tactics: Detect faults (identify non-working components), Recover from faults (what to do in case of faults), Prevent faults (how to increase availability)
    • Security: authentication, data protection, … Security requires a lot of checking: performance will suffer → usability will suffer
      • tactics: Resist attacks, Detect attacks, React to attacks, Recover from attacks
  • Non-runtime QA
    • MeTRiCS (maintainability, evolvability, testability, reusability, integrability, configurability, scalability)
    • Maintainability: how easy can you fix bugs and add new features
      • Reduce size of components, Increase cohesion, Reduce coupling, Defer binding
    • Evolvability: how easy your system copes with changes
    • Testability: how easy can you test the system for correctness
      • tactics: Control and observe system state (make testing easier), Limit complexity (complex systems are harder to test, thus make them simpler)
    • Reusability: how easy is to use software elements in other contexts, e.g. a software library
    • Integrability: how easy you can make the separately developed components of the system work correctly together
    • Configurability: how easy can a system be configured for different installations and target groups
    • Scalability: how easy the system copes with a higher performance demand
  • Business QA: Related to costs and schedule; Related to marketing; Projected lifetime of the system
  • Non-Functional Concepts: Implications of cross-cutting concerns

  • A quality attribute scenario is a quality-­attribute-specific requirement. It consists of six parts.

    • Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus.
    • Stimulus. A condition that needs to be considered when it arrives at a system.
    • Environment. The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.
    • Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.
    • Response. The response is the activity undertaken after the arrival of the stimulus.
    • Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.
  • Availability is concerned with system failure and its associated consequences.

    • failure & fault: A fault may become a failure if not corrected or masked. That is, a failure is observable by the system’s user and a fault is not. When a fault does become observable, it becomes a failure.
    • tactics: fault detection (ping/echo, heartbeat, and exceptions), fault recovery (active/passive redundancy, spare), fault repair (shadow operation, state resynchronization, and rollback), fault prevention (Removal from service, Transactions, Process monitor)
      • heartbesat: In this case one component emits a heartbeat message periodically and another component listens for it. If the heartbeat fails, the originating component is assumed to have failed and a fault correction component is notified.


  • Testability Tactics
    • providing input and capturing output: Record/playback, Separate interface from implementation, Specialize access routes/interfaces.
    • internal monitoring: Built-­‐in monitors