Logical View
The Logical View consists of two models: Analysis model and Design Model.
Analysis Model
Overview
The Analysis Model provides a view of the requirements from the system’s perspective. The requirements are refined, structured and the resulting elements are organized into logical groups of similar functionality called analysis packages.
The analysis model contains View-of-participating-classes (VOPC) which map out control, entity and boundary classes.
Analysis Packages
The Analysis Model contains the following main packages. The following diagram shows the overall package structure and dependencies:
Figure 3 - Analysis Model Packages - Top Level Dependencies
| Package Name | Package Description |
|---|---|
| Data Aggregation | This package contains classes which are responsible for consolidating and normalizing bib and item data from all three partner feeds. |
| Data Distribution | This package contains classes responsible for de-normalizing data from ReCAP middleware database and then distributes shared collection data to all 3 partners through SFTP uploads. |
| Search & Discover | This package contains classes which handle all the search requests from OPAC systems. |
| Validate Request | This package contains classes which are responsible for validating any incoming request. |
| Request Item | This package contains classes responsible for processing a ReCAP request. |
| Hold Item | This package contains classes responsible for processing and maintaining hold queue. |
| Recall Item | This package contains classes responsible for processing a recall request. |
| Accession Item | This package contains classes responsible for accessioning new items |
| DeAccession Item | This package contains classes responsible for Deaccessioning existing items |
| Reports | This package contains classes responsible for generating reports for Library staff. |
Key Analysis Classes
Significant analysis classes are described below.
Boundary Classes
Boundary classes represent the interface between the system and the actors.
| Class Name | Class Description |
|---|---|
| GFA Client | A class responsible for invoking SOAP service to interact with GFA LAS for item status. |
| NCIP Client | A class responsible for invoking NCIP responders to update/create item details. |
| Search Service | A class publishing Services related to bib and item records and its real time status. |
| Barcode Client | A class responsible for handling events related to barcode scanning (Borrow Direct requests) |
Control Classes
Control classes represent classes that co-ordinate flow between the entities and the boundary classes.
| Class Name | Class Description |
|---|---|
| Authentication Controller | Controller Class which handles all the incoming requests for authentication. |
| Search Controller | Controller Class which handles all the search requests for shared collection items. |
| Request Controller | Controller Class which handles all the transactions for item requests. |
| Workflow Controller | Controller Class which handles all the workflow requests such as Accessioning and Deaccessioning items. |
| Report Controller | Controller class which handles all the report requests. |
Entity Classes
Entity classes represent information and associated behavior that must be stored. They are usually persistent.
Important entity classes are listed below:
| Class Name | Class Description |
|---|---|
| Bib | A bibliographic record is an entry being a uniform representation and description of a specific content item in a bibliographic database (or a library catalog), containing data elements required for its identification and retrieval, as well as additional supporting information, presented in a formalized bibliographic format |
| Item | An item record represents a physical piece in the library. |
| Request | Entity that contains all the details for every single request received by ReCAP middleware |
Design Model
Architecturally Significant Design Packages
The application has been partitioned into four layers:
- Presentation Layer
- Enterprise Services Layer
- Data Services Layer
- Data Layer
The presentation layer deals with presentation aspects of the system. The enterprise service layer isolates business rules and the data service layer from the presentation layer. The enterprise service layer implements common services such as “Search”, “Retrieve” etc. The Data Service Layer deals with data.
Figure 4 - Package Hierarchy
The presentation layer has been further sub-divided into “System” and “Report” packages. The System package contains the system administration specific implementation of the interfaces. The report package contains the report specific components.
Enterprise Services Layer:
The enterprise services layer contains the “Service” components. The layer uses the “delegate” pattern to delegate to the appropriate architecture (RDBMS or Solr). The underlying services are accessed via a “Façade” bean. Any bean that acts as a façade would contain a delegate class within its package.
The following are sample list of packages that exist within this layer:
Search & Discover – This package contains classes which handle all the search requests from OPAC systems.
Request Item – This package contains classes handling all the logic to process a ReCAP request.
Hold Item – This package contains classes responsible for processing and maintaining hold queue
Recall Item – This package contains classes responsible for processing a recall request.
Accession Item - This package contains classes responsible for accessioning new items DeAccession Item – This package contains classes responsible for Deaccessioning existing items.
Data service layer contains RDMBS and Search Packages. RDBMS package consists of all classes which interact with the relational database and Search Packages consists of classes which interact with SOLR.
Frameworks, Patterns and Guidelines
Application frameworks are a promising technology for reifying proven software designs and implementations in order to reduce the cost and improve the quality of software.
A framework is a reusable, ``semi-complete'' application that can be specialized to produce custom applications. In contrast to earlier OO reuse techniques based on class libraries, frameworks are targeted for particular business units (such as data processing) and application domains (such as user interfaces)
Common Patterns
All the diagrams presented in this section are copyright of their respective creators and ReCAP project will use most it not all the below patterns during its implementation.
Model-View-Controller (MVC) Pattern
The proposed ReCAP architecture will use MVC model for its core framework. The diagram below (courtesy Sun Microsystems) explains the concepts behind MVC:
- Model: The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model
- View: The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data
- Controller: The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
Façade Pattern
The façade pattern is used in the design at many points. Most significant use is via the Service Implementations, where a Service Implementation Class (business service implementation) acts as a façade to the business layer (hiding the business layer complexities) and also provides a simpler interface for the clients to work with.
The diagram below highlights the details of Façade Pattern:
The intent of this pattern is to hide complex underlying structural details with a simpler interface providing following benefits.
- Provides a simpler interface for the clients to work with
- Reduces number of objects that the client needs to work with
- Promotes weak coupling
Business Delegate Pattern
The Business Delegate pattern can be used to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the business tier components. The lookup service could be implemented using the “Service Locator” pattern.
It is normally implemented by defining a business interface, which is implemented by a delegate class and the business component (if the component is being created afresh. If not, then the delegate acts as a façade).
The diagram below illustrates this pattern:
This model will be used wherever multiple implementations are possible for an interface.
Factory Pattern
Factory Method is a pattern used for object creation. This pattern helps model an interface for creating an object, which at creation time can let its sub-classes, decide the class to be instantiated. This is called a Factory Pattern since it is responsible for "Manufacturing" an Object. The Factory Pattern promotes loose coupling by eliminating the need to bind application-specific classes into the code.
The application layer framework will use this pattern to manage the ingestion factory.
Singleton Pattern
Singleton pattern is used to ensure a class has only one instance, and provide a global point of access to it. It also encapsulates “just-in-time initialization” or “initialization on first use”.
The application framework will use this pattern to initialize single instances of all configuration properties.
Chain of Responsibility Pattern
Chain of Responsibility pattern is used to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. This is achieved by chaining the receiving objects and passing the request along the chain until an object handles it. Each object in chain launches and leaves requests with a single processing pipeline that contains many possible handlers thus creating an object-oriented linked list with recursive traversal.
The application framework will use this pattern to manage several independent steps of output creation.
Value Object or Transfer Object Pattern
In typical applications there is a need to get several properties or exchange business data between tiers. This exchange requires multiple round trips over a network and could result in poor performance. To improve the performance the business data could be encapsulated into a “Value” or “Transfer” object and passed to the service. Similarly the service could return a “Value” object, rather than having the client make several “get” calls. Typically value objects have a VO suffix.
The application framework will use this pattern to exchange data across tiers. The following diagram illustrates this pattern:
Service Locator
Service locator pattern is used to abstract the complexities of initializing all services. Multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.
This pattern reduces the client complexity that results from the client's dependency on and need to perform lookup and creation processes, which are resource-intensive. To eliminate these problems, this pattern provides a mechanism to abstract all dependencies and network details into the Service Locator.
Data Access Object
Data Access Object (DAO) pattern is used to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.
The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.
The application framework will use this pattern to encapsulate all data store calls from services.
Inversion of Control (Spring Framework)
Inversion of Control or IoC is one of the techniques used to wire services or components to an application program. By definition, IoC is “A software design pattern and set of associated programming techniques in which the flow of control of a system is inverted in comparison to the traditional interaction mode.” Simply stated, in IoC, instead of an application calling the framework, it is the framework that calls the components specified by the application.
However, IoC is a broad and generic term. The aspect of IoC that the Spring Framework uses is "Injection of required resources or dependency at Run-time into the dependent resource," which is also known as Dependency Injection. Hence, the service provided by the IoC container of Spring is Dependency Injection.