CAS 703 Software Design

Transcription

1 Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on Software Architecture by Tao et al. (Chapters 6 and 7)

2 1 Data Centered Architecture Architecture Virtual Machine

3 Patterns for Data Centered and Arch. Data Centered Architecture The data centered software architecture Is characterized by a centralized data store The data store is shared by all related software components The software system is decomposed into two major partitions data store independent software component agents The connections between the data modules and software components are implemented by explicit method invocation implicit method invocation based on the repository category Data Centered Architecture Architecture

4 Patterns for Data Centered and Arch. Data Centered Architecture In pure data centered software architecture The software components do not communicate with each other directly All the communications are conducted via data store The shared data module provides all mechanisms for software components to access it insertion deletion update retrieval Data Centered Architecture Architecture

5 Patterns for Data Centered and Arch. Data Centered Architecture There are two categories of data centered architecture (differentiated by the flow control strategy) The data store is passive Clients of the data store are active (software component are taking control of flow logic) Client may access a repository interactively by a batch transaction request is widely used in database management system library information system Computer Aided Software Engineering (CASE) Data Centered Architecture Architecture

6 Patterns for Data Centered and Arch. Data Centered Architecture Data Centered Architecture Architecture Figure: architecture

7 Patterns for Data Centered and Arch. Data Centered Architecture There are two categories of data centered architecture (Continued) The data store in blackboard architecture is active Its clients are passive that the flow logic is determined by the current data status in the data store The clients of a blackboard are called knowledge sources A new data change may trigger events to its listeners (subscribers) Data Centered Architecture Architecture

8 Patterns for Data Centered and Arch. Data Centered Architecture There are two categories of data centered architecture (Continued) (Continued) A new data change may drive the flow logic continually until a goal is reached Most software applications designed in the blackboard architecture are knowledge based systems voice and image recognition system security system Data Centered Architecture Architecture

9 Patterns for Data Centered and Arch. Data Centered Architecture Data Centered Architecture Architecture Figure: architecture

10 Patterns for Data Centered and Arch. Architecture In this architectural style, the system is viewed as a hierarchical structure The software system is decomposed into functional modules (sub-systems) The modules at different levels are connected by explicit method invocations A lower level module provides services to its adjacent upper level modules In procedure orientation, the lower level function and procedures may be organized in a header file or library Data Centered Architecture Architecture

11 Patterns for Data Centered and Arch. Architecture In the object orientation, the lower level services may be organized in a package of classes Many system software (e.g., Unix) are built by hierarchical architecture The services at lower levels provide more specific fundamental utility service The middle layer provides all business logic or core processing services The upper layer provides user with interface Each layer is supported by its lower layer and provides service interface to its upper layer Data Centered Architecture Architecture

12 Patterns for Data Centered and Arch. Architecture Data Centered Architecture Architecture Figure: Unix Architecture

13 Patterns for Data Centered and Arch. Architecture The HA is characterized by explicit method invocation (call-and-return) connection styles It is used in the organization of class library It can be applied to procedure-oriented design, object-oriented design, component-oriented design, domain-specific design, and many others It is hard to see any software that only uses one type architectural style The hierarchical structure is one of the most popular styles that often combine with other styles Data Centered Architecture Architecture

14 Patterns for Data Centered and Arch. It supports user interaction for data processing instead of batch sequential transaction processing The software component agents of the data store control the computation and flow logic of the system Clients can get data from data store and put data in the store Different clients may have different interfaces and different privileges

15 Patterns for Data Centered and Arch. Figure: Student management system (simplified class diagram)

16 Patterns for Data Centered and Arch. The Student class is a data bean class which is backed up by a corresponding table in a database public class Student implements Serializable { String SSN; String Name; public Student() { SSN = ; Name = ; } public Student(String ssn, String name) { SSN = ssn; Name = name; } public void setssn(string ssn) { SSN = ssn; } public String getssn() { return SSN; } public void setname(string name) { Name=name;} public String getname() { return Name; } }

