CEN 4010 Class 15 1018 System Design Overview

  • Slides: 32
Download presentation
CEN 4010 Class 15 – 10/18 System Design • • Overview of System Design

CEN 4010 Class 15 – 10/18 System Design • • Overview of System Design Concepts Software Architecture Overview of Patterns CEN 4010 Class 15 - 10/18

Overview of System Design Products resulting from analysis: § Nonfunctional requirements – constraints on

Overview of System Design Products resulting from analysis: § Nonfunctional requirements – constraints on the system e. g. , max. response time, min. throughput, reliability, OS platform etc. . § Use case model – describing the functionality of the system. § Object model – entities manipulated by the system. § Sequence diagram – sequence of interactions among objects in use case. CEN 4010 Class 15 - 10/18 2

Overview of System Design cont System design results in: • A list of design

Overview of System Design cont System design results in: • A list of design goals that describes qualities of system the developers should optimize. • Software architecture that describes: § subsystem decomposition in terms of responsibilities, dependencies, mapping to h/w, and § major policy decisions such as control flow, access control, and data storage. CEN 4010 Class 15 - 10/18 3

Overview of System Design cont When decomposing the system you must address: • H/w

Overview of System Design cont When decomposing the system you must address: • H/w and s/w mapping: § configuration of system § communication between nodes § services provided by of existing s/w components § encapsulation of components § purchase COTS (Commercial Of The Shelf) components e. g. GUIs, DBMSs CEN 4010 Class 15 - 10/18 4

Overview of System Design cont • Data management § persistence § storage of data

Overview of System Design cont • Data management § persistence § storage of data (location) § accessibility • Access control § authorization § authentication § security CEN 4010 Class 15 - 10/18 5

Overview of System Design cont • Control flow § sequence of operations § type

Overview of System Design cont • Control flow § sequence of operations § type of system – event-driven § concurrency vs. sequential • Boundary conditions § system initialization § system shut down § exceptional conditions (detection and handling) CEN 4010 Class 15 - 10/18 6

System Design Concepts 1. Subsystems and classes: A subsystem is a well defined s/w

System Design Concepts 1. Subsystems and classes: A subsystem is a well defined s/w component that provides a number of services to other subsystems. E. g. , • § storage subsystem - manages persistent data § user interface subsystem – manages the interaction with the user § networking subsystem – manages the communication with other subsystems over the network CEN 4010 Class 15 - 10/18 7

System Design Concepts • A component is a physical and replaceable part of a

System Design Concepts • A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. (Booch et al. ) • Several PLs provide constructs for modeling subsystems: § § § Java – packages C++ - namespaces C – use of directories Ada - ? Pascal - ? CEN 4010 Class 15 - 10/18 8

System Design Concepts cont 2. Services and Subsystems Interfaces • A subsystem is characterized

System Design Concepts cont 2. Services and Subsystems Interfaces • A subsystem is characterized by the services it provide to other subsystems. • A subsystem should provide an interface (subsystem interface) that identifies the operations available to other subsystems. • Specifying the subsystem interface forces the designer to focus on the services provided by the subsystem rather than its implementation. CEN 4010 Class 15 - 10/18 9

System Design Concepts cont • Properties of the subsystem interface: § Provides as little

System Design Concepts cont • Properties of the subsystem interface: § Provides as little information about the implementation as possible. § Minimizes the impact of change when the implementation changes. § Minimizes the dependencies between individual components of different subsystems. CEN 4010 Class 15 - 10/18 10

System Design Concepts cont 3. Coupling and Cohesion • Coupling is the strength of

System Design Concepts cont 3. Coupling and Cohesion • Coupling is the strength of dependencies between subsystems. § Loosely coupled subsystems are relatively independent, i. e. , modifications to one subsystems will have little impact on the other. § If subsystems are strongly couple you might need to rethink you system design. CEN 4010 Class 15 - 10/18 11

System Design Concepts cont • Cohesion is the strength of dependencies within a subsystem.

System Design Concepts cont • Cohesion is the strength of dependencies within a subsystem. § If a subsystem contains many related objects that perform similar tasks its cohesion is high. § If the objects in the subsystem exhibit low cohesion you might want to rethink your system design. • Subsystems should exhibit high coupling and low cohesion. Right ? • Use the 7+/2 rule of concepts at any level of abstraction, i. e. , less than 9 subsystems. CEN 4010 Class 15 - 10/18 12

