Software Architecture

صفحه 1:
Software Architecture CIS 376 Bruce R. Maxim UM-Dearborn 

صفحه 2:
Software Architecture * Architectural Design - process for identifying the subsystems that make up a system - defines framework for sub-system control and communication * Software Architecture - description of the system output by architectural design 

صفحه 3:
Architectural Design Process * System structuring - system decomposed into several subsystems - subsystem communication is established * Control modeling - model of control relationships among system components is established * Modular decomposition - identified subsystems decomposed into modules 

صفحه 4:
Architectural Models Static structural model - shows major system components Dynamic process model - shows process structure of the system Interface model - defines subsystem interfaces Relationships model - data flow or control flow diagrams 

صفحه 5:
Sommerville discusses several architectural models 

صفحه 6:
CASE Repository Model 

صفحه 7:
Call-Return Model 

صفحه 8:
Real-Time System Control Model ae 4 Pod » ۱ 7 Computation > se ‏اس‎ Crit ۶ ١ ‏ممم‎ ) intaface ) ۱ hander ) 

صفحه 9:
Selective Broadcasting Model Subsystem. Subsystem. سج Event and message hander 

صفحه 10:
vector Intenupts Interrupt-Driven Control Model 

صفحه 11:
Compiler Model ا ‎tdle‏ ۲ Lexical > Syntactic > © Semantic > 0 0 ١ _ andlysis yr _ alysis , analysis Pr geerdion ) 

صفحه 12:
OSI Reference Model Application Presentation Session Transport Network Data link Physical Network Datalink Physical Comnuniaations medium. Application Presentation Session, Transport Network Datalink Physical 

صفحه 13:
Distributed Systems * Most large computer systems are implemented as distributed systems * Information is also distributed over several computers rather than being confined to a single machine ٠ Distributed software engineering has become very important 

صفحه 14:
System Types * Personal systems - designed to run on a single user system * Embedded systems - may run on a single processor - might run on an integrated group of processors ٠ Distributed systems - system software runs on loosely integrated group of cooperating processors linked by a network 

صفحه 15:
Distributed Systems Characteristics Concerns ¢ Resource sharing ۰ Complexity * Openness * Communication * Concurrency 8 ۳ Securit * Scalable 0 oye ۰ ° Fault tolerant Manageability Transparent * Quality of Service * Unpredictability 

صفحه 16:
Distributed Systems Architectures * Client/Server - offer distributed services which may be called by clients - servers providing services are treated differently than clients using the services * Distributed Object - no distinctions made between clients and servers - any system object may provide and use services from any other system object 

صفحه 17:
Middleware * Software that manages and supports the different components of a distributes system * Sits in the middle of the system to broker service requests among components * Usually off-the-shelf products rather than custom * Representative architectures - CORBA (ORB) - COM (Microsoft) - JavaBeans (Sun) 

صفحه 18:
Multiprocessor Architecture * Simplest distributed system model * System composed of multiple processes that may execute on different processors * Model used in many large real-time systems * Distribution of processes to processors may be preordered or may be under control of a dispatcher 

صفحه 19:
Multiprocessor Traffic Control System from Sommerville Sensor ‘Trafic flow Traffic ightoortra QO. ‏پات‎ moe 9 79 7 ۱ ‏سل( > تحص‎ eS pes ۳ ‘Traffic lights ‏مسم ی‎ ۳ 

صفحه 20:
Client/Server Architectures * Application is modeled as a set of services that are provided by servers and a set of clients that use these services * Clients know the servers but the servers do not need to know all the clients * Clients and servers are logical processes (not always physical machines) * The mapping of processes to processors is not always 1:1 

صفحه 21:
Client/Server System from Sommerville © 9 @) Oe = OQ» O “KK @ ‏لتكر علد‎ oO 

صفحه 22:
Representative Client/Server Systems Part 1 * File servers - client requests selected records from a file - server transmits records to client over the network * Database servers - client sends SQL requests to server - server processes the request - server returns the results to the client over the network 

صفحه 23:
Representative Client/Server Systems part 2 * Transaction servers - client sends requests that invokes remote procedures on the server side - server executes procedures invoked and returns the results to the client * Groupware servers - server provides set of applications that enable communication among clients using text, images, bulletin boards, video, etc. 

صفحه 24:
Client/Server Software Components User interaction/presentation subsystem Application subsystem - implements requirements defined by the application within the context of the operating environment - components may reside on either client or server side Database management subsystem Middleware - all software components that exist on both the client and the server to allow exchange of information 

