Bài giảng Introduction to Software Engineering - Week 6: Architectural Design - Nguyễn Thị Minh Tuyền

ey are not useful, and the
 pattern’s strengths and weaknesses.
£ Patterns may be represented using tabular and
 graphical descriptions.
 21
 Examples of patterns 
£ Model-View-Controller (MVC) pattern
£ Layered architecture pattern
£ Repository pattern
£ Client–server pattern
£ Pipe and filter pattern
 22
 Model-View-Controller (MVC) 
 pattern
£ Description
 p Separates presentation and interaction from the system data.
 p Is structured into three logical components that interact with each
 other.
 ¡ The Model component: manages the system data and associated
 operations on that data.
 ¡ The View component: defines and manages how the data is presented
 to the user.
 ¡ The Controller component: manages user interaction (e.g., key
 presses, mouse clicks, etc.) and passes these interactions to the View
 and the Model.
£ Is used when
 p There are multiple ways to view and interact with data.
 p The future requirements for interaction and presentation of data are
 unknown.
 23
 Model-View-Controller (MVC) 
 pattern
£ Advantages
 p Allows the data to change independently of its representation and
 vice versa.
 p Supports presentation of the same data in different ways with
 changes made in one representation shown in all of them.
£ Disadvantages
 p Can involve additional code and code complexity when the data
 model and interactions are simple.
 24
 Organization of the MVC
 Controller View View
 selection
Maps user actions Renders model
to model updates Requests model updates
Selects view Sends user events to
 User events controller
 Change
 notification
 State State query
 change
 Model
 Encapsulates application
 state
 Notifies view of state
 changes
 25
Web application architecture using the 
 MVC pattern
 Browser
 Controller View
 Form to
 display
 HTTP request processing Dynamic page
 Application-specific logic generation
 Data validation Forms management
 User events
 Change
 notification
 Update Refresh request
 request
 Model
 Business logic
 Database
 26
 Layered architecture
£ Used to model the interfacing of sub-systems.
£ Organises the system into a set of layers (or
 abstract machines) each of which provide a set of
 services.
£ Supports the incremental development of sub-
 systems in different layers. When a layer interface
 changes, only the adjacent layer is affected.
 27
 Layered architecture pattern
£ Description
 p Organizes the system into layers with related functionality
 associated with each layer.
 p A layer provides services to the layer above it so the lowest-level
 layers represent core services that are likely to be used throughout
 the system.
£ Used when
 p Building new facilities on top of existing systems;
 p The development is spread across several teams with each team
 responsibility for a layer of functionality;
 p There is a requirement for multi-level security.
 28
 Layered architecture pattern
£ Advantages
 p Allows replacement of entire layers so long as the interface is
 maintained.
 p Redundant facilities (e.g., authentication) can be provided in each
 layer to increase the dependability of the system.
£ Disadvantages
 p In practice, providing a clean separation between layers is often
 difficult and a high-level layer may have to interact directly with
 lower-level layers rather than through the layer immediately below
 it.
 p Performance can be a problem because of multiple levels of
 interpretation of a service request as it is processed at each layer.
A generic layered architecture
 User interface
 User interface management
 Authentication and authorization
Core business logic/application functionality
 System utilities
 System support (OS, database etc.)
 30
Architecture of the LIBSYS system
 Web browser interface
 LIBSYS Forms and Print
 login query manager manager
 Distributed Document Rights
 Accounting
 search retrieval manager
 Library index
 DB1 DB2 DB3 DB4 DBn
 31
Architecture of the iLearn system
 Repository architecture
£ Sub-systems must exchange data. This may be
 done in two ways:
 p Shared data is held in a central database or repository
 and may be accessed by all sub-systems;
 p Each sub-system maintains its own database and
 passes data explicitly to other sub-systems.
£ When large amounts of data are to be shared, the
 repository model of sharing is most commonly
 used a this is an efficient data sharing mechanism.
 33
 Repository pattern
£ Description
 p All data in a system is managed in a central repository that is
 accessible to all system components.
 p Components do not interact directly, only through the repository.
