1 / 36

Internet Sellouts

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.

kalona
Download Presentation

Internet Sellouts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Sellouts Final Presentation Enterprise Architecture Group

  2. Internet Sellouts Presentation Overview • Domain Definition, Commonality Analysis • Architecture Variability Analysis, Example Application • Enterprise Architecture • Reference Applications • What Internet Sellouts LLC is NOT

  3. 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

  4. 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

  5. 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

  6. 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

  7. Domain Architecture

  8. 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

  9. Enterprise Use Cases • Buy a product • Track an order • Manage catalogs

  10. 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

  11. Track an Order • The buyer requests access • The buyer provides a tracking number • The system provides the status of the order

  12. Manage Catalogs • Create a catalog use case • Update a catalog use case • Delete a catalog use case

  13. Client Mgmt Use Cases • Authenticate user • Get catalog selection • Get item selections • Get shipping information • Get confirmation • Offer receipt

  14. Client Mgmt Facade

  15. Catalog Mgmt Use Cases • Select catalog • Add catalog • Update catalog • Drop catalog • Add Items • Update Items • Drop Items

  16. Catalog Mgmt Facade

  17. Order Mgmt Use Cases • Price order • Place order • Get order status • Report orders

  18. Order Mgmt Facade

  19. Authorization Mgmt Use Cases • Confirm member • Add member • Update member • Drop member

  20. Authorization Mgmt Facade

  21. Reference Applications

  22. Prototypes • An online financing application. • An online merchandise selling application. • An online office supply ordering system.

  23. 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

  24. An Online Financing Application (cont..) • DIAE Component on the Client Side • Package client’s input parameters and communicate with server objects.

  25. 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

  26. 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.

  27. 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.

  28. Identifying the Domain

  29. 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.

  30. What is NOT in the domain? • Obviously, things that do not meet the criteria previously described • Video games • Word processors • Online message board

  31. 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.

  32. 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.

  33. 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.

  34. 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

More Related