Phân tích thiết kế hướng đối tượng - Chương 4.5 (HUST) GV.Phạm Ngọc Nam

LI
lienhejb
0 次下载
27
0

资料内容

第 3 页

1. Introduction goupee.vn The Physical Architecture Layer design models the system’s hardware, software andgoupee.com network environments  Design for Physical Architecture Layer:-  [1] Reflects the non-functional requirements, e.g. operational, security and human-oriented requirements  [2] Models the infrastructure, and specifies the hardware and software of that infrastructure  Most modern IT systems involve co-operating computers  Web-based systems execute in a client’s browser and interact with a Web server, and possibly kinds of other server, via the Internet  An IT system operating entirely within a company’s network may have applications on a given computer that interact with other servers, e.g. a database server, within the same network  Design for physical architecture layer must model [1] how system is distributed amongst computers, [2] the hardware of those computers and [3] the software on those computers  Most systems exploit existing hardware and software infrastructure  Another significant constraint is existing hardware and software procurement arrangements, e.g. licensing and vendor agreements/relationships  Often, a variety of different infrastructures are used and hence available for “pilot” projects to evaluate new architectures and their interrelationships  Effective Physical Architecture Layer design is a specialist discipline  Often, consultants (internal and/or external) are used  Non-functional requirements must be evolved into proposed architecture(s) and modelled in a UML deployment diagram  The resulting model is then used to specify the hardware and software (e.g.fb.com/goupee.vn 3 database systems) that will support the IT system CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 4 页

1.1 Elements of Physical Architecture Layer goupee.vn goupee.com  Software must be assigned to hardware  Assigning software involves its component parts  Parts can be given various application architectures:-  [1] Server-based  [2] Client-based  [3] Client-server  The most common  Software system has four functions  [1] Data storage  Modelled by Data Management Layer as the persistent objects  Data is documented in structural model (CRC cards and Class Diagrams)  [2] Data Access Logic  As modelled by Data Access and Management Classes in Data Management Layer  Describes processing required to access stored data, e.g. SQL queries  [3] Application logic  As modelled in Problem Domain Layer’s functional and behavioural models  Functional Model = Activity Diagrams and Use Cases  Behavioural Models = Sequence and Communication diagrams % Behavioural State Machines  [4] Presentation Logic  Modelled in HCI layer  Hardware components are  [1] Client computers  I/O devices or system’s users, e.g. desktop/laptop computers, handheld, mobile, etc  [2] Servers  Mainframes, minicomputers and high-end microcomputersfb.com/goupee.vn 4  [3] Connecting Network CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 5 页

1.3 Server-Based Architectures goupee.vn goupee.com  Initially all architectures were server-based  Central (mainframe) computer performed all four application functions  Clients (dumb terminals) enables messages (keystrokes) to be sent to server and received messages from server (instructions defining what to display) More machines and/or more applications slows server response times UpgradeServer All messages MustOr through one ProcessNew central server ServerAll ExpensiveMessages Application software and its data stored on same computer fb.com/goupee.vn 5 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 6 页

1.4 Client-Based Architectures goupee.vn goupee.com  Client = PC, server is (high-end) PC on same Local Area Network (LAN)  Client has its own processing capability Presentation Logic Presentation Logic Application Logic Application Logic Data Access Logic Data Access Logic All data must Presentation Logic Presentation Logic Application Logic Application Logic travel from server Data Access Logic Data Access Logic to client for processing Presentation Logic Application Logic Data Access Logic Only Application software has Presentation Logic, Presentation Logic, its own (application) Application Logic Logic, and Data Access Data Access Logic logic fb.com/goupee.vn 6 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 7 页

1.4 Client-server Architectures goupee.vn goupee.com  Client has Presentation Logic  Server has Data Access Logic and Data Storage  Application Logic  [1] On Client  [2] On Server  [3] Shared between Client and Server If most ofIf most of Application Logic onApplication Logic onApplication logic fb.com/goupee.vn Server = “Thin” ClientClient = “Thick” (or “Fat”) Client7 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 8 页

1.4 continued… goupee.vn goupee.com  Advantages of Client-Server  [1] Scaleability  Storage capacity and processing power of servers can be increased (or decreased) easily  If one (or more) servers performance degrades add one (or more) servers to perform the Application Logic, Data Access Logic or Data Storage Application Logic Data Access Logic Data Storage Application Logic Data Access Logic fb.com/goupee.vn 8 Application logic CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 9 页

1.4 continued… goupee.vn goupee.com  [2] Can support many kinds of clients and servers  Different computers running different operating systems  Middleware on clients and servers enables client software to communicate with middleware  Middleware translates/reformats message into middleware standardised language  Standardised language processible by middleware on server Server Client Application’s Message Original message + Middleware Reformatted + Middleware Message fb.com/goupee.vn 9 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 10 页

1.4 continued… goupee.vn goupee.com  [3] Thin-client server architecture using Internet standards enable separation of Presentation Logic, Application Logic and Data Access Logic  Design of each can be independent  Presentation Logic in HTML and XML  Application logic in modules linked (by statements in programming language) to interface logic  Can change Application Logic without changing Presentation Logic or Data  [4] No single server supports all applications  No central point of failure can halt the entire network  If a server fails, other servers still available  But, applications requiring failed server will not work  Disadvantage is complexity due to separation of software between Client and Server(s)  Writing distributed software more complex  Updating distributed software also more complex  Have to update ALL clients and ALL servers  Micro-computer-based client-server now very common  But total cost includes hardware and other ownership costs fb.com/goupee.vn 10 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 11 页

