Transcript Document
Introduction to Software Architecture 1 Introduction ◦ ◦ ◦ ◦ Background What is software architecture? What’s wrong with the diagram? Software architecture definition Why is Software Architecture Important? ◦ Communication among stakeholders ◦ Early design decisions ◦ Transferable abstraction of a system Architectural Structures and Views ◦ Module ◦ Connector-Component ◦ Allocation 2 Think about a situation where we are trying to build a new dog house. ◦ we can build a new one simply by cutting the wood and driving a nail into the wood 3 How about a situation where we have to build a two-storied house? ◦ We need More workers More instruments ◦ We may need to draw a blue-print before constructing the house 4 What if we want to construct a high-rise building ◦ Many specialists are involved ◦ The high-rise building cannot be built without careful planning and design Architectures are the key to the successful construction of the building planning design construction 5 Analogy ◦ As the size and complexity of software systems increases, the design of overall system structuresoftware architecture- become more significant issues than the choice of algorithms and data structures of computation. ◦ Structural issues include The organization of a system as a composition of components The protocols for communications The assignment of functionality to design elements Physical distribution, etc. 6 Control process (CP) Prop loss model (MODP) Reverb model (MODR) Noise model (MODN) 7 Many things are left unspecified: ◦ ◦ ◦ ◦ What What What What is the nature of the elements? are the responsibilities of the elements? is the significance of the connections? is the significance of the layout? Box and arrow drawings alone are not architectures; rather, they are a starting point All architectural descriptions require three fundamental things: ◦ a drawing - illustrating major parts of systems ◦ a legend - explaining what the graphic representation ◦ a prose - describing the drawing 8 Perry and Wolf, 1992 A set of architectural (or design) elements that have a particular form. Perry and Wolf further distinguish between processing elements, data elements, and connecting elements. Boehm et al., 1995 A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements. Clements et al., 1997 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. 9 Architecture defines major components Architecture defines component relationships (structures) and interactions Architecture omits content information about components that does not pertain to their interactions Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component Every system has an architecture (even a system composed of one component) Architecture defines the rationale behind the components and the structure Architecture definitions do not define what a component is Architecture is not a single structure -- no single structure is the architecture 1 0 A unit of distribution, assembly, deployment, and replacement Implementing a nontrivial functionality Defined by services it provides and services it requires ◦ Services reveal component’s behavior only as far as required for assembly Meaningful in context of ◦ architecture ◦ Component model and a framework Not necessarily a single unit of code or a single binary 1 1 Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction architecture design implementation CODE Architectural decisions are the most fundamental decisions and changing them will have significant ripple effects. 1 2 Architectural renderings begin to appear after requirements elicitation and analysi s ◦ typically we iterate between requirements and analysis Customer Requirements Architecture 1 3 User view of problem User Model Builder’s view of problem Requirements Modules and connections Architecture Methods data structures Algorithms & data Data layouts, memory maps Design Code Executable 1 4 Abstractly as box-and-line diagrams Accompanying prose ◦ Explain the meaning behind the symbols ◦ Provide some rationale for the specific choice of components and interactions Ex) “Camelot is based on the client-server model and uses remote procedure calls …” “We have chosen a distributed, object-oriented approach to managing information” [Orfali 99] Request Web Server Browser Document HTML Documents CGI application [Conallen 99] Request ISAPI NSAPI Java Servlet DataBase Scripted Scripted Scripted Page Scripted Page Page Page Browser Document ASP JSP Web Server Scripted Scripted Scripted Page HTML Page Page Page Dataflow systems ◦ Batch sequential ◦ Pipes and filters Call-and-return systems ◦ Main program and subroutine ◦ OO systems ◦ Hierarchical layers Independent components ◦ Communicating process ◦ Event systems Virtual machines ◦ Interpreters ◦ Rule-based systems Data-centered systems(Repositories) ◦ Databases ◦ Hypertext systems ◦ Blackboards Components + Connectors + Constraints ◦ Components : Computational components ◦ Connectors : Interactions among components ◦ Constraints : How they can be combined What is the design vocabulary? What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of using that style? What are some of the common specializations?? Components ◦ Filters Connectors ◦ Pipes Invariants ◦ Filters must be independent entities. Should not share state with other filters ◦ Filters do not know the identity of their upstream and downstream filters CourseFilter 15671 Input File MainFilter MergeFilter CourseFilter 21701 Filter File Pipe Output File Main controller Sub 1 Sub 2 Sub 3 comp manager mem mem System model ◦ Call and definition hierarchy ◦ Subsystems often defined via modularity Components ◦ Procedures and explicitly visible data Connectors ◦ Procedure calls and explicit data sharing Control ◦ Single thread data data methods methods data methods methods methods data data methods data Components ◦ Objects(Manager), Instance of ADT Connectors ◦ Function and Procedure calls Invariants ◦ An object is responsible for preserving the integrity of its representation ◦ The representation is hidden from other objects Advantage ◦ Possible to change the implementation without affecting those clients ◦ Allow designers to decompose problems into collections of interacting agents Disadvantage ◦ Must know the identity of that other object ◦ Whenever the identity of an object changes it is necessary to modify all other objects that explicitly invoke A B e2 e1 C D Components ◦ Modules whose interfaces provide both a collection of procedures and a set of events Connectors ◦ Event registration and procedure invocation Invariants ◦ Announcers of events do not know which components will be affected by those events Reactive integration, Selective broadcast ◦ A component can announce one or more events ◦ Other components can register an interest in an event by associating a procedure with it ◦ When the event is announced, the system itself invokes all of the procedures that have been registered for the event ◦ An event announcement implicitly causes the invocation of procedures in other modules Usages ◦ Programming environments to integrate tools ◦ In database management systems Ensure consistency constraints ◦ In user interfaces to separate presentation of data from applications that manage data ◦ Syntax directed editors ◦ Debugger Application Layer System Service Layer Resource Management Layer Kernel Layer Components ◦ Layers Each layer provides service to the layer above it and serves as a client to the layer below Connectors ◦ Protocols Constraints ◦ Topological ◦ Limit interaction to adjacent layers Usage ◦ Communication layer OSI ISO model ◦ Database systems and Operating system Some of the X window system protocols comp comp comp Repository comp comp comp Components ◦ Central data structure Represent the current state, ◦ A collection of independent components Operate on central data store Traditional Database ◦ The types of transactions in an input stream trigger selection of processes to execute Blackboard ◦ The current state of the central data structure is the main trigger for selecting processes to execute Blackboard ◦ The knowledge source Separate, independent parcels of applicationdependent knowledge. Interaction among knowledge sources takes place solely through the blackboard ◦ The blackboard data structure Problem-solving state data Organized into an application-dependent hierarchy ◦ Control Driven by the state of the blackboard Knowledge sources respond opportunistically when changes in the blackboard make them applicable ks ks ks ks ks Blackboard (shared data) ks ks ks ks ks Memory data (program state) program being interpreted instruction data updates Interpretation Engine inputs interpreter control unit instruction interpreter state interpreter execution unit outputs System model ◦ Virtual machines Components ◦ One state machine and three memories Connectors ◦ Data access and procedure call Control ◦ Usually state transition for execution engine ◦ Input-driven for selection of what to interpret Memory knowledge base rules working memory facts rules and facts data updates Inference Engine rule scheduler selected action engine state inputs rule interpreter outputs System model ◦ Virtual machines Components ◦ One inference engine and three memories (knowledge base, working memory, and inference engine state) Connectors ◦ Data access and production rule application Control ◦ Usually state transition for inference engine ◦ Goal-driven for selection of what to interpret Compiler construction - 1 Text Code Lex Syn Sem Opt Code Opt Code Sym tab Text Lex Syn Sem Code Compiler construction - 2 Sym tab Text Lex Syn Sem Tree Opt Code Code Compiler construction - 3 Sem Opt Syn Opt Lex Tree Code Sym tab Edit Syn The concept of software architecture Software architecture patterns Building software systems from parts Software Architecture Analysis Discussion A part of a deployed system Purchased from a vendor Sold in binary form in identical copies Available to general public Example ◦ Windows NT, Netscape Communicator COTS Market ◦ Examine which products? Selected ◦ Which products are fit? Adapted ◦ Use which features Assembled ◦ Which design best reflects market factors? Refreshed ◦ Version, Upgrading Code size ◦ Each piece was huge by itself ◦ (Ex) Tools had to include X, even if they didn’t need it Performance ◦ Efficiency can be low Need to modify/understand reused parts in significant ways ◦ Event loop rewrite ◦ Memory allocation Architecture assures conceptual integrity while allowing change ◦ New requirements ◦ Changed requirements ◦ Technology churn Architecture supports system longevity 5 2 “Divide and conquer” ◦ Decomposition into components ◦ Hiding of implementation details Separation of concerns ◦ Components (and layers) encapsulate details ◦ Different components can be implemented by people with different expertise 5 3 Architecture iterations remove major risks Architecture prototypes allow for collection of metrics ◦ Development cost metrics ◦ Schedule metrics 5 4 Well componentized systems support better and easier ◦ Diagnostics ◦ Traceability ◦ Error detection Testing is use-case driven 5 5 Architecture defines rules of substitution Component interfaces define substitution boundaries Architecture enables different granularity of reuse ◦ Small-scale reuse at component level ◦ Large-scale reuse Subsystems Products Frameworks 5 6 architecture supports communication between stakeholders Different views address different stakeholder concerns architecture communicates key design decisions architecture design rationale communicates the tradeoffs 5 7 Organizational structure aligned with architecture ◦ Development team(s) ◦ Subcontractors Components/subsystems used as units of ◦ ◦ ◦ ◦ Development CM Testing Delivery and upgrade Components/subsystems developed concurrently 5 8 Software Requirements and Specificatio ns, Michael Jackson, 1995 Software Software Architecture: Perspectives on a n Emerging Discipline, Shaw & Garlan, 1 996 Architecture in Practice, Bass, Clements, & Kazman, 1998 5 9