360 likes | 444 Vues
Explore the domain, commonalities, and variabilities of an online shopping cart system for Internet Sellouts LLC, including domain definition, architecture analysis, and enterprise application examples.
E N D
Internet Sellouts Final Presentation Enterprise Architecture Group
Internet Sellouts Presentation Overview • Domain Definition, Commonality Analysis • Architecture Variability Analysis, Example Application • Enterprise Architecture • Reference Applications • What Internet Sellouts LLC is NOT
Domain Definition • Domain: Online Shopping Cart • A set of reusable components and a basic framework in which to build online shopping carts • Framework support product family applications that have a storefront for purchasing goods/services over the Internet • Framework models Buyers, Managers, Authentication, Catalogs, and Orders • Limited Domain Scope: Not B-to-B, Not Do-It-All Business Systems
Commonality Generic Architecture – Identification of set of requirements in common • Identification of actors - Buyer and Manager • Browse a catalog • Fill a shopping cart by selecting items from catalog • Manages shopping cart – update quantity, subtotal prices • Buyers check out – billing and shipping information • Buyers confirm/track orders • Managers CRUD catalogs • Coded Commonality for Requirement and Reusable Asset Tracking
Commonality Traceable and Coded Requirements • C1 Buyer credential verification, authentication • C2 Buyer searches/browses catalog • C3 Buyer builds shopping cart • C4 Buyer manages the shopping cart, and pricing • C5 Buyer checks out – payment, shipping and receipt • C6 Buyer tracks order • C7 Catalog management
Variability • Clients: browser, Java App, Windows App • Catalog CRUD: html, command-line, real-time, batch • Ordering: carrier choices, expediting options, payment options • Authentication: username/PW, App access list, group membership
Domain Architecture • Buyer Client App System • Buyer Controller App System • Client Mgmt Comp System • Catalog Mgmt Comp System • Order Mgmt Comp System • Authorization Mgmt Comp System
Enterprise Use Cases • Buy a product • Track an order • Manage catalogs
Buy a Product • The buyer requests access • If access is restricted, the buyer is authenticated • The buyer selects items to buy • The buyer pays for the items • The system gives the buyer a receipt
Track an Order • The buyer requests access • The buyer provides a tracking number • The system provides the status of the order
Manage Catalogs • Create a catalog use case • Update a catalog use case • Delete a catalog use case
Client Mgmt Use Cases • Authenticate user • Get catalog selection • Get item selections • Get shipping information • Get confirmation • Offer receipt
Catalog Mgmt Use Cases • Select catalog • Add catalog • Update catalog • Drop catalog • Add Items • Update Items • Drop Items
Order Mgmt Use Cases • Price order • Place order • Get order status • Report orders
Authorization Mgmt Use Cases • Confirm member • Add member • Update member • Drop member
Prototypes • An online financing application. • An online merchandise selling application. • An online office supply ordering system.
An Online Financing Application • This system allows clients to select the type of financing product they would like to apply for on a website for mortgage loans, car loans and other types of personal loans. • DIAE Component on Server – 3 components • User Authentication • Product/Service Offering Selections (Inventory) • A Shopping Cart
An Online Financing Application (cont..) • DIAE Component on the Client Side • Package client’s input parameters and communicate with server objects.
An online merchandise selling application • Server side DIAE components • Browse Catalog • Shopping Cart • Authenticate Admin user • Client side components • Admin Interface • Order Status Manager Interface • Catalog Manager Interface
An online office supply ordering system • Client DIAE Components • Client interface (1…n distinct concurrently running entities). • Interact with user. • Shipping interface (1 distinct concurrently running instance) • Add, edit, and delete contents of the inventory. • Read the checked out orders from the database. • Once the order has been filled, delete the entry.
An online office supply ordering system • Server DIAE Components • Session management • Authenticate user login. • Match session id to user credentials. • Determine valid session ids. • Inventory Browser • Provide a list of office supplies available upon valid request. • Filter the list of office supplies based upon search criteria. • Cart Manager • Record the item selections for a specific session. • At checkout, validate session selections against the session’s • user credentials. • At checkout, request office location where to ship the requested supplies. • Store the result of checkout in database. • Relational Database server (provided as COT software) • Store data for the other 3 DIAE server components.
What is the domain? • By now the domain should be relatively clear. • Online, client server • Searchable inventory • Select items to receive • Selected items are validated based upon application specific logic. • Remember the reference applications.
What is NOT in the domain? • Obviously, things that do not meet the criteria previously described • Video games • Word processors • Online message board
More subtly… • Real time vending services. • For example: • Medical supply retrieval. • Juke Box / DJ services • Reasons: • Service to fulfill requested order is not in architecture. • Real time delivery of order not guaranteed.
More subtly (con’t)… • Inventory Management systems. • For example: • Stock management for retail store. • Factory inventory control. • Reasons: • Architecture is designed for browsing the inventory, not managing it. • Administrative interface is not well defined enough to provide enough reuse in these areas.
More subtly (con’t)… • Free Text Data Repository / Knowledge Base • For example: • Internet search engine’s cache • MSDN help • Reasons: • Search of inventory is not optimized for free text searches. • Some of these could be in the domain. • Phone book – Structured data fits architecture.
Adding to the domain. • Application domains close to, but not in, the domain can be added. • The current architecture can be extended. • Will incur additional cost to the customer to properly integrate into the architecture. • Architect and create new reuse assets • Low reuse on these applications