صفحه 25:
Representative Client/Server Configurations - part 1 ¢ Distributed presentation - database and application logic remain on the server - client software reformats server data into GUI format ۰ Remote presentation - similar to distributed presentation - primary database and application logic remain on the server ~ data sent by the server is used by the client to prepare the user presentation 

صفحه 26:
Representative Client/Server Configurations - part 2 * Distributed logic - client is assigned all user presentation tasks associated with data entry and formulating server queries - server is assigned data management tasks and updates information based on user actions * Remote data management - applications on server side create new data sources - applications on client side process the new data returned by the server 

صفحه 27:
Representative Client/Server Configurations - part 3 * Distributed databases - data is spread across multiple clients and servers - requires clients to support data management as well as application and GUI components * Fat server - most software functions for C/S system are allocated to the server ۰ Thin clients - network computer approach relegating all application processing to a fat server 

صفحه 28:
Thin Client Model * Used when legacy systems are migrated to client server architectures - the legacy system may act as a server in its own right - the GUI may be implemented on a client * It chief disadvantage is that it places a heavy processing load on both the server and the network 

صفحه 29:
Fat Client Model More processing is delegated to the client as the application processing is locally extended Suitable for new client/server systems when the client system capabilities are known in advance More complex than thin client model with respect to management issues New versions of each application need to installed on every client 

صفحه 30:
Three-tier Architecture ٠ Each application architecture layers (presentation, application, database) may run on separate processors ۰ Allows for better performance than a thin-client approach * Simpler to manage than fat client approach * Highly scalable (as demands increase add more servers) 

صفحه 31:
Three-Tier Architecture from Sommerville ‘Database server Customer SQL] “Scoot ddabase SQL query HITP interaction ‘Web server ‘Account service piovision ۱ 

صفحه 32:
Guidelines for Distributing Application Subsystems ¢ The presentation/interaction subsystem is generally placed on the client. * If the database is to be shared by multiple users connected by a LAN, the database is typically located on the server. * Static data used for reference should be allocated to the client. 

صفحه 33:
Linking Client/Server Software Subsystems * Pipes - permit messaging between different machines running different operating systems ۰ Remote procedure calls - permit process running on one machine to invoke execute of process residing on another machine * Client/server SQL interaction - SQL requests passed from client to server DBMS, this mechanism is limited to RDBMS 

صفحه 34:
Design Issues for Client/Server Systems - part 1 * Data and architectural design - dominates the design process to be able to effectively use the capabilities of RDBMS or OODMBS ¢ Event-driven paradigm - when used, behavioral modeling should be conducted - the control-oriented aspects of the behavioral model should translated into the design model 

صفحه 35:
Design Issues for Client/Server Systems - part 2 * Interface design - elevated in importance - user interaction/presentation component implements all functions associated with a GUI * Object-oriented point of view - often chosen, since object structure is provided by events initiated in the GUI and their event handlers within the client-based software 

صفحه 36:
Architectural Design for Client/Server Systems - part 1 * Best described as communicating processes style architecture ¢ Architectural goal is to achieve easy scalability when adding and arbitrary number of clients * Modern C/S systems tend to be component-based * An object request broker (ORB) architecture is used for implementation 

صفحه 37:
Architectural Design for Client/Server Systems - part 2 * Object adapters or wrappers facilitate communication among clients and servers - component implementations are registered - all component references are interpreted and reconciled component references are mapped to corresponding component implementations - objects are activated and deactivated - operations are invoked when messages are transmitted security features are implemented 

صفحه 38:
Client/Server Design Repository Information - part 1 * Entities (from ER diagram) * Files (which implement entities) * File-to-field relationship (establishes file layout) * Fields (from data dictionary) * File-to-file relationships - related files that may be joined together * Relationship validation 

صفحه 39:
Client/Server Design Repository Information - part 2 * Field type - used to permit inheritance from super classes * Data type (characteristics of field data) * File type (used to identify file location) * Field function (key, foreign key, attribute, etc.) * Allowed values * Business values - rules for editing, calculating derived fields, etc. 

صفحه 40:
Data Distribution and Management Techniques - part 1 * Relational data base management systems * Manual extract - user allowed to manually copy data from server to client * Snapshot - automates manual extract by specifying a copy of the data be transferred from the client to the server at predefined intervals 

