Blahunka - Krajčo - Vančo - System Design Document
From Princípy tvorby software
System Design Document for Stock Management Application
Authors: Juraj Blahunka, Martin Krajčo, Anton Vančo
Document is ready for evaluation.
Contents |
Scope
Identification
Warehouse Management System provides a unified application for stock item, codebook management, generating reports, invoices, credit notes and warehouse task management. Desktop application groups functional actions into separate modules, which are populated from assigned database model repository.
System Overview
Application Purpose
Warehouse management application running at client machines is specifically designed to automatize stock item management by integrating specific actions performed in warehouses into the application. Application stores persistent data in a database or generates output, which can be stored on filesystem or be printed out.
End user perspectives
Manager
Manages user credentials, creates reports, adds new suppliers, distributors with respective stock items.
Customer Care
Manipulates customer stock operations, handles printing and sending of invoices and credit notes. Handles customer reclamations.
Warehouse Operator
Documents internal stock operations (stock in, out).
Operations
System handles user authentication and authorization. Every user has assigned credentials, under which he can operate. Application supports internal stock item management between warehouses, codebook integration into supplier listing, task assignment and document generation.
Applicable Documents
- Blahunka, Krajčo, Vančo - System Specification Document
- Use Case diagram (Specification)
- Use Case description (Specification)
System Design Evaluations
Selection of System Configuration
Desktop application is distributed among client machines; all client machines have to be configured for seamless application runtime. Minimal client side hardware and software requirements can be found in System specification.
The only centralized and most important part of the system is database server, which accumulates and provides data to clients.
Application system is designed with zero fault tolerance and realtime operations, therefore response caching layer is not an option. Further extendability may be provided by directly splitting the load on more database servers, which communicate on a separate layer with unified interface.
Drivers and Constraints
System design imposes important constraints on the deployed network, because of application dependency on centralized data storage.
- database server must allow network incoming connections
- often database back up or mirroring
- network nodes should enable communication on critical application ports.
Desktop realization brings distribution of client load mostly on client machines. Running client applications are not dependent on each other, therefore there is no need for a centralized application server and additional backup plans.
Other Critical Considerations
System is designed in layers, after Model View Controller design pattern, with models oriented more on service oriented architecture, than classical business oriented approach. Models carry state while components wrapping them are designed to be as stateless as possible for testability and error handling in mind.
Extendability
Export and Print components are decoupled from the main hierarchy, for easier addition of new formats during development process.
Filtering components help the GUI with relevant data manipulation and are easily extendable by adding new filters.
System Security
Application requires user authentication only while login/register process, other interactions with user passwords are reduced to minimum. Passwords are hashed and then salted with use of sha-1 algorithm.
User authorization layer implemented into command layer disables performing actions for users with less credentials, than required.
System does not cypher the data flow between application and database server, although it may be possible by wrapping the hibernate framework into separate proxy and adding a security layer on top of the database server.
Human-Machine Interface
User interfaces are designed to enable multiple operations and speed up order and item processing. Grouped data is manipulated by splitting into smaller separate subsections which reference other management modules.
Logistics Support Requirements
System development plans include iterative development process with strong influence by unit testing, integration testing and end-user testing. Releases occur every 4 weeks with 1 week end-user testing. Two months before final release, milestone releases occur in 2 week cycle for faster bug finding and fixing.
The system design can be implemented as separate component parts or even separate layers with common model classes, which discourages programmers, UI designers and prototypers of holding other group back.
System Design
System Components
Component Architecture
Model Repository
Common components, which include models, validators and filters.
Service oriented models provide data abstraction on top of hibernate framework. They are designed not to include any functionality, just to define state and relations between multiple models.
Validators validate input data stored in models against given requirements and provide feedback to attached error observers.
Filters provide easy model navigation by aggregating multiple Filter instances, which accept specific types and decide, whether the anatomy of model describes stated requirements.
Stock Item, Order Management
Commands, Mediators and Views responsible for warehouse management. All forms are managed by Mediators, which are composed of Command instances. Each command is responsible for single action, low coupling of these separate actions ensures testable code and painless maintenance.
Output Transports
Output operations are supported by separate components, which transform input into persisted output (emails, printouts, files).
External Dependencies
Application communication with database is based on high level of abstraction provided by Hibernate framework. Email sending, formatting and email transports are composed from JavaMail external component.
Database Models
Database design consists of one-to-one, one-to-many, many-to-one and many-to-many relations. Table structure provides easy reusability and archivation of item stock events like arrivals, departures, stock-ins, stock-outs, orders.
OOP Class Diagrams
Models
Model classes are based on hibernate entity framework for Java. Relations between them are modelled after Data diagram. Models are typed placeholders for data, they don't contain any functionality or business logic.
Helper classes for persistance management (built on top of hibernate) for decomposing data model classes into their respective providers or proxies.
Almost every user input has to be validated against a set of rules. Validators check model's consistency and report back to their respective observers for more decoupled approach with better maintainability.
Reports
Order reports are based on OrderReportSummary, which is a row collection of required objects. The summary can be processed or exported to selected data format.
Stock Event Reporting is a component, which notifies connected listeners about two standard stock events:
- order is created
- status of order has changed
Listeners act based on their definitions (printing Credit notes or Invoices, emailing customers about their orders)
Filters
Filtering of models is very important operation, which eases user interaction with the system and speeds up whole management.
Filtering is provided by FilterChain, which aggregates Filter instances and retrieves items from input list marked as accepted. Filter components are made as reusable and maintainable as possible for future customer requirements.
Forms
All form classes are modelled after the simplistic MVC pattern enhanced by Mediators, which group Command classes (controllers split in parts) and interact with the View (usually a form instance).
Each Command class is named after the single purpose of its existance (NewOrderCommand, EditDistributorCommand, etc). Commands aggregate other components. If commands of a mediator require shared resource, it can be factored out into respective AbstractCommand class.
Object Diagrams
Relationship between a customer, his order containing two stock items and the warehouse, in which one stock item is stored.
Association of a user (with supplier credential, two emails) and a stock item with specified price.
Component Interactions
Sequence Diagrams
Sequence diagram describes the process of adding a codebook item (suppliers, distributors, forwarders). User needs to fill in the form. Form data are forwarded to Form object. Form object replies by confirmation message and waits for user command. Command object forwards data to Validator object. Validator object response and Command object calls Mediator object in order to proceed additional action. Mediator object replies by final report.
Sequence diagram describes the process of editing a codebook item. User fills in the form. Form data are forwarded to Form object. Form Object replies with confirmation message and waits for user filter command. Filter command object forwards data to Validator object. Validator object responses and filter command object calls Mediator object in order to proceed additional action. Mediator object replies by sending proper codebook items to form object. Form object waits for user reaction. User needs to pick a record to edit. Form data are forwarded to edit command. Edit command object forwards data to Validator object. Validator object responses and filter command object calls Mediator object in order to perform additional action. Mediator object replies with final report.
Collaboration Diagrams
Collaboration diagram describes the process of adding a codebook item.
Collaboration diagram describes the process of editing a codebook item.
Statechart Diagram
Chart describes the states during the lifetime of an order. Placing an order
- First, an order is initialized (e.g. from the GUI).
- Next, all the necessary data of the order (like customer's name, list of products to be shipped, shipping address, billing address, contact information, etc.) are filled in by the operator.
- After filling all the data, the order is saved and marked as ready for further processing
Activity Diagram
Dispatching an order
- After the submission of a certain order to the system, operator can start the dispatching process
- First, the operator checks whether all the products needed for completion of the order are available (e.g. stored in the local warehouse)
- If not, the operator places requests for the missing products to their respective suppliers and the original order is put on halt, awaiting the arrival of the missing goods
- If all the necessary products are available or all the missing ones have arrived, the order is shipped to the customer
If the customer returns the shipment and reclaims the order (order was damaged, parts were missing, etc), the reclamation is processed and then the order is once again sent to the customer.
When the customer finally accepts the shipment, the order is marked as completed.
Interface Characteristics
Internal Interfaces
Layered architecture provides a set of places, where additional components are introduced. Each component implements required interface, to make the compositor functional.
Introduced interfaces for components will actively help in unit testing (easily mockable services) or even in production, when a component will need to be replaced.
External Interfaces
Applications communicates with the user through Graphical User Interface, with prototypes in next chapter. Application provides exports into different formats, which can be discussed during application development and customer requirements.
Concrete classes as credit note or invoice printing are done as stateless components and their behavior will be easily adjusted to final customers needs.
User Interface Prototypes
User interface for Stock item management:
User interface for Stock in management:
User interface for CodeBook management:
