LECTURE 7 Software Architecture Ivan Marsic Rutgers University

LECTURE 7: Software Architecture Ivan Marsic Rutgers University

Topics • Software Architecture Definition • Architectural Decisions & Key Concerns • Problem Decomposition & Problem Architecture • Architectural Styles • Documenting Architecture: Views 2

Hierarchical Organization of Software Product line (or product family) highest abstraction level System or product Subsystems/Modules Packages Classes/Objects Methods lowest level Source code We know there are different views of abstraction in software … 3

Software Architecture Definition • Kiến trúc phần mềm = Một tập các quyết định ở mức trừu tượng hóa cao về các phần tử quan trọng của hệ thống đích và quan hệ giữa chúng – Các quyết định mang tính nguyên tắc được đưa ra trong suốt quá trình phát triển và tiến hóa của một hệ thống phần mềm – Được quyết định sớm và ảnh hưởng đến những mảng lớn của hệ thống (“triết lý thiết kế”) — về sau khó những quyết định này khó thay đổi • Kiến trúc phần mềm không phải một pha trong quá trình phát triển 4

Example Architectural Decisions Safe Home Access System Subsystem for device control Subsystem for administration Subsystem for remote data access Quyết định về phân rã hệ thống On embedded computer On office desktop On tenant’s smartphone Quyết định về ánh xạ software-to-hardware Những quyết định như vậy được đưa ra sớm, Có thể trong khi thảo luận với khách hàng về yêu cầu phần mềm Để xác định sẽ sử dụng những thiết bị phần cứng nào để tương tác với người dùng và để điều khiển thiết bị 5

Software Architecture các mối quan tâm chính (Principal decisions to be made) • Phân rã hệ thống – System decomposition – Cách chia hệ thống thành từng mảnh? – Ta đã có đủ các mảnh cần thiết chưa? – Các mảnh có khớp nhau không? • Cross-cutting concerns – Đặc điểm và chất lượng của hệ thống khi xét phạm vi rộng hơn – Cân bằng giữa các tiêu chí chất lượng • Conceptual integrity 6

System Decomposition Product line (or product family) System or product Subsystems/Modules Packages Classes/Objects Methods The hierarchy shows a taxonomy of the system parts, but not the procedure for decomposing the system into parts — how do we do it? But, why do we want to decompose systems? 7

Tại sao cần phân rã hệ thống? • Xử lý bài toán phức tạp bằng cách “chia để trị” • Xem có phần nào đã có sẵn và có thể tái sử dụng • Tập trung vào những phần đòi hỏi tính sáng tạo và tránh phát minh lại cách bánh xe • Hỗ trợ sự linh động cho tiến hóa về sau bằng cách tách những phần không liên quan, để chúng có thể tiến hóa riêng rẽ (“separation of concerns”) • Tạo lợi thế chiến lược cho việc kéo dài tuổi thọ của hệ thống 8

Architecture versus Design • Architecture tập trung vào các yêu cầu phi chức năng (“cross-cutting concerns”) và sự phân rã của các yêu cầu chức năng • Design tập trung vào việc cài đặt các yêu cầu chức năng – Chú ý: ranh giới không phải lúc nào cũng rõ ràng! 9

Thường có thỏa hiệp trong các quyết định thiết kế • Thiết kế “tốt nhất” cho một thành phần nếu xét riêng mình nó có thể không được chọn khi xét một ngữ cảnh rộng hơn hoặc khi xét quan hệ giữa các thành phần • Ngoài ra còn phải xét đến các ưu tiên doanh nghiệp, nguồn lực, năng lực, khách hàng nhắm đến, các bước đi của đối thủ cạnh tranh, xu hướng công nghệ, các nguồn đầu tư, tương thích phiên bản cũ, … 10

Decomposition: Projection vs. Partitioning (a) (b) 11

Problem Decomposition Xác định các hệ thống con từ các yêu cầu 12

Các bài toán điển hình của CNPM 1. a) System transforms input document to output document 1. User works with computer system (environment irrelevant/ignored) IN doc User System OUT doc 1. b) User edits information stored in a repository System Repository User 2. Computer system controls the environment (user not involved) System Environment 3. Computer system intermediates between the user and the environment 3. a) System observes the environment and displays information User System Environment 3. b) System controls the environment as commanded by the user 13 User System Environment

