Object-Oriented Design Layers. 2 Layering Mechanisms Introduction to layering design principles Introduction to layering design principles Determining.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

Software Requirements Engineering
SS ZG653Second Semester Topic Architectural Patterns – Review of Patterns.
ECE 526 – Network Processing Systems Design Software-based Protocol Processing Chapter 7: D. E. Comer.
Page 1 Building Reliable Component-based Systems Chapter 7 - Role-Based Component Engineering Chapter 7 Role-Based Component Engineering.
Component-Level Design
Software Architecture Design Instructor: Dr. Jerry Gao.
1 SYSTEM and MODULE DESIGN Elements and Definitions.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
1 Objectives To introduces the concept of software Design. To introduce the concept of Object- Oriented Design (OOD). To Define various aspects about object.
SWE Introduction to Software Engineering
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
Establishing the overall structure of a software system
December 9, 2001Architectural Design, ECEN Architecture – Layers, in particular ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs University of.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Chapter 22 Object-Oriented Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
System Design Decomposing the System. Sequence diagram changes UML 2.x specifications tells that Sequence diagrams now support if-conditions, loops and.
Chapter 6: Architectural Design
What is it? A mobile robotics system controls a manned or partially manned vehicle-car, submarine, space vehicle | Website for Students.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
OO Frameworks Department of Computer Science Kent State University.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
CS451 Lecture 13: Architectural Design Chapter 10
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13Slide 1 Architectural Design u Establishing the overall structure of a software system.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
An Introduction to Software Architecture
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
Case Studies on Design Patterns Design Refinements Examples.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Styles.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
 Repository Model  Client-Server Model  Layered Model  Modular decomposition styles  Object Models  Function Oriented Pipelining  Control Styles.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
Distributed Information Systems. Motivation ● To understand the problems that Web services try to solve it is helpful to understand how distributed information.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1 after designing to meet functional requirements, design the system.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 13. Review Shared Data Software Architectures – Black board Style architecture.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Chapter 7: Architectural Design Chapter 11 in textbook 1.
Lecture 18: Object-Oriented Design
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
Layered Systems Rahul Nabar CS 551 Fall ’02. Layered or Hierarchical Designs A layered system is organized hierarchically, each layer providing service.
E81 CSE 532S: Advanced Multi-Paradigm Software Development Venkita Subramonian, Christopher Gill, Ying Huang, Marc Sentany Department of Computer Science.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 15. Review Interaction-Oriented Software Architectures – MVC.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Layers Architecture Pattern Source: Pattern-Oriented Software Architecture, Vol. 1, Buschmann, et al.
Basic Characteristics of Object-Oriented Systems
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Software Connectors. What is a Software Connector? 2 What is Connector? – Architectural element that models Interactions among components Rules that govern.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Software Design and Architecture
Analysis models and design models
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Presentation transcript:

Object-Oriented Design Layers

2 Layering Mechanisms Introduction to layering design principles Introduction to layering design principles Determining when to use layers Determining when to use layers The attention points when layering The attention points when layering Layering and PAC model Layering and PAC model

3 Object-Oriented Design Layered Systems Hierarchically organised Hierarchically organised A layer provides services to layer(s) above it A layer provides services to layer(s) above it A layer is a client to layer(s) below it A layer is a client to layer(s) below it Possible topological constraints (opaqueness) Possible topological constraints (opaqueness) Limit interactions between adjacent layers Limit interactions between adjacent layers

4 Object-Oriented Design Examples of layered Systems Layered communication protocols (e.g. OSI) Layered communication protocols (e.g. OSI) OS kernels (e.g. Windows, Chorus) OS kernels (e.g. Windows, Chorus) Database systems (e.g. ANSI/SPARC) Database systems (e.g. ANSI/SPARC) Many commercial apps use layers model Many commercial apps use layers model The agents in a PAC model! The agents in a PAC model!

