CS 551 Component Based Software Development Chapter 2

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

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 2 CS 551 - Lecture 4

Collaboration - Business Model Purchasing spec: buyer has received goods from seller, and has paid for them purchase Seller Buyer return spec: …… – 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 3 CS 551 - Lecture 4

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

Business Design: As-is and To-be As-Is job test track fix – – essential – model To-Be dispatch report track test fix 5 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 CS 551 - Lecture 4

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

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. System Context System Specification Scenarios Type Model and Op Specs Architectural Design Partition technical and application architecture components and their connectors to meet design goals Interface and Class Specs Design interfaces and classes for each component; build and test Implementation and Test dialog flow, prototype, usability Logical Application Architecture Component Internal Design 7 Platform, Physical Architecture UI Design Dictionary Describe external behavior of target system using problem domain model DB Design CS 551 - Lecture 4 class mapping, transactions, etc.

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

Problem Domain Analysis Global Groceries Domain Knowledge 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. actor shelf product discount customer sale bank card cash register Entities sales rep… customer… discount. . . product… sale… use-case or action Customer pay sales rep start sale Sales System Actions add sales rep… back-order product. . . start sale… system add sales rep Head sales rep Mind Map 9 Credit Authorization System Dictionary CS 551 - Lecture 4 System Context

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

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 pay by bank card Sales Rep start sale add item remove item close sale cancel sale Sales System add authorized sales rep remove authorized sales rep Head sales rep 11 CS 551 - Lecture 4 Credit Authorization 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.

Scenario of Use Actors identified from System 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 pay for the purchase. The sales rep has completed his last sale so there is currently no sale in progress. sales. System Narrative: sales rep customer The sales rep starts a new sale. The total for the sale is $0. 00. start. Sale() The sales rep adds the three watzits to the current sale. add. Item(watzit, 3) The sales rep closes the sale. The sales system returns the total due. total : = close. Sale() The customer inserts her bank card into the reader and enters her pin number The Sales System requests payment authorization from the credit authorization system. The system authorizes payment. 12 credit. Authorization System pay(bank. Card, pin) authorized : = authorize. Payment(bank. Card, pin, total) Interactions from system-context actions CS 551 - Lecture 4

Type Model and Operation Specs System of Interest Sales System <<type>> Object type and abstract attribute Interface Operations of System Product * inventory * * Sale. Item quantity curr. Sale Cust Payment Model of object types for terms used to specify system operations Not a stored data model Authorization start. Sale () add. Item (Product, quantity) close. Sale () pay (bank. Card, Pin) Operation Spec 1 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. 13 CS 551 - Lecture 4

Architecture: Platform and Physical SQL requests methods> UI <views Inventory DB Application Server 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. . . 14 Note: 3 -Tier could also be a purely logical partition of presentation, business objects, store CS 551 - Lecture 4

Architecture: Application Components Application Server Sales Manager UI Sale. Item Inventory Manager Product Credit Authorizer Payment DB Server 1 Authorization Frequent Buyer Mgr 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 15 CS 551 - Lecture 4

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

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 ISellable Inventory Manager Product Sales Manager Sale. Item internal interaction scenario 17 interface ISellable { Money unit. Price (); void deplete (int quantity); } class Product implements ISellable { Money unit. Price () {. . . SQL call. . . } void deplete (int qty) { …SQL call… } } CS 551 - Lecture 4

A Recursive Process: Domain to Code Reqs customer product sale Domain Models Mind Map bank card System Context System Spec system Scenarios c Scenario of Interaction system Type Model and Op Specs a Platform Physical Architecture op 1 op 2 b Arch c Type Model and Op Specs Int Des Logical Application Architecture 18 Architectural Collaborations, Interfaces, Scenarios Interface and Class Specs Implementation and Test a c 1 a m 1 m 2 b c 2 x y m 3 m 4 CS 551 - Lecture 4 Class and Interface Model, Scenarios b c

Two Distinct Development Cycles • 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 19 application 1 find components specialize assemble application 2 find components specialize assemble Assets find commonality re-factor generalize CS 551 - Lecture 4 certify config-manage

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) 20 CS 551 - Lecture 4

Why Iterative and Incremental? initial target unclear function target better known (or moved) target well defined (or moved again) 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 21 CS 551 - Lecture 4

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, “plugpoints” – Associated packaging with tests, specs, default “plugins”, etc. – Carefully chosen architecture for “kit” of components – More careful certification and configuration management 22 CS 551 - Lecture 4

Re-usable Assets and Variation Points Variation Point - A location at which a generic component may be specialized for use in a particular application. Generic Component 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. 23 CS 551 - Lecture 4

Golden Rule of 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. 24 CS 551 - Lecture 4