Problem Architecture 1. a) Transformation: Feeding subsystem Transformation subsystem Receiving subsystem Data editor 1. b) Simple workpieces: User Data repository 2. Required behavior: Controlling subsystem Controlled subsystem 3. a) Information display: Monitoring subsystem Monitored subsystem Controlling subsystem Controlled subsystem Display 3. b) Commanded behavior: Operator 14

Các phong cách kiến trúc • World Wide Web architectural style: REST (Representational State Transfer) • UNIX shell script architectural style: Pipe-and-Filter • Client/Server • Central Repository (database) • Layered (or Multi-Tiered) • Peer-to-Peer • Model-View-Controller 15

Architectural Styles – Constituent Parts 1. Các thành phần – Components – Processing elements that “do the work” 2. Connectors – Phương tiện cho phép các thành phần liên lạc với nhau • Broadcast Bus, Middleware-enabled, không tường minh (events), tường minh (procedure calls, ORBs, explicit communications bus) … 3. Các giao diện – Interfaces – Các điểm nối giữa component và connector • Định nghĩa vị trí dữ liệu đi vào đi ra các component/connector 4. Cấu hình - Configurations – Sắp xếp các component và connector hợp thành một kiến trúc 16

Architectural Style: Pipe-and-Filter • Components: Filters biến đổi input thành output • Connectors: Pipe data streams • Example: UNIX shell commands filter % ls filter pipe folder-name | pipe filter grep –v match-string | more 17

Architectural Style: Layered Còn gọi là Kiến trúc phân tầng User Interaction User Interface Layer User Authentication Archiving Control of Sensors and Devices Communicating alerts about intrusion Domain Logic Layer (Business Rules) Technical Services Layer 18

Architectural Style: Model-View-Controller ¨ Model: nắm toàn bộ dữ liệu, trạng thái và logic của ứng dụng. Không biết gì về View và Controller. Cung cấp API để lấy trạng thái và gửi thông báo về trạng thái cho “observer” ¨ View: cho ta một biểu diễn của Model. Lấy dữ liệu thẳng từ Model ¨ Controller: Lấy input của người dùng và tìm hiểu xem nó có ý nghĩa gì đối với Model display 5. I need your state (to display) View 4. I have changed 3. Change your display 1. The user did something user Controller input device Model 2. Change your state 19

Model-View-Controller User Interface Model Controller Input device events User Visual feedback of the altered model Event Interpreter Domain model action Model Visualizer Notification about the effects of the action View Model: array of numbers [ 14, 26, 31 ] 26 14 Different Views for the same Model: Domain Model 31 14 versus 31 26 20

Hệ thống thực tế là kết hợp của các dạng kiến trúc Subsyste m for device control Subsystem for administration Central Repository Subsystem for remote data access - Valid keys - Access history - Tenant profiles -… Application server Web browser 21

Lắp các mảnh vào với nhau • Đặc tả interface – Một dạng hợp đồng giữa các component và các module sử dụng, interface phải… • Có tài liệu đầy đủ • Mô tả cả ngữ nghĩa chứ không chỉ cú pháp sử dụng • Hiểu được, nội dung gọn, chính xác về ngữ nghĩa • Thêm nội dung – Mô tả không chính thức – Các mô hình thiết kế (v. d. , biểu đồ tương tác UML) – pre/post conditions 22

Làm tài liệu về kiến trúc phần mềm: Architecture Views • Views are different kinds of “blueprints” created for the system-to-be • Ví dụ. các bản vẽ cho tòa nhà: xây dựng, đường ống nước, đường điện, hệ thống sưởi, hệ thống điều hòa nhiệt độ, … (những người khác nhau có nhu cầu thông tin khác nhau) 1. Module/Subsystem Views 2. Component and Connector Views 3. Allocation Views 23

Module/Subsystem Views • Decomposition View – Top-down refinement (e. g. , simple “block diagram”) • Dependency View – How parts relate to one another • Layered View – Special case of dependency view • Class View – “domain model” in OOA and “class diagram” in OOD 24

Component and Connector Views • Process View – Defined sequence of activities? System represented as a series of communicating processes • Concurrency View • Shared Data View – … • Client/Server View – E. g. , in Web browsing 25

Allocation Views • Deployment View – Software-to-hardware assignment • Implementation View – File/folder structure – “package diagram” • Work Assignment View – Work distribution within the development team 26