System Architecture • The software architecture includes the system decomposition, the global control flow,

System Architecture • The software architecture includes the system decomposition, the global control flow, error-handling policies and inter-subsystem communication protocols (Shaw & Garlan ’ 96). • Software architectures: 1. Repository architecture (Blackboard variant) § Subsystems access and modify data from a single data structure called the central repository. § Subsystems interact through the central data structure. CEN 4010 Class 15 - 10/18 13

System Architecture cont Repository Subsystem create. Data() set. Data() get. Data() search. Data() §

System Architecture cont Repository Subsystem create. Data() set. Data() get. Data() search. Data() § Central data flow dictated either by the repository or subsystems (synchronization and locks required) § Example: compiler (P. 239 Fig. 6 -13) Each subsystem depends only on a central data structure, the repository CEN 4010 Class 15 - 10/18 14

System Architecture cont 2. Model/View/Controller (MVC) Controller initiator repository 1 * Model * View

System Architecture cont 2. Model/View/Controller (MVC) Controller initiator repository 1 * Model * View 1 notifier subscriber § Model subsystems – responsible for maintaining domain knowledge. § View subsystems – responsible for displaying information to user. § Controller subsystems – responsible for managing the sequence of interactions with the user. CEN 4010 Class 15 - 10/18 15

System Architecture cont § Changes in the state of the model are propagated to

System Architecture cont § Changes in the state of the model are propagated to the view subsystem via a subscribe/notify protocol. § Special case of repository, where Model implements the central data structure and control objects dictate the control flow. § Document-View variant used in Visual C++ environment – MFC, for developing Windows applications. CEN 4010 Class 15 - 10/18 16

System Architecture cont 3. Client/Server architecture Server Client * * requester provider service 1()

System Architecture cont 3. Client/Server architecture Server Client * * requester provider service 1() service 2() … service. N() § Server subsystem – provides services to instances of other subsystems, clients. § Client subsystem – responsible for interacting with the user. CEN 4010 Class 15 - 10/18 17

System Architecture cont § Request for service usually done via a remote procedure call

System Architecture cont § Request for service usually done via a remote procedure call mechanism or common object broker (e. g. , CORBA or Java RMI). § Control flow in the clients and the servers is independent except for synchronization to manage requests or to receive results. § Example: Unix OS, web servers. CEN 4010 Class 15 - 10/18 18

System Architecture cont 4. Peer-to-peer architecture requester Peer service 1() service 2() … service.

System Architecture cont 4. Peer-to-peer architecture requester Peer service 1() service 2() … service. N() * * provider § Generalization of client/server. § Each subsystem can act as both client and server w. r. t requesting and providing services. Example: a database that accepts request from user and sends notifications to the app. when certain data change. CEN 4010 Class 15 - 10/18 19

System Architecture cont 5. Three-tier architecture Interface Form Application Logic Connection Storage Query •

System Architecture cont 5. Three-tier architecture Interface Form Application Logic Connection Storage Query • Interface layer – includes all boundary objects that deal with the user including windows, forms, web pages etc. . CEN 4010 Class 15 - 10/18 20

System Architecture cont § Application layer – includes all control and entity objects, realizing

System Architecture cont § Application layer – includes all control and entity objects, realizing the processing, rule checking, and notification required by the application. § Storage – realizes storage, retrieval, and query of persistent objects. § Note the separation of between the interface layer and the application layer enables the development or modification of different user interfaces for the same application logic. § Read Four-tier on P. 244 in test. Possible test question!!! CEN 4010 Class 15 - 10/18 21

System Design Concepts cont Example: Systems Support Logging System (SSLS) Problem Defn. 1. 2.

System Design Concepts cont Example: Systems Support Logging System (SSLS) Problem Defn. 1. 2. 3. 4. 5. Develop a software system to log and manage request made by CS users shall submit requests via the web. Each request shall contain at least – a brief description of the problem, the user’s name, user id, location, machine id. The request shall be stored in the SSLS system upon receipt of the request. The systems staff shall respond to the request as soon as possible after receipt and update the stored message as handled. CEN 4010 Class 15 - 10/18 22

