Object Oriented Analysis and Design Logical Architecture

Transcription

1 Object Oriented Analysis and Design Logical Architecture Matthew Dailey Computer Science and Information Management Asian Institute of Technology Matthew Dailey (CSIM-AIT) Architecture 1 / 24

2 Readings Readings for these lecture notes: - Larman (2005), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Chapter 13. Some material c Larman (2005). Matthew Dailey (CSIM-AIT) Architecture 2 / 24

3 Outline 1 Introduction 2 Layering Pattern 3 Wrap-Up Matthew Dailey (CSIM-AIT) Architecture 3 / 24

4 Introduction Start with the big picture Design is another major discipline of the UP elaboration phase. To get started on design, we need the big picture or high-level organization for the software. Here we consider the logical architecture that describes the high-level organization of the system. Later we drill down to design the application logic (aka domain logic) layer. Matthew Dailey (CSIM-AIT) Architecture 4 / 24

5 Introduction Getting started The logical architecture organizes the major subsystems without committing to a particular deployment. The Software Architecture document is created during elaboration and will be baselined by the end of elaboration. Logical architecture design begins with a consideration of an constraints and non-functional requirements in the supplementary specification. Matthew Dailey (CSIM-AIT) Architecture 5 / 24

6 Introduction Logical architecture relationships Sample UP Artifact Relationships Business Modeling Domain Model * * Requirements Use-Case Model Vision Supplementary Specification Glossary The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Design Model package diagrams UI of the logical architecture (a static view) Domain Tech Services : Register : ProductCatalog Design interaction diagrams (a dynamic view) enteritem (itemid, quantity) spec = getproductspec( itemid ) Register ProductCatalog class diagrams (a static view)... makenewsale() enteritem(...) getproductspec(...)... Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 6 / 24

7 Outline 1 Introduction 2 Layering Pattern 3 Wrap-Up Matthew Dailey (CSIM-AIT) Architecture 7 / 24

8 Characteristics Most applications (especially enterprise applications) use the layering pattern: Subsystems are organized into coarse-grained groups Responsibilities within each layer are strongly related to each other Each layer may depends on the layers (relaxed layering) or layer (strict layering) below it. There are no upward dependencies. Matthew Dailey (CSIM-AIT) Architecture 8 / 24

9 Example UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 9 / 24

10 Typical layers Typical layers: UI (thick client, Web, remote) Application logic and domain objects Technical services (persistence, logging, etc.) Matthew Dailey (CSIM-AIT) Architecture 10 / 24

11 UML packages for layers In UML, layers are represented by packages. Unlike Java packages or C++ namespaces, UML packages can contain anything. UI Domain Swing Web Sales UI UI::Swing UI::Web Domain::Sales Swing Web Domain Sales Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 11 / 24

12 Why layers? Why layers? Coupling is reduced Application logic is well separated from user interface. General purpose business logic can be separated from application specific logic. Development activities can proceed with clear responsibilities Matthew Dailey (CSIM-AIT) Architecture 12 / 24

13 Typical informations system layers Typical layers in an information system: GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript,... UI (AKA Presentation, View) 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) (relatively) high-level technical services and frameworks Persistence, Security Technical Services (AKA Technical Infrastructure, High-level Technical Services) low-level technical services, utilities, and frameworks 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 Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 13 / 24

14 Layers and package naming conventions Packages should be named consistently with nesting by layer to allow reverse engineering of the layer structure, e.g.: // --- UI Layer com.mycompany.nextgen.ui.swing com.mycompany.nextgen.ui.web // --- DOMAIN layer com.mycompany.nextgen.domain.sales com.mycompany.nextgen.domain.payments // --- TECHNICAL SERVICES Layer // home-grown services com.mycompany.services.persistence // third-party services org.apache.log4j org.apache.soap.rpc // --- FOUNDATION Layer // foundation packages that our team creates com.mycompany.util Matthew Dailey (CSIM-AIT) Architecture 14 / 24

15 The domain layer Our focus for this course is the application logic layer aka the domain layer. The key to object-oriented design We begin design using the domain objects in the analysis model. This leads to a lower representational gap between the real world and the software design. Matthew Dailey (CSIM-AIT) Architecture 15 / 24

16 Domain model and domain layer The domain model and the domain layer are related. Example: UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount Payment amount: Money getbalance(): Money 1 Pays-for 1 inspires objects and names in 1 1 Pays-for date time Sale Sale date: Date starttime: Time gettotal(): Money... Domain layer of the architecture in the UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered. Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 16 / 24

17 Layers and partitions Within each layer we have horizontal partitions. Domain POS Inventory Tax Vertical Layers Technical Services Persistence Security Logging Horizontal Partitions Larman (2005), Fig Avoid the word tier in a logical architecture as it usually refers to deployment. Matthew Dailey (CSIM-AIT) Architecture 17 / 24

18 Use the right view Avoid allowing deployment views to creep into your logical architecture views: Worse mixes logical and deployment views Domain(s) Technical Services POS Better a logical view Domain(s) Technical Services Inventory a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database. Foundation Persistence Naming and Directory Services Web AppFramework MySQL Inventory «component» Novell LDAP Foundation UML notation: A UML component, or replaceable, modular part of the physical system UML notation: A physical database in the UML. Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 18 / 24

19 MVC and layers The Model-View Controller pattern separates model objects in the domain layer from view objects in the UI layer. View objects use the Observer pattern to register for notification of model object events (e.g. state changes). The Observer pattern allows the model to inform the view of changes and other events without coupling. (See next slide for the pattern...) Matthew Dailey (CSIM-AIT) Architecture 19 / 24

20 Observer pattern Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 20 / 24

21 UI layer Domain layer interface UI layer Domain layer interface The messages sent from the UI to the domain layer should be exactly the system-level events discovered during SSD analysis. Matthew Dailey (CSIM-AIT) Architecture 21 / 24

22 UI-Domain layer interface design from SSD analysis Example interface derived from SSD analysis: UI :System : Cashier makenewsale() enteritem(id, quantity) description, total Domain Swing... ProcessSale Frame makenewsale() enteritem() endsale() makenewsale() enteritem() endsale() : Cashier endsale()... Register makenewsale() enteritem()... the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer Larman (2005), Fig Matthew Dailey (CSIM-AIT) Architecture 22 / 24

23 Outline 1 Introduction 2 Layering Pattern 3 Wrap-Up Matthew Dailey (CSIM-AIT) Architecture 23 / 24

24 Wrap-Up Package diagrams BOUML makes it easy to create package diagrams. Create the package hierarchy in the explorer view, then drag the packages you want to display to the diagram panel. For the pineapple farm information system project, we might begin with a standard layering and plan to refine later. Matthew Dailey (CSIM-AIT) Architecture 24 / 24