5 Object-Oriented Design Generic OS Environment User-visible elements (layer 6) User-visible elements (layer 6) Specific application modules (layer 5) Specific application modules (layer 5) Common services level (layer 4) Common services level (layer 4) OS interface level (layer 3) OS interface level (layer 3) OS (may itself be layered) (layer 2) OS (may itself be layered) (layer 2) Hardware (layer 1) Hardware (layer 1)

6 Object-Oriented Design Typical Layers Regime

7 Object-Oriented Design Reasons for layered Systems Support designs based in increasing levels of abstraction Support designs based in increasing levels of abstraction Can partition a problem into smaller pieces Can partition a problem into smaller pieces Changes to a layer affect only a few layers Changes to a layer affect only a few layers Layers can be used interchangeably Layers can be used interchangeably Reuse is supported Reuse is supported

8 Object-Oriented Design Implementing layered Systems We use Buschmann’s Layers pattern We use Buschmann’s Layers pattern Iterative process in general (‘yo-yo’) Iterative process in general (‘yo-yo’) Approximately 10 steps Approximately 10 steps Other (Gamma) patterns may be used Other (Gamma) patterns may be used Approach is reusable (RT UML, component technology) Approach is reusable (RT UML, component technology)

9 Object-Oriented Design Some Definitions A task is a responsibility of a given layer A task is a responsibility of a given layer A service is a set of functions offered by a layer A service is a set of functions offered by a layer We speak of service layering We speak of service layering Each layer has interface functions Each layer has interface functions A layer can be implemented as a Black Box or White Box A layer can be implemented as a Black Box or White Box

10 Object-Oriented Design More on Services Each layer can be viewed as a virtual machine Each layer can be viewed as a virtual machine A service is a programmable facility of a virtual machine A service is a programmable facility of a virtual machine Examples of services: DB, comm, UI Examples of services: DB, comm, UI

11 Object-Oriented Design What is ‘inside’ a Layer? A layer populated by modules (e.g. objects) A layer populated by modules (e.g. objects) Determine how to access module interfaces Determine how to access module interfaces Two main possibilities Two main possibilities 1: ability to access all objects (White Box) 1: ability to access all objects (White Box) 2: create a ‘contact’ for all modules (Black Box) 2: create a ‘contact’ for all modules (Black Box)

12 Object-Oriented Design Layer N is a black box for layer N + 1 Layer N is a black box for layer N + 1 Design a flat interface that offers layer N’s services Design a flat interface that offers layer N’s services This can be achieved by the Façade pattern This can be achieved by the Façade pattern Necessitates introduction of a Façade object Necessitates introduction of a Façade object What is a Black Box?

13 Object-Oriented Design Consequences of Black Box Approach Supports system evolution Supports system evolution Can support multiple interface implementations (see Bridge pattern) Can support multiple interface implementations (see Bridge pattern) May not be the most efficient approach May not be the most efficient approach Adds to project time Adds to project time

14 Object-Oriented Design What is a White Box? Layer N + 1 sees internals of layer N Layer N + 1 sees internals of layer N Upper layer may access modules in layer N Upper layer may access modules in layer N Introduces explicit coupling Introduces explicit coupling Compromise: ‘gray’ box Compromise: ‘gray’ box

15 Object-Oriented Design What is a Gray Box? Something between White and Black! Something between White and Black! Layer N + 1 knows number of components in layer N Layer N + 1 knows number of components in layer N Each component is addressed separately Each component is addressed separately However, it does not know about component internals However, it does not know about component internals

16 Object-Oriented Design Consequences of White Box Approach Relatively easy to implement Relatively easy to implement Incremental development Incremental development Large maintenance costs Large maintenance costs Low reusability levels Low reusability levels

17 Object-Oriented Design Levels of Information Hiding

18 Object-Oriented Design Layers: Steps Part I 1:Determine abstraction criteria for task grouping 1:Determine abstraction criteria for task grouping 2:Determine the number of abstraction levels 2:Determine the number of abstraction levels 3:Name layers and assign tasks to them 3:Name layers and assign tasks to them 4:Specify layers’ services 4:Specify layers’ services 5:Refine the layering 5:Refine the layering

