CS551 Component Based Software Development (Chapter 2 of UML)

1. CS551 Component Based Software Development (Chapter 2 of UML) Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu www.sice.umkc.edu/~leeyu CS551 - Lecture 4

2. Component-based Development Process • Requirements • Domain model • System context (Collaboration) • System specification • Scenarios • Type model and Operation specifications • Architecture design • Physical architecture • Logical architecture (Component specification) • Component Internal design • Interface and class specs • Implementation and test CS551 - Lecture 4

3. spec: buyer has received goods from seller, and has paid for them spec: …… Collaboration - Business Model Purchasing purchase Seller return Buyer • Collaboration: a set of related actions between objects • Actions and objects can be business processes and roles • Each action has a specification and model of types CS551 - Lecture 4

4. Refinement order, notify, deliver, pay = purchase Buyer = Buyer Seller = Sales.co = Shipper.co = A/R.co order Sales Buyer notify deliver Shipper pay A/R Business Refinement purchase Seller Buyer • A relation and mapping from a detailed to an abstract description of the same phenomenon CS551 - Lecture 4

5. essential model Business Design: As-is and To-be As-Is • Analyze existing interaction • Extract essential behavior • Do a re-design (refinement) • Framework for use-cases • Many business implications • performance • new functionality • cycle-time • error rate • costs • phased transition plan job test track fix To-Be track dispatch report test fix CS551 - Lecture 4

6. 1. Collaboration 2. Type 3. Collaboration Recursive Process - Software or “World” • A software system is an “object” in the business context • Its internal design will be other collaborating objects CS551 - Lecture 4

7. UML Development Process with Catalysis UML = Unified Modeling Language, standard notation for OO design Requirements Domain Models Understand the business problem, system context and requirements. SystemContext System Specification Scenarios UI Design Describe external behavior of target system using problem domain model Type Model and Op Specs dialog flow, prototype, usability Dictionary Architectural Design Platform, Physical Architecture Partition technical and application architecture components and their connectors to meet design goals Logical Application Architecture DB Design Component Internal Design Interface and Class Specs class mapping, transactions, etc. Design interfaces and classes for each component; build and test Implementation and Test CS551 - Lecture 4

8. SQL Java Global Groceries Focus on the Problem Domain External models should reflect the customer’s view of the problem domain, not the programmer’s view. X A problem domain focus helps to ensure continuity between the software and the real world. • Continuity makes it easier to • verify model with customer • train new developers • estimate maintenance effort • identify sources of defects CS551 - Lecture 4

9. Global Groceries Problem Domain Analysis Problem Domain Analysis - That part of the development process dedicated to developing an understanding of the environment in which a target system will reside as well as the systems role in that environment. Domain Knowledge actor use-case or action shelf • Entities • sales rep… • customer… • discount ... • product… • sale… • Actions • add sales rep… • back-order product... • start sale… Customer Credit Authorization System product discount pay sales rep customer start sale Sales System cash register sale bank card system add sales rep sales rep Head sales rep Mind Map Dictionary System Context CS551 - Lecture 4

10. Global Groceries Mind Map: Informal Problem Domain Model Mind Map - An informal structured representation of a problem domain Not a stored data model!! shelf Clusters - Domain terms representing potential attributes. product price discount percent purchases customer records sale Sales System bank card conducts Arcs (optionally directed and labeled) - Representations of potential associations or collaborations between objects. Nodes - Domain terms representing potential objects, types, or actors. Can include “rich-pictures” as drawings of the problem domain sales rep Can be formalized if appropriate CS551 - Lecture 4

11. System Context -- a Collaboration System Context Model - A structured representation of the collaborations that take place between a system and objects in its surrounding environment (context). Actor - A person, existing system, device, etc. that interacts directly with the target system. Specialization - Indicates that a specialized actor can also play the role of a more general actor. Customer Credit Authorization System pay by bank card Sales Rep start sale add item remove item close sale cancel sale Sales System Target System - The system or component under construction. Use-Case / Action - An interaction between the system and an actor to accomplish a useful unit of work. add authorized sales rep remove authorized sales rep Head sales rep CS551 - Lecture 4

12. total := closeSale() Interactions from system-context actions Scenario of Use Context: A customer approaches a sales rep with the intention of purchasing three watzits using her bank card. There are sufficient funds in her account to payfor the purchase. The sales rep has completed his last sale so there is currentlyno sale in progress. Actors identified from System Context. creditAuthorization System salesSystem Narrative: sales rep customer The sales rep starts a new sale. The total for the sale is $0.00. startSale() The sales rep adds the three watzits to the current sale. addItem(watzit, 3) The sales rep closes the sale. The sales system returns the total due. pay(bankCard, pin) The customer inserts her bank card into the reader and enters her pin number authorized := authorizePayment(bankCard, pin, total) The Sales System requests payment authorization from the credit authorization system. The system authorizes payment. CS551 - Lecture 4