£ Used when
 p You have a system in which large volumes of information are
 generated that has to be stored for a long time.
 p You may also use it in data-driven systems where the inclusion of
 data in the repository triggers an action or tool.
 34
 Repository pattern
£ Advantages
 p Components can be independent—they do not need to know of the
 existence of other components.
 p Changes made by one component can be propagated to all
 components.
 p All data can be managed consistently (e.g., backups done at the
 same time) as it is all in one place.
£ Disadvantages
 p The repository is a single point of failure so problems in the
 repository affect the whole system.
 p May be inefficiencies in organizing all communication through the
 repository.
 p Distributing the repository across several computers may be
 difficult.
 35
 A repository architecture for an IDE
 UML Code
 editors generators
 Java
 editor
 Design Project
translator repository
 Python
 editor
 Design Report
 analyzer generator
 36
 Client-server architecture
£ Distributed system model which shows how data
 and processing is distributed across a range of
 components.
 p Can be implemented on a single computer.
£ Set of stand-alone servers which provide specific
 services.
£ Set of clients which call on these services.
£ Network which allows clients to access servers.
 37
 Client–server pattern
£ Description
 p In a client–server architecture, the functionality of the system is
 organized into services, with each service delivered from a separate
 server.
 p Clients are users of these services and access servers to make use
 of them.
£ Used when
 p Data in a shared database has to be accessed from a range of
 locations.
 p Load on a system is variable.
 38
 Client–server pattern
£ Advantages
 p Servers can be distributed across a network.
 p General functionality can be available to all clients and does not
 need to be implemented by all services.
£ Disadvantages
 p Each service is a single point of failure so susceptible to denial of
 service attacks or server failure.
 p Performance may be unpredictable because it depends on the
 network as well as the system.
 p May be management problems if servers are owned by different
 organizations.
 39
A client–server architecture for a film 
 library
 Client 1 Client 2 Client 3 Client 4
 Internet
 Catalog Video Picture Web
 server server server server
 Library Film store Photo store Film and
catalogue photo info.
 40
 Pipe and filter architecture
£ Functional transformations process their inputs to
 produce outputs.
£ May be referred to as a pipe and filter model.
£ Variants of this pattern are very common. When
 transformations are sequential, this is a batch
 sequential model which is extensively used in data
 processing systems.
£ Not really suitable for interactive systems.
 41
 Pipe and filter pattern
£ Description
 p The processing of the data in a system is organized so that each
 processing component (filter) is discrete and carries out one type of
 data transformation.
 p The data flows (as in a pipe) from one component to another for
 processing.
£ Used when
 p Commonly used in data processing applications (both batch- and
 transaction-based) where inputs are processed in separate stages
 to generate related outputs.
 42
 Pipe and filter pattern
£ Advantages
 p Easy to understand and supports transformation reuse.
 p Workflow style matches the structure of many business processes.
 Evolution by adding transformations is straightforward.
 p Can be implemented as either a sequential or concurrent system.
£ Disadvantages
 p The format for data transfer has to be agreed upon between
 communicating transformations.
 p Each transformation must parse its input and unparse its output to
 the agreed form. This increases system overhead and may mean
 that it is impossible to reuse functional transformations that use
 incompatible data structures.
 43
 Example of the pipe and filter 
 architecture
 Issue
 Receipts
 receipts
Read issued Identify
 invoices payments
 Find Issue
 payments payment Reminders
 due reminder
 Invoices Payments
 44
 Topics covered
£ Architectural design decisions
£ Architectural views
£ Architectural patterns
£ Application architectures
 45
 Application architectures
£ Application systems are designed to meet an
 organizational need.
£ As businesses have much in common
 p their application systems also tend to have a common
 architecture that reflects the application requirements.
£ A generic application architecture is an
 architecture for a type of software system that may
 be configured and adapted to create a system that
 meets specific requirements.
 46
 Use of application architectures
£ As a starting point for architectural design.
£ As a design checklist.
£ As a way of organizing the work of the
 development team.
£ As a means of assessing components for reuse.
£ As a vocabulary for talking about application types.
 47
 Examples of application types