19 Object-Oriented Design Abstraction Criteria Most difficult step during layering process Most difficult step during layering process Determine the different tasks Determine the different tasks Then groups tasks into layers Then groups tasks into layers Iterative process Iterative process OOA use cases are of help here OOA use cases are of help here

20 Object-Oriented Design Example PAC Model Three layers and three major tasks Three layers and three major tasks Task 1: Interactions with external environment Task 1: Interactions with external environment Task 2: Business objects and logic management Task 2: Business objects and logic management Task 3: Communication with other agents Task 3: Communication with other agents

21 Object-Oriented Design Number of Abstraction Levels Each abstraction level corresponds to 1 layer Each abstraction level corresponds to 1 layer Can split a layer into 2 layers Can split a layer into 2 layers Layers can be combined Layers can be combined Associated advantages and disadvantages Associated advantages and disadvantages

22 Object-Oriented Design Example PAC Three layers (P, A, C) Three layers (P, A, C) Correspond to UML (B,E,C) pattern Correspond to UML (B,E,C) pattern Sufficient regime for many applications Sufficient regime for many applications In some cases we can split A into 2 layers In some cases we can split A into 2 layers Then get a 4-layer regime Then get a 4-layer regime

23 Object-Oriented Design Layers Names and Responsibilities Highest layer is overall system task Highest layer is overall system task Other tasks are ‘helpers’ Other tasks are ‘helpers’ Lower layers provide an ‘infrastructure’ Lower layers provide an ‘infrastructure’ Higher layers use services of lower layers Higher layers use services of lower layers Demands experience and foresight Demands experience and foresight

24 Object-Oriented Design Example PAC Layer 1: SensorUnit (interaction with environment) Layer 1: SensorUnit (interaction with environment) Layer 2: ModelledEntity (objects of interest) Layer 2: ModelledEntity (objects of interest) Layer 3: Controller (dispatching/notification) Layer 3: Controller (dispatching/notification)

25 Object-Oriented Design Services of Layers High-level description of what a layer offers to upper layers High-level description of what a layer offers to upper layers Keep services distinct Keep services distinct Locate more services in higher layers Locate more services in higher layers This reduces programmer ‘cognitive overload’ This reduces programmer ‘cognitive overload’

26 Object-Oriented Design Layer Refinement Iterate over steps 1 to 4 Iterate over steps 1 to 4 Combination of top-down and bottom-up approaches Combination of top-down and bottom-up approaches Be careful not to destroy strict layering Be careful not to destroy strict layering

27 Object-Oriented Design Example Moving from PAC to Agent Technology Agent technology uses a number of layered models Agent technology uses a number of layered models Can be seen as an extension of the OO model Can be seen as an extension of the OO model A 4-layer regime is common A 4-layer regime is common

28 Object-Oriented Design Prototypical 4-layer Model Level 1:World interface layer (sensors) Level 1:World interface layer (sensors) Level 2:Behavioural layer (reactive objects) Level 2:Behavioural layer (reactive objects) Level 3:Planning layer (algorithms, proactive objects) Level 3:Planning layer (algorithms, proactive objects) Level 4:Communication layer (group planning, communication with other agents) Level 4:Communication layer (group planning, communication with other agents)

29 Object-Oriented Design Layers: Steps Part II 6: Specify an interface for each layer 6: Specify an interface for each layer 7: Structure individual layers 7: Structure individual layers 8: Specify communication between layers 8: Specify communication between layers 9: Decouple adjacent layers 9: Decouple adjacent layers 10: Design an error-handling strategy 10: Design an error-handling strategy

30 Object-Oriented Design Layer Interfaces Problem of finding interfaces for each layer Problem of finding interfaces for each layer Differences for white, black and gray boxes Differences for white, black and gray boxes Sequence diagrams help here Sequence diagrams help here Possible to define and discover standard interfaces Possible to define and discover standard interfaces