17 Patterns for Data Centered and Arch. The connection between the data bean class and an Oracle database try { } Class.forName( sun.jdbc.odbc.jdbcodbcdriver ); Connection connection = DriverManager.getConnection( "jdbc:odbc:students"); catch(exception e){... }

18 Patterns for Data Centered and Arch. JDBC SQL statement to select all records from the students table and place them in the ResultSet ArrayList studentlist = new ArrayList() ; Statement statement = connection.createstatement () ; ResultSet results = statement.executequery("select * FROM students ) ; Student student = new Student() ; while (results. next ()) { student.setssn(results.getssn(l)) ; student.setname(results.getname(2)) ; studentlist.add(student) ; }

19 Patterns for Data Centered and Arch. Figure: Dynamic view of this repository architecture

20 Patterns for Data Centered and Arch. The relational database management system is a typical design domain for the repository architecture The data store of the repository maintains all types of data including schema (meta-data), data tables, and index files for data tables Many tools available to develop application on the database stored in database management system tools, development tools, maintenance tools, and documentation tools Oracle er, Oracle Developer, Oracle data warehouse, etc. Computer Aided Software Engineering (CASE) system is another design domain for the rep. soft. arch.

21 Patterns for Data Centered and Arch.

22 Patterns for Data Centered and Arch. Applicable domain of repository Large complex information system where many software component clients need to access it in different aspects Information system where data transactions drive the control flow of computation Benefits Data integrity: easy to backup and restore System scalability and Reusability of agents: easy to add new software component Reduce the overhead of transient data between software components

23 Patterns for Data Centered and Arch. Limitations Data store reliability & availability are important issues Centralized repository is vulnerable to failure compared to distributed repository with data replication High dependency between data structure of data store and its agents The changes of data structure have significant impacts on its agents Overhead cost of moving data on network if data is distributed Related Architecture architecture, multi-tier architecture, Model-view-controller (MVC) architecture

24 Patterns for Data Centered and Arch. The word blackboard comes from classroom teaching and learning Teacher and students can share data in solving a hard open problem on classroom blackboard Each student and each teacher plays a role of agent to make their contributions to the problem solving They all can work in parallel and very independently The idea of blackboard architecture is very similar to the classroom blackboard

25 Patterns for Data Centered and Arch. It is a data directed and partial data driven architecture The whole system is decomposed into two major partitions blackboard sub-system used to store data (hypotheses and facts) knowledge source sub-system (domain-specific knowledge is stored) There may be a third sub-system called controller (used to initiate the blackboard and knowledge sources, takes a bootstrap role and overall supervision control)

26 Patterns for Data Centered and Arch. The connections between the two partitions are implicit invocation from the blackboard to a specific knowledge source in the blackboard The data change in the blackboard triggers a matched knowledge source to continue its reasoning The data change may be caused by new deduced conclusion or hypotheses results by some knowledge sources (called publish/subscribe mode)

27 Patterns for Data Centered and Arch. Figure: architecture

28 Patterns for Data Centered and Arch. Many domain specific knowledge sources collaborate together to solve a complex problem such authentication in information security Each knowledge source is relatively independent from other knowledge source No need to interact with each other They only need to interact and respond to the blackboard sub-system Each source only works on a specific aspect of the problem, and contributes a partial solution to the ultimate solution

29 Patterns for Data Centered and Arch. Figure: UML class diagram of rule-based blackboard software architecture

30 Patterns for Data Centered and Arch. Knowledge source (Set of rules) RI: IF animal gives milk THEN animal is mammal R2: IF animal eats meat THEN animal is carnivore R3: IF animal is mammal AND animal is carnivore AND animal has tawny color AND animal has black stripes THEN animal is tiger (The set of facts) F I: animal eats meat F2: animal gives milk F3: animal has black strips F3: animal has tawny color The goal is to recognize an animal (Using forward reasoning or backward reasoning)

31 Patterns for Data Centered and Arch. Figure: Sequence diagram of blackboard architecture

32 Patterns for Data Centered and Arch. Figure: Publish/subscribe relationship between blackboard and knowledge sources

33 Patterns for Data Centered and Arch. Figure: architecture for a travel consulting system

34 Patterns for Data Centered and Arch. Applicable domain Suitable for solving immature and complex problems where non deterministic solutions exist The problem spans multiple disciplines Optimal, partial, or approximate solution is acceptable to the problems Exhausted searching is impossible and impractical since it may take forever Benefits Scalability: easy to add new knowledge source or update existing knowledge source Concurrency: all knowledge sources can work in parallel since they are very independent of each other

35 Patterns for Data Centered and Arch. Benefits (Continued) Supports experimentation for hypotheses Reusability of knowledge source agents Limitations Tight dependency between the blackboard and knowledge source Difficult to make a decision when to terminate reasoning Synchronization of multiple agents is an issue Debugging and testing of the system is a challenge (no clear execution path) Related architecture Implicit invocation architecture such as event-based

36 Patterns for Data Centered and Arch. The main/subroutine design architecture has dominated the software design methodologies for very long time Its purpose is to have maximum reuse of subroutines and make individual subroutine be developed independently In the classical procedure orientation, often all the data are shared by related subroutines at lowest level In the object orientation, the data is encapsulated in each individual object Often M/S style is refered to as the traditional style

37 Patterns for Data Centered and Arch. Figure: Typical hierarchical software architecture

38 Patterns for Data Centered and Arch. A system is decomposed into subroutines hierarchically according to the desired functionality of the system Behaviour hiding (secrets = input formats, screen formats, messages) Software decision hiding (secrets= algorithms and data structures) Machine hiding (secrets= hardware machine, virtual machine, interfaces, etc.) The refinements are conducted vertically until the decomposed subroutine is simple enough

39 Patterns for Data Centered and Arch. Figure: Main/subroutines architecture

40 Patterns for Data Centered and Arch. The main program is the program driver that has a mater control over the sequencing of its subroutines How to map a requirement specification to the design structure? Start from a data flow view (Data Flow Diagram) of the requirements We need to find transform or transaction flows: Transform Flow (flow feeds in an external format, it is transformed into an internal format, and then carried out) Transaction Flow (evaluates its incoming data value, and decides on the path to follow)

41 Patterns for Data Centered and Arch. How to map a requirement specification to the design structure? (Continued) A transform flow is mapped to an M/S architecture with a controlling module for incoming, transform and outgoing information processing A transaction center is located at the fork origin of action paths Classify each action path to transform or transaction flows The transaction centre becomes a dispatcher control module Factoring analysis continues until each module in the software architecture has its sole responsibility

42 Patterns for Data Centered and Arch. Figure: Mapped M/S structure

43 Patterns for Data Centered and Arch. Benefits Easy to decompose the system based on the definition of the tasks in a top down refinements manner This architecture can still be used in a sub-system of 00 Limitation Globally shared data in classical main/subroutines are vulnerable Tight coupling may cause ripple impacts compared to 00

44 Patterns for Data Centered and Arch. Software Architecture The architecture is a variant of the main/subroutine architecture style It supports fault tolerance and system reliability The slaves provide replicated services to the master The master selects a particular result among slaves by certain selection strategy The slaves may perform the same functional task by different algorithms and methods

45 Patterns for Data Centered and Arch. Figure: Block diagram for master/slaves architecture

46 Patterns for Data Centered and Arch. Figure: Class diagram for master/slaves architecture

47 Patterns for Data Centered and Arch. This architecture is suitable for parallel computing and accuracy of computation All slaves can be executed in parallel A task is delegated to several different implementations, inaccurate results can be detected Applicable Domains Software system where the liability is critical Software system where performance is critical (to a certain limit communication overhead )

48 Patterns for Data Centered and Arch. Architecture System is decomposed into a number of higher and lower layers Each layer consists of a group of related classes in a format of package or deployed component (OOD) a group of subroutines in the format of method library or header file Each layer should have its own sole responsibility for the entire system

49 Patterns for Data Centered and Arch. A request to layer i + 1 invokes the services provided by the layer i via the later interface The response may go back to the layer i + 1 if the task is completed by this layer i Otherwise, layer i continually invokes the layer i 1 below for services The interface of each layer encapsulates all detail service implementations in the current layer or below

50 Patterns for Data Centered and Arch. Figure: A partial layered architecture

51 Patterns for Data Centered and Arch. The request from higher layer to the layer below is made via the method invocation and the response goes back up via the method return Each layer has two interfaces up interface provides services to its upper layer low interface requires services from its lower layer In a pure layered hierarchy, each layer only provides services to the adjacent upper layer directly and only requests services from the adjacent layer directly below

52 Patterns for Data Centered and Arch. Figure: Business oriented software architecture

53 Patterns for Data Centered and Arch. Higher layer provides more generic or application oriented services (abstract) Lower layer provides more specific utility type services To encapsulate all the services in one layer, we can deploy each layer in a component format (such as a JAR file (Java ARchive) )) A JAR file is a compressed file which is deployed as a component of a package