£ Data processing applications
 p Data driven applications that process data in batches without
 explicit user intervention during the processing.
£ Transaction processing applications
 p Data-centered applications that process user requests and
 update information in a system database.
£ Event processing systems
 p Applications where system actions depend on interpreting
 events from the system's environment.
£ Language processing systems
 p Applications where the users' intentions are specified in a
 formal language that is processed and interpreted by the
 system.
 48
 Application type examples
£ Focus here is on transaction processing and
 language processing systems.
£ Transaction processing systems
 p E-commerce systems;
 p Reservation systems.
£ Language processing systems
 p Compilers;
 p Command interpreters.
 49
 Transaction processing systems
£ Process user requests for information from a
 database or requests to update the database.
£ From a user perspective, a transaction is:
 p Any coherent sequence of operations that satisfies
 a goal;
 p For example - find the times of flights from London
 to Paris.
£ Users make asynchronous requests for service
 which are then processed by a transaction
 manager.
 50
 Structure of transaction processing 
 applications
 I/O Application Transaction
processing logic manager Database
 51
Software architecture of an ATM system
 Input Process Output
 Get customer
 Print details
 account id
 Query account
 Validate card Return card
 Update account
 Select service Dispense cash
 ATM Database ATM
 52
 Information systems architecture
£ Information systems have a generic architecture
 that can be organized as a layered architecture.
£ These are transaction-based systems as
 interaction with these systems generally involves
 database transactions.
£ Layers include:
 p The user interface
 p User communications
 p Information retrieval
 p System database
 53
Layered information system architecture
 User interface
 User communications Authentication and
 authorization
 Information retrieval and modification
 Transaction management
 Database
 54
 Architecture of the Mentcare
 Web browser
 Form and menu Data
 Login Role checking
 manager validation
 Security Patient info. Data import Report
management manager and export generation
 Transaction management
 Patient database
 55
 Web-based information systems
£ Information and resource management systems are
 now usually web-based systems
 p user interfaces are implemented using a web browser.
£ Example:
 p E-commerce systems are Internet-based resource
 management systems that accept electronic orders for goods
 or services and then arrange delivery of these goods or
 services to the customer.
 p In an e-commerce system, the application-specific layer
 includes additional functionality supporting a ‘shopping cart’ in
 which users can place a number of items in separate
 transactions, then pay for them all together in a single
 transaction.
 56
 Server implementation
£ These systems are often implemented as multi-tier
 client server/architectures
 p The web server is responsible for all user
 communications, with the user interface implemented
 using a web browser;
 p The application server is responsible for implementing
 application-specific logic as well as information storage
 and retrieval requests;
 p The database server moves information to and from the
 database and handles transaction management.
 57
 Language processing systems
£ Accept a natural or artificial language as input and
 generate some other representation of that
 language.
£ May include an interpreter to act on the
 instructions in the language that is being
 processed.
 58
Architecture of a language processing 
 system 
 Translator
 Source
 language Check syntax
 instructions Check semantics
 Generate
 Abstract m/c
 instructions
 Interpreter
 DataFetch Results
 Execute
 59
 Compiler components
£ A lexical analyzer
 p Takes input language tokens and converts them to
 an internal form.
£ A symbol table
 p Holds information about the names of entities
 (variables, class names, object names, etc.) used in
 the text that is being translated.
£ A syntax analyzer
 p Checks the syntax of the language being translated.
£ A syntax tree
 p Is an internal structure representing the program
 being compiled. 60
 Compiler components
£ A semantic analyzer
 p Uses information from the syntax tree and the symbol
 table to check the semantic correctness of the input
 language text.
£ A code generator
 p ‘Walks’ the syntax tree and generates abstract machine
 code.
 61
 A pipe and filter compiler 
 architecture
 Symbol table
 Syntax tree
Lexical Syntactic Semantic Code
analysis analysis analysis generation
 62
 A repository architecture for a 
 language processing system
 Lexical Syntax Semantic
 analyzer analyzer analyzer
Pretty- Abstract Grammar
 Optimizer
printer syntax tree definition
 Symbol Output Code
Editor
 table definition generator
 Repository
 63