صفحه 41:
Data Distribution and Management Techniques - part 2 * Replication - multiple copies of data are maintained at different sites ¢ Fragmentation - system database is spread across several machines 

صفحه 42:
Client/Server Design Approach 1. For each elementary business process, identify the files created, updated, referenced, or deleted. 2. Use files from step 1 as basis for defining components. 3. For each component, retrieve the business rules and other business object information that has been established for the relevant file. 4. Determine which rules are relevant to the process and decompose the rules down to the method level. 5. As required, define any additional components that are needed to implement the methods. 

صفحه 43:
Process Design Entities - part 1 * Methods - describe how a business rule is to be implmemented * Elementary processes - business processes identified in the analysis model * Process/component link - identifies components that makeup the solution for an elementary business process 

صفحه 44:
Process Design Entities - part 2 * Components - describes components shown on structure chart ¢ Business rule/component link - identifies components significant to implementation of a given business rule 

صفحه 45:
Client/Server Testing Strategy part 1 ¢ Application function tests - client applications tested in stand alone manner * Server tests - test coordination and management functions of server - also measure performance of server * Database tests - check accuracy and integrity server data - examine transactions posted by client, test archiving 

صفحه 46:
Client/Server Testing Strategy part 2 * Transaction testing - ensure each class of transactions is processed correctly * Network communication testing - verify communication among network nodes 

صفحه 47:
Client/Server Testing Tactics Begins with testing in the small and then proceeds to integration testing using the non- incremental or big bang approach Requires special attention to configuration testing and compatibility testing * OO testing tactics can be used for C/S systems GUI testing requires special techniques in C/S systems (e.g. structured capture/playback) 

صفحه 48:
Distributed Object Architectures ۰ No distinctions made between client objects and server objects * Each distributable entity is an object that both provides and consumes services * Object communication is though an object request broker (middleware or software bus) ٠ More complex to design than client/server systems 

صفحه 49:
Distributed Object 04 5) Architecture from Sommerville 500 03 S(03) ‘Software bus 02 S(02) S(o5) S(ol) 

صفحه 50:
Distributed Object Architecture Advantages ¢ Allows system designer to delay decisions on where and how services should be provided * Very open architecture that allows new resources to be added as required * System is flexible and scalable * Dynamic reconfiguration is possible by allowing objects to migrate across the network as required 

صفحه 51:
Uses of Distributed Object Architectures ¢ As a logical model that allows you to structure and organize the system - think about how to provide application functionality solely in terms of services and combinations of services * As a flexible approach to the implementation of client/server systems ~ the logical model of the system is client/server with both clients and servers realized as distributed object communicating through a software bus 

صفحه 52:
Data Mining System Report gen. | =] Viswdiser حك Display na | from Sommerville ‘Databese 1 Example — Database 2 = om = 

صفحه 53:
CORBA International standard for an Object Request Broker (e.g. middleware) to manage distributed object communication Largely platform and language independent (by having versions for several OO environments) DCOM is Microsoft’s alternative approach (but it is highly platform dependent) 

صفحه 54:
CORBA Services * Naming and trading services - allow object to discover and refer to other objects on the network * Notification services - allow objects to notify each other when events have occurred * Transaction services - support atomic transactions and rollback on failure 

صفحه 55:
CORBA Application Structure from Sommervill 0 Application Domain 01 ‏كاه‎ facilities Object request broker 

صفحه 56:
CORBA Standards * Provides a model for application objects - COBRA objects encapsulate a state with a well-defined, language neutral interface ٠ A single object request broker that manages requests for object services ٠ A set of object services that may be of use to many distributed applications ٠ A set of common components built on top of these services 

صفحه 57:
Object Request Broker (ORB) Handles object communications Knows about all system objects and their interfaces Using the ORB a client object binds an IDL (interface definition language) stub and defines the interface of the server object Calling the stub results in calls to the ORB which calls the required object through a published IDL skeleton that links the interface to the service implementation 

صفحه 58:
ORB-based Communications from Sommerville IDL IDL Object Request Broker 

صفحه 59:
Inter-ORB Communications * ORB’s are not usually separate programs * ORB’s are usually linked object libnraries * ORB’s handle communication between objects executing on the same machine * Each computer in a distributed system may have its own ORB * Inter-ORB communication is used to handle distributed object calls 

صفحه 60:
Inter-ORB Communications from Sommerville ol 02 93 04 SoD 502 503 1 IDL IDL IDL IDL Object RequestBroker Object Request Broker