54 Patterns for Data Centered and Arch. A jar file includes all the service classes from lower level plus other related classes provided in the same layer and provided by Java API The Java API is the set of classes included with the Java Development Environment These classes are written using the Java language and run on the JVM The Java API includes everything from collection classes to GUI classes

55 Patterns for Data Centered and Arch. Figure: Component-based layered architecture

56 Patterns for Data Centered and Arch. A simple software system may consist of two layers (Interaction& Processing) Interaction Layer It provides user Interfaces to clients It takes requests It validates and forwards request to processing layer for processing It responds to clients Processing Layer It gets the forwarded requests and performs business logic process It accesses database It returns the results to its upper layer It lets upper layer respond to clients (since the upper layer has the GUI interface responsibility)

57 Patterns for Data Centered and Arch. Figure: Object Access Protocol (SOAP) layered architecture

58 Patterns for Data Centered and Arch. Figure: Class diagram for layered architecture

59 Patterns for Data Centered and Arch. Applicable Domains Any system that can be divided between the application specific portions and platform specific portions Applications that have clean divisions between core services, critical services, user interface services Applications that have a number of classes that are closely related to each other so that they can be grouped together to provide the services to others. Benefit Incremental software development based on increasing levels of abstraction Enhanced independence of layers Enhanced reusability Component-based technology is a suitable technology to implement the layered structure (plug-and-play) Promotion of portability: each layer can be an abstract machine deployed independently