31 Object-Oriented Design Layer Structure Objective is to structure the internals of each layer Objective is to structure the internals of each layer Break a layer into finer components Break a layer into finer components Gamma patterns are useful at this level Gamma patterns are useful at this level Finer-grained structures Finer-grained structures

32 Object-Oriented Design Example PAC Bridge: support multiple implementations of a layer interface Bridge: support multiple implementations of a layer interface Composite: complex aggregate objects Composite: complex aggregate objects Strategy: dynamic interchange of algorithms in a layer Strategy: dynamic interchange of algorithms in a layer State: implementing state machines in an object State: implementing state machines in an object

33 Object-Oriented Design Using Bridges in Layers

34 Object-Oriented Design Inter-layer Communication Determines how layers exchange information Determines how layers exchange information Precondition is that they ‘know’ each other in some way Precondition is that they ‘know’ each other in some way Choice depends on a number of factors Choice depends on a number of factors

35 Object-Oriented Design Determining the best Choice Loose coupling (callbacks, implicit invocation) Loose coupling (callbacks, implicit invocation) Efficiency (peer-to-peer model) Efficiency (peer-to-peer model) Ability to switch at configuration time or run-time Ability to switch at configuration time or run-time

36 Object-Oriented Design Decouple adjacent Layers Optimisation step, many options Optimisation step, many options Two-way or one-way coupling Two-way or one-way coupling Callbacks help one-way coupling Callbacks help one-way coupling Use of C++ abstract classes Use of C++ abstract classes Use of Bridge pattern Use of Bridge pattern

37 Object-Oriented Design Error-handling Strategy Really a separate design/analysis issue Really a separate design/analysis issue Has a major performance impact on layered systems Has a major performance impact on layered systems Handle error in current layer or hand it off to next layer? Handle error in current layer or hand it off to next layer? Rule: handle errors at lowest possible layer Rule: handle errors at lowest possible layer

38 Object-Oriented Design Example PAC P: hardware errors (no response, heavy response) P: hardware errors (no response, heavy response) A: emergency requests A: emergency requests C: notification errors C: notification errors

39 Object-Oriented Design Advantages of Layering Reuse of layers Reuse of layers Support for standardisation Support for standardisation Dependencies are kept local Dependencies are kept local Exchangeability of layers (via Bridge) Exchangeability of layers (via Bridge)

40 Object-Oriented Design Disadvantages of Layering Cascades of changing behaviour Cascades of changing behaviour Lower efficiency Lower efficiency Unnecessary work Unnecessary work Correct granularity of layers. What is it? Correct granularity of layers. What is it?

41 Object-Oriented Design Layering and PAC: last Remarks Similarities (levels of increasing abstraction) Similarities (levels of increasing abstraction) PAC structure is a tree of PAC nodes PAC structure is a tree of PAC nodes Layers is a vertical line of nodes Layers is a vertical line of nodes Each PAC node consists of three components Each PAC node consists of three components Layers does not prescribe how many layers to create Layers does not prescribe how many layers to create

42 Object-Oriented Design Example Steam-Boiler Problem Well-known prototype problem Well-known prototype problem Objective here is to show how layers are implemented Objective here is to show how layers are implemented Knowing what was done allows us to improve the code quality and flexibility Knowing what was done allows us to improve the code quality and flexibility Three layers in general (based on PAC) Three layers in general (based on PAC) We concentrate on Delivery agent We concentrate on Delivery agent

43 Object-Oriented Design Delivery Responsible for producing heat and cold Responsible for producing heat and cold Realised by physical actuators Realised by physical actuators Knows about provision of services Knows about provision of services 3-layer agent 3-layer agent

44 Object-Oriented Design Abstraction Criteria Desire to distance system from physical hardware Desire to distance system from physical hardware Locate interactions with hardware in one layer Locate interactions with hardware in one layer Another layer knows what service is needed and what it can provide Another layer knows what service is needed and what it can provide Upper layer is responsible for communi- cating results and acknowledgements Upper layer is responsible for communi- cating results and acknowledgements

