COMP 6471 Software Design Methodologies

Transcription

1 COMP 647 Software Design Methodologies Fall 20 Dr Greg Butler

2 Course Introduction Course People Course Components What the course is What the course is not The KenKen Game Case Study Larman s Design Process What is OO Analysis and Design Design Pattern Example - Command

3 Course People Instructor: Dr Greg Butler EV3.2 Office Hours: Mondays 6:00 to 7:00 Or by appointment But ask questions in class please TAs: Elias Bou-Harb Labs:???

4 Course Components Lectures: Mondays 7:45 to 20:5 H-603 Assignments: 6, every 2 weeks, worth 60% Quizzes: 2, weeks 6 and 2, worth 40% You must pass the quizzes!!!

5 Course Objectives Software architecture Its role in the software process Its role in software design Software architecture Importance describing/modeling software architecture Common styles of software architecture Layers Especially in web applications

6 Course Objectives Think in Objects Analyze requirements with use cases Create domain models Apply an iterative & agile Unified Process (UP) Relate analysis and design artifacts Read & write highfrequency UML Practice Apply agile modeling Design object solutions Assign responsibilities to objects Design collaborations Design with patterns Design with architectural layers Understand OOP (e.g., Java) mapping issues

7 What the course is: A (second) look at OO design! Software architecture: where global decisions are made! Design process: domain model, use cases, design Emphasis: models, architectural patterns, GRASP principles, design patterns, responsibility, collaboration Closely follows textbook!

8 What the course is not: Not A course in UML, Java You should know the basics of these And become expert (as needed) yourself Not A course in tools: Eclipse, XDE, JUnit You can work through tutorials yourself Not A course in UI design, DB design Not A course in software engineering, software management, software reuse,

9 The Kenken Game Case Study

10 The Kenken Game Case Study

11 The KenKen Game Case Study KenKen for 4-by-4 games and 6-by-6 games Components/Stages ( Last to First): Game UI to let user play, get advice Game automatically/intelligently solve games Game UI to let users play game Game solve games by brute force-and-ignorance (BFI) Generate games ie add arithmetic Generate game layouts

12 Software Architecture Formal definition IEEE Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution

13 Software Architecture Software architecture encompasses the set of significant decisions about the organization of a software system Selection of the structural elements and their interfaces by which a system is composed Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization

14 Software Architecture Perry and Wolf, 992 A set of architectural (or design) elements that have a particular form Boehm et al., 995 A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements Clements et al., 997 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them

15 Common Software Architectures Layered architecture Eg, client-server, 3-tier Model-View-Control architecture Broker Interpreter Pipeline

16 Larman s Design Process Sample UP Artifact Relationships Domain Model Business Modeling date... Sale..* Sales... LineItem... quantity Use Case Model Process Sale inspiration for names of some software domain objects Requirements starting events to design for, and detailed postcondition to satisfy Cashier Process Sale Use Case Diagram Operation: enteritem( ) Post conditions:... Operation Contracts ideas for the postconditions use case names system operations : Register : Cashier. Customer arrives Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System System Sequence Diagrams Design Model functional requirements that must be realized by the objects : ProductCatalog Glossary Supplementary Specification item details, formats, validation non functional requirements domain rules : Sale Design enteritem (itemid, quantity) d = getproductdescription(itemid) addlineitem( d, quantity )... Register makenewsale() enteritem(...)... *... ProductCatalog getproductdescription(...)...

17 Domain Model Pays-for-overdue-charges CashPayment amount : Money Customer address name phonenumber Has Membership Pays-for Initiates Rents-from * Maintains * RentalTransaction date * * Rents VideoStore address name phonenumber Owns-a Catalog..* Stocks * VideoRental duedate returndate returntime ID Records-rental-of Video *..* * 0.. ID startdate..* Described-by LoanPolicy perdayrentalcharge perdaylatecharge..* Defines VideoDescription title subjectcategory..* Determines-rental-charge

18 Use Case Model Partial artifacts, refined in each iteration. Use Case Model :System Requirements text use cases use case diagrams foo( x ) bar( y ) system sequence diagrams system operations system operation contracts

19 Typical Software Architecture Layers! GUI windows B reports B speech interface B HTML, XML, XSLT, JSP, Javascript,... UI (AKA Presentation, View) B B B B B handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation > handles application layer requests > implementation of domain rules > domain services (POS, Inventory) services may be used by just one application, but there is also the possibility of multi application services Application (AKA Workflow, Process, Mediation, App Controller) Domain (AKA Business, Application Logic, Model) dependency more app specific > very general low level business services used in many business domains > CurrencyConverter Business Infrastructure (AKA Low level Business Services) 9 (relatively) high level technical services and frameworks 9 Persistence, Security Technical Services (AKA Technical Infrastructure, High level Technical Services) 9 low level technical services, utilities, and frameworks 9 data structures, threads, math, file, DB, and network I/O Foundation (AKA Core Services, Base Services, Low level Technical Services/Infrastructure) width implies range of applicability

20 Typical Software Architecture Layers (Simplified) UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine

21 What is Design? Developing a blueprint (plan) for a mechanism that performs the required task, taking into account all the constraints, & making trade-offs between constraints when they are in conflict.

22 What is OO Analysis and Design Object-Oriented Analysis Important domain concepts or objects? Vocabulary? Visualized in the UP Domain Model Object-Oriented Design Design of software objects Responsibilities Collaborations Design patterns Visualized in the UP Design Model

23 Important Concepts Model Abstraction hiding (unimportant) details Eg, cover of Larman s book GRASP Principle for assigning responsibility Design pattern Solution to design problem in context Eg, Command pattern

24 Responsibility-Driven Design (RDD) Detailed object design is usually done from the point of view of the metaphor of: Objects have responsibilities Objects collaborate Responsibilities are an abstraction. The responsibility for persistence. Large-grained responsibility. The responsibility for the sales tax calculation. More fine-grained responsibility.

25 The 9 GRASP Principles. Creator 2. Expert 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Protected Variations

26 Overview of Patterns Present solutions to common software problems arising within a certain context Help resolve key software design forces Flexibility Extensibility Dependability Predictability Scalability Efficiency Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs Generally codify expert knowledge of design strategies, constraints & best practices AbstractService service Client Proxy service Service service The Proxy Pattern

27 Command Pattern You have commands that need to be executed, undone, or queued Command design pattern separates Receiver from Invoker from Commands All commands derive from Command and implement do(), undo(), and redo() Also allows recording history, replay