2. Client-Server Tiers goupee.vn goupee.com  Most common partitioning of Application Logic between Client and Server is:- Clients Servers Client has Server has Presentation Data And Application fb.com/goupee.vn 11 Tier Tier = 2 Tier CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 12 页

2. continued… goupee.vn Separate goupee.com  3-Tiered Architecture Application Server Tier Tier Tier  n-Tiered Architecture (n=4) Application Logic Distributed across Two or more Application Servers fb.com/goupee.vn 12 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 13 页

2. continued… goupee.vn goupee.com  Advantage of n-Tiering (as “n” increases) is separation of processing across servers  Potential is to better balance the load on different servers  IF Application Server performance degrades THEN  [1]Replace with another more powerful server  OR  [2]Increase number of Application Servers  IF Database Server load is underused THEN store another applications data on it  Disadvantages of n-tiering (as “n” increases” are:-  Increase in communication between servers  More difficult to develop (implement and test) software distributed over increasing numbers of devices that collaborate in a computation fb.com/goupee.vn 13 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 14 页

3. Distributed Objects Computing (DOC) goupee.vn goupee.com  Previously “messages” were sent between distributed components  “Message” may be request from Client to resolve SQL query and return data from Database Server via Data Access Logic (on same server)  DOC is middleware layer between Clients & Servers  Middleware enables interactions between distributed objects  Abstracts over actual Physical Network Architecture  Enables developer to ignore actual Physical Network Architecture  Can concentrate on Physical Architecture independent properties of system  Developer can “ignore” which server contains which set of objects  Client simply request “Network” to resolve (locate and execute) Server object’s methods  Physical location of Server object not known by Client  Lack of server-specific code in Client access enables Server(s) to be added and removed without affecting Client code  Middleware maps to storage address  Only middleware needs updating if object’s address changes  Reduces maintenance overheads  Can reduce efficiency of applications  Currently three “approaches” (standards) for DOC  [1] OMG’s CORBA Common Object Request Broker Architecture standard  [2] Sun’s EJB Enterprise JavaBeans (EJB)  Java 2 Enterprise Edition (J2EE)  [3] MicroSoft’s DCOM Distributed Component Object Modelfb.com/goupee.vn and .Net 14 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 15 页

4. Selecting a Physical Architecture goupee.vn goupee.com  Cost Of Infrastructure  Client-server architectures now commonplace because  PC’s (including high-end servers) relatively inexpensive  Place lower load on network  Cost of Development  Client-server more complex and hence more costly than server-based  Ease of Development  Legacy systems developers have specialised abilities unsuited to non- Server-based systems  Client-Based and Client-Server developers have development tools with intuitive graphical interfaces  Developing Client-Server requires interoperability of hardware layers, software layers and middleware  Interface Capabilities  Server-Based applications have only character-based I/O  Modern systems require GUI’s, web-based interfaces, graphical icons, WIMPS fb.com/goupee.vn 15 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 16 页

4. continued… goupee.vn goupee.com  Control and Security  Server-Based architecture centralises control and secures data, easier to administrate  Client-Server involves collaborating components (hardware and software, including middleware) with potential for security and control problems  Scalability  Ability to increase (or decrease) capacity of infrastructure to meet changing demands  Client-Server is most easily scaled  Can increase (or decrease) number of servers  Individual servers can be upgraded as demand grows  fb.com/goupee.vn 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 17 页

5. (UML) Deployment Diagram goupee.vn goupee.com  Show relationships between hardware components in physical infrastructure (of information system)  IF a WAN (Wide Area Network) used for distributed system THEN communication relationships between nodes in network defined  Also used to represent software components and their deployment over physical architecture/infrastructure  IF software represented THEN diagram = execution environment (for system)  Nodes: Hardware components  Client computers, servers, separate networks, individual (networked) devices  Labelled with its name (possibly a stereotype <<text>>>)  Stereotype = type of node  E.g. device, mobile device, database server, web server, application server  Extended syntax = network node symbols  Artifacts: Elements of information system deployed onto physical architecture  E.g. Software component, subsystem (module), database table, (entire) database, layer  Labelled with its name (possibly a stereotype <<text>>>)  Stereotype = type of node  E.g. source file, database table, executable file  Communication paths: Links between nodes of the network  Stereotype = type of link OR protocol  E.g. LAN, Internet, serial, parallel, USB OR TCP/IP fb.com/goupee.vn 17 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 18 页

5.1 Deployment Diagram Syntax goupee.vn dfgd goupee.com fb.com/goupee.vn 18 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 19 页

5.1 continued… goupee.vn goupee.com  Three different versions of a Deployment Diagram Basic Standard Notation Stereotypes Imply Artefact Deployed on Node Hardware Requirements Extended Notation Emphasises hardware requirements (Omits software distribution) fb.com/goupee.vn 19 CuuDuongThanCong.com https://fb.com/tailieudientucntt

第 20 页

6. Network Model goupee.vn goupee.com  [1] Major components of IT system and their geographic locations in “high-level” UML Deployment Diagram  Shows software components and their interrelationships  Used to develop hardware and software specification  Elements are clients, servers, network equipment, external systems & networks  Locations are geographic sites related to elements Application Locations in Many-to-many Canada connections by External Service provider Application Network Locations in connection US between Brampton fb.com/goupee.vn and20 Ottawa CuuDuongThanCong.com https://fb.com/tailieudientucntt

显示前 20 页。下载资料查看完整内容。

评论 (0)

登录 以加入讨论

暂无评论。快来抢沙发吧!