45 Object-Oriented Design Layer Names and Tasks Delivery: 2-way dispatching/notification Delivery: 2-way dispatching/notification ActuatorUnit: current service needs and resources ActuatorUnit: current service needs and resources Actuators: Physical heating/cooling units Actuators: Physical heating/cooling units Names can be generalised (later) Names can be generalised (later)

46 Object-Oriented Design Services Each layer provides services to upper layer Each layer provides services to upper layer Define service-access points (SAPs) and service provision points (SPPs) Define service-access points (SAPs) and service provision points (SPPs) SAP and SPP are closely related SAP and SPP are closely related SAP is ‘upper’ part, SPP is ‘lower’ part SAP is ‘upper’ part, SPP is ‘lower’ part SAP and SPP ensure that layers are uncoupled SAP and SPP ensure that layers are uncoupled

47 Object-Oriented Design Services ActuatorControl: heat and cold regulation levels ActuatorControl: heat and cold regulation levels Actuators: heat and cold regulation Actuators: heat and cold regulation Delivery: service requests Delivery: service requests No layer refinement No layer refinement

48 Object-Oriented Design Interfaces for Layers C++ used C++ used Interface functions based on sequence diagrams Interface functions based on sequence diagrams White box approach White box approach Tight coupling between layers (call and return mechanism) Tight coupling between layers (call and return mechanism)

49 Object-Oriented Design Inter-layer communication Realised by function calls Realised by function calls Layers know address of upper and lower neighbours Layers know address of upper and lower neighbours Return and call: all action starts in Mediator Return and call: all action starts in Mediator We can call it a pull model We can call it a pull model

50 Object-Oriented Design Decoupling Layers Not done in this version of the software Not done in this version of the software Use of C++ inheritance and Event classes enhances loose coupling Use of C++ inheritance and Event classes enhances loose coupling use Command pattern to pass functions from layer to layer use Command pattern to pass functions from layer to layer

51 Object-Oriented Design Error Handling All events (including errors) are modelled by Event classes All events (including errors) are modelled by Event classes Specialised events per agent Specialised events per agent All handling takes place in Mediator All handling takes place in Mediator Centralised control (more dependencies) Centralised control (more dependencies)

52 Object-Oriented Design Example Financial Services Architecture Provides access to financial services from an application Provides access to financial services from an application Ability to communicate with various service providers Ability to communicate with various service providers Precondition: no code change Precondition: no code change

53 Object-Oriented Design Architecture 3 main layers 3 main layers XFS API: used by application XFS API: used by application XFS SPI: interfaces to specific service providers XFS SPI: interfaces to specific service providers XFS Manager: maps API calls to appropriate service provider XFS Manager: maps API calls to appropriate service provider

54 Object-Oriented Design XFS Architecture

55 Object-Oriented Design Remarks on Communication API calls can be synchronous or asynchronous API calls can be synchronous or asynchronous SPI calls are always asynchronous SPI calls are always asynchronous Service provider entry point is always local Service provider entry point is always local Device or service (final target) may be remote Device or service (final target) may be remote

56 Object-Oriented Design Responsibilities of Service Providers Translate generic service requests to service-specific requests Translate generic service requests to service-specific requests Request routing Request routing Arbitrate access by multiple apps to a single service or device Arbitrate access by multiple apps to a single service or device Manage hardware interfaces to services or devices Manage hardware interfaces to services or devices Manage asynchronous nature of services and devices Manage asynchronous nature of services and devices

57 Object-Oriented Design API Functions Basic: StartUp/CleanUp, Open/Close, Lock/Unlock Basic: StartUp/CleanUp, Open/Close, Lock/Unlock Administration functions (e.g. device init) Administration functions (e.g. device init) Specific commands (e.g. request device/service-specific functions) Specific commands (e.g. request device/service-specific functions) SPI functions kept as close as possible to API functions SPI functions kept as close as possible to API functions