System Design Concepts cont Diagram: Subsystem decomposition for the SSLS system <<subsystem>> SSLSUser. Interface

System Design Concepts cont Diagram: Subsystem decomposition for the SSLS system <<subsystem>> SSLSUser. Interface <<subsystem>> Request. Store <<subsystem>> SSLSController CEN 4010 Class 15 - 10/18 23

System Design Concepts cont Diagram: Classes in package Request. Store <<presistent>> Request <<presistent>> Work.

System Design Concepts cont Diagram: Classes in package Request. Store <<presistent>> Request <<presistent>> Work. Request <<presistent>> Completed. Request CEN 4010 Class 15 - 10/18 24

Overview of Patterns • A pattern addresses a recurring design problem that arises in

Overview of Patterns • A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. • An architectural pattern expresses a fundamental structural organization schema for software systems. • A design pattern provides a scheme for refining the subsystems or components of a software system, or relationships between them. • An idiom is a low-level pattern specific to a programming language. CEN 4010 Class 15 - 10/18 25

Pattern Description • Name – name (and aliases) and short summary. • Example –

Pattern Description • Name – name (and aliases) and short summary. • Example – real-world example demonstrating the existence of the problem and the need for the pattern. • Context – the situations in which the pattern may apply. • Problem – the problem the pattern addresses, including a discussion of its associated forces. • Solution - the fundamental solution principle underlying the pattern. CEN 4010 Class 15 - 10/18 26

Pattern Description cont • Structure – A detailed specification of the structural aspects of

Pattern Description cont • Structure – A detailed specification of the structural aspects of the pattern. • Dynamics – typical scenarios describing the run -time behavior of the pattern. • Implementation – guidelines for implementing the pattern. • Variants – a brief description of variants or specialization of a pattern. • Known uses • Consequences – pros and cons. CEN 4010 Class 15 - 10/18 27

Pattern Example • Name - Pipe and Filter (architectural pattern) • Summary – provides

Pattern Example • Name - Pipe and Filter (architectural pattern) • Summary – provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. • Example – complier. • Context – Processing data streams. • Problem – You are building a system that must process or transform a stream of input data. Implementing such a system as a single component may not be feasible for several reasons: CEN 4010 Class 15 - 10/18 28

Pattern Example cont – the system has to be built by several developers, –

Pattern Example cont – the system has to be built by several developers, – the global system tasks decomposes naturally into several processing stages, – the requirements are likely to change. • Solution – The Pipe and Filter architectural patterns divides the task of a system into several processing steps. – These steps are connected by the data flow through the system – the output data of a step is the input to the subsequent step. – Each processing step is implemented by a filter component. CEN 4010 Class 15 - 10/18 29

Pattern Example cont – A filter consumes and delivers data incrementally to achieve low

Pattern Example cont – A filter consumes and delivers data incrementally to achieve low latency and enable real parallel processing. – The input to the system is provided by a data source such as a text file. – The output flows into a data sink such as a file, terminal, animation program etc. . – The data source, the filters and the data sink are connected sequentially by pipes. – Each pipe implements the data flow between adjacent processing steps. – The sequence of filters combined by pipes is called a processing pipeline. CEN 4010 Class 15 - 10/18 30

Pattern Example cont • Structure Class Filter Responsibility • Gets input data • Performs

Pattern Example cont • Structure Class Filter Responsibility • Gets input data • Performs a function on its data. • Supplies output data. Collaborators • Pipe Class Collaborators Data Source • Pipe Responsibility • Delivers input to processing pipeline. Class Pipe Responsibility • Transfers data. • Buffers data. • Synchronizes active neighbors. Class Data Sink Responsibility • Consumes output CEN 4010 Class 15 - 10/18 Collaborators • Data Source • Data Sink • Filter Collaborators • Pipe 31

Pattern Example cont • Scenarios – (give an example use case) • Implementation –

Pattern Example cont • Scenarios – (give an example use case) • Implementation – • Variants – Tee and join systems i. e. , filters with more than one input and/or more than one output. • Known uses – UNIX, CMS Pipelines (IBM OS) • Consequences Benefits: – No intermediate files necessary, but possible. – Flexibility by filter exchange. CEN 4010 Class 15 - 10/18 32