60 Patterns for Data Centered and Arch. Limitations Lower runtime performance (a client s request/response goes through many layer) Performance concerns on overhead on the data marshaling and buffering by each layer Many applications can not fit this architecture Exception and error handling is an issue in the layered architecture Related architecture, client/server, virtual machine

61 Patterns for Data Centered and Arch. Virtual Machine Virtual Machine It is built on an existing system It separates a programming language, hardware language, or application from a physical execution platform It plays the role of an emulation software It provides an emulation of the functions of one system using a different system It allows exact reproduction of external behavior of a system

62 Patterns for Data Centered and Arch. Virtual Machine Figure: Unix virtual machine

63 Patterns for Data Centered and Arch. Virtual Machine Figure: Common Language Runtime (CLR) virtual machine in.net platform

64 Patterns for Data Centered and Arch. Virtual Machine Figure: Java virtual machine

65 Patterns for Data Centered and Arch. Virtual Machine Applicable Domain Solving a problem by simulation or translation Interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Small talk and Java interpreter typed programming language Benefits Portability and machine platform independence Simplicity of the software development Simulation for non-native model

66 Patterns for Data Centered and Arch. Virtual Machine Limitations Slow execution of the interpreter Additional overhead due to the new layer Related architecture Interpreter, repository, layered architecture

67