University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1 after designing to meet functional requirements, design the system to meet non-functional requirements identify subsystems and components identify concurrency requirements allocate subsystems to processors select data management strategy select human-computer interface strategy/standards specify code development standards, style guides specify all control aspects set priorities for design tradeoffs identify testing and implementation requirements system architecture

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 2 system architecture design of all system aspects: software, hardware, human... software architecture organization of classes into subsystems to satisfy non-functional requirements physical architecture maps the software onto the hardware components type of examples of examples of architecture elements relationships conceptual components/classes connectors module sub-systems, modules data exports, imports code files, libraries, directories includes, contains execution object interactions, tasks, uses, calls threads architecture

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 3 they should have:  clearly defined boundaries  fully defined interfaces with other subsystems so that:  they can be designed and constructed independently of each other  the system complexity is reduced  changes are localized during system maintenance  afford efficient/effective processor allocation  maximize reuse and portability O-O subsystems encapsulate a coherent set of responsibilities

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 4 > subsystemA > subsystemB > subsystemC > subsystemC communication between subsystems changes to the client do not affect the server if the communication remains the same more tightly coupled and may require both to be changed divide into subsystems by... layering separate into different levels of abstraction, layers of service e.g. database handling VS application logic partitioning separate into different types of functionality e.g. sales VS financial

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 5 layer 1 layer 2 layer 3 layer 4 closed architecture open architecture layer 1 layer 2 layer 3 layer 4 layered subsystems layer 2 subsystem layer 3 subsystem layer 2 uses the services of layer 3 minimum dependencies between layers reduces the impact of change more compact, possibly better performance, but change is more complex

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 6 presentation application logic domain database boundary classes - specific to an application control classes - specific to an application entity classes - possibly shared by several applications DBMS - very often shared by several applications examples different levels of abstraction layering options within applications presentation business logic database commonly used for business-oriented information systems

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 7 application presentation session transport network data link physical misc. protocols for common activities structures information and attaches semantics dialogue control and synchronization facilities breaks messages into packets, ensures delivery selects route from sender to receiver detects/corrects errors in bit sequences transmits bits OSI 7 layer model covers every aspect of communication between two applications, incl. application processes and network hardware device control with well-defined interface controls and standards, you can change some layers without affecting others Open Systems Interconnection

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 8 > data application logic user interface shared 2-tier and 3-tier architecture

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 9 customer maintenance order maintenance shipping sales domain sales database partitions partitioning and distributing

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 10 MVC architecture is the foundation for Mac interfaces, Windows, various Unix-based GUI environments model-view-controller model controller A view Bview A controller B > main/core functionality user interfaces manage updates to views supports tailoring to users’ needs

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 11 model: central functionality, implement the application logic, aware of dependent view and controller components view: presentation to user, handles the output, gets data from model, creates associated controller controller:handles the input, trigger updates to views propagation mechanism:enables model to inform each view that the model data has changed this MVC separation allows you to plug in different front-end clients and also provides a separation in development model is driven by data design controller is driven by process design view is driven by screen design model-view-controller

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 12 Reference Framework Architecture Technologies JavaOne2002_2645.ppt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 13 (distributed processing) :Client :ClientSide Proxy :Broker :ServerSide Proxy :Server broker: decouples client and server components, forwards service requests to appropriate servers proxies: insulate clients and servers from broker distributed systems

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 14 for each thread of control, we need different logical processors but do we need: different physical processors multi-tasking operating systems a scheduler subsystem to handle constraints in response times multi-threaded programming language another solution? concurrency

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 15 consider: the number or users and their locations varied needs for operating systems, special servers, special workstations... Internet, intranet... processing power needed concurrency requirements throughput requirements response time processor allocation

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 16 your choices are: file-based with application-controlled storage/retrieval database management system: relational for large data volumes and various access requirements object-oriented for fast access and complex data structures object-relational (new!) data management number of users response time requirements volumes of data throughput requirements etc. consider:

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 17 support: different views of the data by different users control of multi-user access to data distribution of data over different platforms security enforcement of integrity constraints access to data by various applications data recovery portability across platforms data access via query language query optimization database management systems but have significant performance overhead and enforce standard data access mechanisms