13. System of Interest Model of object types for terms used to specify system operations Not a stored data model Interface Operations of System Type Model and Operation Specs Sales System <<type>> currSale Product inventory * Sale Cust Object type and abstract attribute * * SaleItem quantity Payment Authorization Operation Spec 1 startSale () addItem (Product, quantity) closeSale () pay (bankCard, Pin) Operation Spec 2 Note: Does not as yet commit to operations on individual classes inside system Internal component partitioning and class design not decided yet. CS551 - Lecture 4

14. Architecture: Platform and Physical UI Application Server SQL requests methods> Inventory DB <views SQL requests Customer DB • 3-Tier Architecture • Thin Client: User interface, dialog flow logic • Application Server: Business objects and rules • Oracle Database: Persistent data storage • Must explicitly evaluate technical architecture factors • Scalability, performance, thruput, seats, platform, clustering... Note: 3-Tier could also be a purely logical partition of presentation, business objects, store CS551 - Lecture 4

15. Sales Manager Inventory Manager Sale SaleItem Credit Authorizer Payment Authorization Frequent Buyer Mgr Architecture: Application Components Application Server UI DB Server 1 Product DB Server 2 Customer • Application components partitioned and interactions designed • Partition based on ease of change, re-use, buy Vs. build, etc. • Original domain types split across components, some partly shared CS551 - Lecture 4

16. cross-component transactions DB Server 1 Credit Authorizer Payment Authorization TransactionServer DB Server 2 Architecture: Infrastructure Components Application Server SalesManager Inventory Manager Sale SaleItem Product Frequent Buyer Mgr Customer • Infrastructure component added for transaction management • Appropriate application components “linked” to it CS551 - Lecture 4

17. InventoryManager ISellable Product Component Internal Class Design • Design exposed interfaces of objects visible across components • Design collaborations at exposed interfaces • Design collaborations triggered from exposed interfaces • Design classes to implement exposed interfaces and interactions Sales Manager interface ISellable { Money unitPrice (); void deplete (int quantity); } Sale SaleItem class Product implements ISellable { Money unitPrice () { ...SQL call... } void deplete (int qty) { …SQL call… } } internal interaction scenario CS551 - Lecture 4

18. Mind Map product customer bank card sale Domain Models Reqs System Context Scenarios Spec system Type Model and Op Specs Type Model and Op Specs op1 op2 Platform Physical Architecture Arch a b Logical Application Architecture c Interface and Class Specs Int Des c1 c2 Class and Interface Model, Scenarios a b x y Implementation and Test m1 m2 m3 m4 A Recursive Process: Domain to Code System Context System system c Scenario of Interaction a b c Architectural Collaborations, Interfaces, Scenarios CS551 - Lecture 4

19. find components specialize assemble find components specialize assemble Two Distinct Development Cycles application 2 • Applications • rapidly built solutions • specialize and assemble Assets • Assets = Reusable components • includes source, executable, designs, kits, ... • generalized from multiple application needs • not dreamt-up re-use application 1 Assets find commonality re-factor generalize certify config-manage CS551 - Lecture 4

20. Development Cycle for Applications • Developing Applications • A managed RAD method is usually the most effective • Rapid requirements modeling and prototyping • Short delivery cycles • Close user involvement If I had to live my life again, I'd make the same mistakes, only sooner -- Tallulah Bankhead (1903-1968) CS551 - Lecture 4

21. target target well defined (or moved again) Why Iterative and Incremental? function initial target unclear target better known (or moved) time • Not everything needed is known up front (or at the “end”) • Not everything known is needed up front (or at the “end”) • Frequent iterative and incremental delivery helps function and timeliness CS551 - Lecture 4

22. Development Cycle for Components • Developing Components for re-use justifies investment • Well specified and documented interfaces • Robust against misuse; does not just crash • Generalized for variation points with parameters, “plug-points” • Associated packaging with tests, specs, default “plug-ins”, etc. • Carefully chosen architecture for “kit” of components • More careful certification and configuration management CS551 - Lecture 4

23. Generic Component Re-usable Assets and Variation Points Variation Point - A location at which a generic component may be specialized for use in a particular application. A generic component may come bundled with a set of pre-built variants for some or all of its variation points or the host application may provide its own variants. A variation point may have a default variant. CS551 - Lecture 4

24. Golden Rule of Design Design for change. • Distinct Categories of Change • Modification • Extension • Reuse Open Closed Principle - Ideally a method, class, or component is open to extension but closed to modification. CS551 - Lecture 4