Part 3 Design What does design mean in

  • Slides: 20
Download presentation
Part 3 Design What does design mean in different fields? How important is it?

Part 3 Design What does design mean in different fields? How important is it? What are the methods? Are there patterns you can use? Is it creative? Where does it fit with requirements? Slide 1

Chapter 11: Architectural Design What is architecture? What does an architect do? What skills

Chapter 11: Architectural Design What is architecture? What does an architect do? What skills does an architect have? What does a software architect do? Skills? This will look a lot like systems engineering Can often reuse some of it's results Slide 2

Architectural design: the first step in design From a system perspective, not necessarily a

Architectural design: the first step in design From a system perspective, not necessarily a user perspective Goal: decompose a system into interacting subsystems • • high level: just the subsystems connected by lines better: show subsystems share data and interface with each other Refine by decomposing the subsystems 11. 2 System Organization (identify the pieces) Representative models » repository » client-server » layered Slide 3

11. 2. 1 The repository model Subsystems may exchange data in two ways: •

11. 2. 1 The repository model Subsystems may exchange data in two ways: • • shared data is held in a central database or repository and may be accessed by all subsystems each subsystem maintains its own database and passes data explicitly to other subsystems Repository commonly used for large amounts of shared data Fig 11. 2, CASE toolset : A fairly simple box and line diagram. Strengths? Weaknesses? Slide 4

Repository model characteristics Advantages • • • efficient way to share large amounts of

Repository model characteristics Advantages • • • efficient way to share large amounts of data subsystems need not be concerned with how data is produced centralized management e. g. backup, security, etc. a single sharing model published as the repository schema Disadvantages • • subsystems must agree on a data model--often a compromise data evolution is difficult and expensive no scope for specific management policies difficult to distribute efficiently (How) does the web support this model? Slide 5

11. 2. 2 Client-server architecture Data and processing distributed across a range of components

11. 2. 2 Client-server architecture Data and processing distributed across a range of components • • • servers provide specific services such as printing, data management clients call on these services network allows clients to access servers Film and picture library: Slide 6

Client-server characteristics Advantages • • straightforward data distribution uses networked systems effectively may use

Client-server characteristics Advantages • • straightforward data distribution uses networked systems effectively may use cheap hardware easy to add new servers or upgrade existing servers Disadvantages • • no shared data model so subsystems use different data organization data interchange may be inefficient redundant management in each server it may be hard to find out what servers and services are available Slide 7

11. 2. 3 Layered model Organizes the system into layers (or abstract machines) Each

11. 2. 3 Layered model Organizes the system into layers (or abstract machines) Each layer provides a set of services Supports incremental development in different layers When a layer interface changes, only the adjacent layer is affected It is often difficult to structure systems in this way Is there an example from CS 330? Slide 8

11. 3 Modular decomposition Subsystems are decomposed into modules What models do you know?

11. 3 Modular decomposition Subsystems are decomposed into modules What models do you know? • object model: the system is decomposed into interacting objects • function oriented pipelining: the system is decomposed into functional modules which transform inputs to outputs. Also called data flow models Slide 9

11. 3. 1 Object models A set of loosely coupled objects with well-defined interfaces

11. 3. 1 Object models A set of loosely coupled objects with well-defined interfaces OO decomposition: identify classes, attributes and operations Implementation: create objects from these classes and a control model to coordinate object operations How does this work in C++? Invoice processing system Slide 10

11. 3. 2 Function–oriented pipelining Functional transformations process inputs to produce outputs May be

11. 3. 2 Function–oriented pipelining Functional transformations process inputs to produce outputs May be called a pipe and filter model (e. g. UNIX shell) Not well suited for interactive systems Invoice processing system: Slide 11

11. 4 Control styles (how do the pieces communicate) How control flows between subsystems

11. 4 Control styles (how do the pieces communicate) How control flows between subsystems Distinct from the system decomposition model Centralized control • one subsystem controls/starts/stops other subsystems Event-driven control • each subsystem responds to external events from other subsystems or the system environment Slide 12

11. 4. 1 Centralized control A control subsystem is responsible for managing the execution

11. 4. 1 Centralized control A control subsystem is responsible for managing the execution of other subsystems Call-return model • • top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. usually sequential systems Slide 13

11. 4. 1 Centralized control Manager model • • • applies to concurrent systems

11. 4. 1 Centralized control Manager model • • • applies to concurrent systems one system component controls the stopping, starting and coordination of other system processes. can be implemented in sequential systems as a case statement E. g. this might describe a robot for selecting inventory from a warehouse. Slide 14

11. 4. 2 Event-driven systems Driven by external events whose timing is not controlled

11. 4. 2 Event-driven systems Driven by external events whose timing is not controlled by the subsystems which process the event Two models • • broadcast. An event is broadcast to all subsystems. Any subsystem that can handle the event may do so interrupt-driven. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing Slide 15

Broadcast model Effective for subsystems on different computers in a network Subsystems register an

Broadcast model Effective for subsystems on different computers in a network Subsystems register an interest in specific events. When these occur, the event is transferred to the subsystem to handle it Control policy is embedded in the subsystem, not the event and message handler What broadcast model(s) do you know? Slide 16

Interrupt-driven systems Used in real-time systems for fast response to an event Known interrupt

Interrupt-driven systems Used in real-time systems for fast response to an event Known interrupt types have defined handlers Each interrupt type is associated with a memory location and a hardware switch that causes transfer to its handler Fast response but complex to program and validate Examples you know? Slide 17

11. 5 Reference architectures u u Specific to a domain Generic models (more in

11. 5 Reference architectures u u Specific to a domain Generic models (more in Chapter 13) • • • u abstract from real systems and encapsulate principal characteristics usually bottom up examples: compiler, natural language processing Reference models • • more abstract, idealized derived from study of the application, not existing systems may be a basis for an implementation or to compare systems example: OSI 7 layers Slide 18

Generic example: compiler Slide 19

Generic example: compiler Slide 19

OSI reference model Application Slide 20

OSI reference model Application Slide 20