Modern methods in Software Engineering System …misha/ID2207/2014/lectures/Syste… · · 2014-09-15Modern methods in Software Engineering ... Using UML, Patterns, and Java 34

Modern methods in Software Engineering

System Design

www.imit.kth.se/courses/2G1522

1

Literature used

•  Text Book Chapters 6 and 7

2

Content Overview of System Design Activities:

1. Design Goals 2. Subsystem Decomposition 3. Other activities Hardware/Software Mapping Persistent Data Management Global Resource Handling and Access Control Software Control Boundary Conditions

3

Design

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”

- C.A.R. Hoare

4

Analysis & Design •  Analysis: Focuses on the application domain •  Design: Focuses on the solution domain

–  Design knowledge is a moving target –  The reasons for design decisions are changing very

rapidly •  Halftime updating knowledge in solution domain: About 3-5

years •  Cost of hardware rapidly sinking

•  “Design window”: –  Time in which design decisions have to be made

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

5

System Design Activities

System design

Object design

object design model

design goals

subsystem decomposition

Analysis

analysis object model

dynamic model

nonfunctional requirements


6

System Design

2. System

Layers/Partitions Cohesion/Coupling

5. Data

1. Design Goals Defi nition

T rade-of fs

4. Hardware/

Special purpose

Software e

Buy or Build Trade-off Allocation Connectivity

3. Concurrency

Data structure

Persistent Objects Databases

Management Access control Security

6. Global Resource Handling

8. Boundary Conditions

Initialization T ermination Failure

Decomposition

Mapping

7. Software Control

Identification of Threads of control

Monolithic Event-Driven Threads Conc. Processes


7

How to use the results from the Requirements Analysis for System Design

•  Nonfunctional requirements => –  Activity 1: Design Goals Definition

•  Functional model => –  Activity 2: System decomposition (Selection of

subsystems based on functional requirements, cohesion, and coupling)

•  Object model => –  Activity 4: Hardware/software mapping –  Activity 5: Persistent data management

•  Dynamic model => –  Activity 3: Concurrency –  Activity 6: Global resource handling –  Activity 7: Software control –  Activity 8: Boundary conditions


8

Example: Current Desktop Development


9

Single Output Device

Precise Input

Direction where the user looks is

irrelevant

Fixed Network Connection

Location of user does not

matter

Identify Current Technology Constraints


10

Single Output Device

Precise Input


irrelevant

Fixed Network Connection

Location of user does not

matter

Multiple Output Devices

Vague Input


relevant

Dynamic Network Connection

Location-based

Generalize Constraints using Technology Enablers


11

Design Goals

•  Reliability •  Modifiability •  Maintainability •  Understandability •  Adaptability •  Reusability •  Efficiency •  Portability •  Traceability of requirements •  Fault tolerance •  Backward-compatibility •  Cost-effectiveness •  Robustness •  High-performance

•  Good documentation •  Well-defined interfaces •  User-friendliness •  Reuse of components •  Rapid development •  Minimum # of errors •  Readability •  Ease of learning •  Ease of remembering •  Ease of use •  Increased productivity •  Low-cost •  Flexibility


12

Relationships among Design Goals

Reliability

Low cost Increased Productivity Backward-Compatibility Traceability of requirements Rapid development Flexibility

Client

End User

(Customer,

Portability Good Documentation

Runtime Efficiency

Sponsor)

Developer/ Maintainer

Minimum # of errors Modifiability, Readability Reusability, Adaptability Well-defined interfaces

Functionality User-friendliness Ease of Use Ease of learning Fault tolerant Robustness


13

Design goals grouping •  Performance

–  Response time –  Throughput –  Memory

•  Dependability –  Robustness –  Reliability –  Availability –  Fault tolerance –  Security –  Safety

•  End-user criteria –  Utility –  Usability

•  Cost –  Development cost –  Deployment cost –  Upgrade cost –  Maintenance cost –  Administration cost

•  Maintenance –  Extensibility –  Modifiability –  Adaptability –  Portability –  Readability –  Traceability of requirements

14

Design Trade-offs •  Space vs. Speed •  Efficiency vs. Portability •  Rapid development vs. Functionality •  Cost vs. Reusability •  Backward Compatibility vs. Readability •  Delivery time vs. Quality •  Delivery time vs. Functionality •  …


15

System Decomposition •  Subsystem

–  Collection of classes, associations, operations, events and constraints that are interrelated

–  Seed for subsystems: UML Use cases, Objects and Classes.

•  Service: –  Group of operations provided by the subsystem (a set

of related operations that share a common purpose) –  Seed for services: Subsystem use cases

•  Service is specified by Subsystem interface: –  Specifies interaction and information flow from/to

subsystem boundaries, but not inside the subsystem.


16

Coupling and Cohesion •  Goal: Reduction of complexity while change occurs •  Coupling measures dependencies between subsystems

–  High coupling: Changes to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.)

–  Low coupling: A change in one subsystem does not affect any other subsystem

•  Cohesion measures the dependence within the system –  High cohesion: The classes in the subsystem perform similar tasks

and are related to each other (via associations) –  Low cohesion: Lots of miscellaneous and auxiliary classes, no

associations •  Subsystems should have as maximum cohesion and

minimum coupling as possible: –  How can we achieve high cohesion? –  How can we achieve loose coupling?


17

Reducing coupling

MapManagement

IncidentManagement

Database

ResourceManagement

Alternative 1: Direct access to the Database subsystem

MapManagement IncidentManagement

Storage

ResourceManagement

Database

Alternative 2: Indirect access to the Database through a Storage subsystem


18

Increasing cohesion Alternative

Decision

Criterion

subtasks

* SubTask

ActionItem

DesignProblem

Task

assesses

solvableBy

resolvedBy

based-on

* * *

implementedBy

DecisionSubsystem

Alternative 1

Alternative 2

subtasks

*

assesses

solvableBy resolvedBy

based-on

* * *

implementedBy

RationaleSubsystem

PlanningSubsystem

Criterion Alternative

Decision

DesignProblem

SubTask

ActionItem Task 19

Partitions and Layers Partitioning and layering are techniques to achieve

low coupling. A large system is usually decomposed into

subsystems using both, layers and partitions. •  Partitions vertically divide a system into several

independent (or weakly-coupled) subsystems that provide services on the same level of abstraction.

•  A layer is a subsystem that provides subsystem services to a higher layers (level of abstraction) –  A layer can only depend on lower layers –  A layer has no knowledge of higher layers


20

Subsystem Decomposition into Layers

•  Subsystem Decomposition Heuristics: –  No more than 7+/-2 subsystems at any layer

•  More subsystems increase cohesion but also complexity (more services)

–  No more than 7+/-2 layers, use 3 layers (good)

F:SubsystemE:Subsystem G:Subsystem

D:SubsystemC:SubsystemB:Subsystem

A: Subsystem Layer 1

Layer 2

Layer 3


21

Closed Architecture (Opaque Layering)

•  Any layer can only invoke operations from the immediate layer below

•  Design goal: High maintainability, flexibility

VM4

VM3

VM2

VM1 C1

attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op


22

Open Architecture (Transparent Layering)

•  Any layer can invoke operations from any layers below

•  Design goal: Runtime efficiency

VM4

VM3

VM2

VM1 C1

attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op


23

Layered Architecture Application

Presentation

Session

Transport

Network

DataLink

Physical

Leve

l of a

bstra

ctio

n

•  ISO’s OSI Reference Model –  ISO = International

Standard Organization –  OSI = Open System

Interconnection •  Reference model defines 7

layers of network protocols and strict methods of communication between the layers.

•  Closed software architecture


24

Virtual Machine

VM4

VM3

VM2

VM1 C1 attr opr

C1 attr opr

C1 attr opr

C1 attr opr

C1 attr opr

C1 attr opr

C1 attr opr

C1 attr opr

Problem

Existing System Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

25

Properties of Layered Systems •  Layered systems are hierarchical. They are

desirable because hierarchy reduces complexity (by low coupling).

•  Closed architectures are more portable. •  Open architectures are more efficient. •  Layered systems often have a chicken-and egg

problem –  Example: Debugger


G: Op. System

D: File System A: Debugger

26

Choosing Subsystems •  Criteria for subsystem selection: Most of the

interaction should be within subsystems (High cohesion), rather than across subsystem boundaries (Low coupling).

•  Primary Question: –  What kind of service is provided by the subsystems

(subsystem interface)?

•  Secondary Question: –  Can the subsystems be hierarchically ordered (layers)?


27

Heuristics for grouping objects into subsystems

•  Assign objects identified in one use case into the same subsystem

•  Minimize the number of associations crossing subsystem boundaries

•  All objects in the same subsystem should be functionally related

•  …


28

Software Architectural Styles

•  Subsystem decomposition –  Identification of subsystems, services, and their

relationship to each other. •  Specification of the system decomposition is critical. •  Patterns for software architecture

–  Client/Server –  Peer-To-Peer –  Repository –  Model/View/Controller –  Pipes and Filters –  …


29

System as a set of subsystems communicating via a software bus

Authoring

Modeling

Augmented Reality

Workorder Repair

Inspection

Workflow

A Subsystem Interface Object publishes the service (= Set of public methods) provided by the subsystem


30

Repository Architectural Style •  Subsystems access and modify data from a single

data structure •  Subsystems are loosely coupled (interact only

through the repository) •  Control flow is dictated by central repository

(triggers) or by the subsystems (locks, synchronization primitives)

Subsystem

Repository

createData() setData() getData() searchData()


31

Repository Architectural Style

LexicalAnalyzer

SyntacticAnalyzer SemanticAnalyzer

CodeGenerator

Compiler

SyntacticEditor

ParseTree SymbolTable

Repository

SourceLevelDebugger

Optimizer


32

Client/Server Architectural Style •  One or many servers provide services to instances of

subsystems, called clients. •  Client calls on the server, which performs some service

and returns the result –  Client knows the interface of the server (its service) –  Server does not need to know the interface of the client

•  Response in general immediate •  Users interact only with the client

Client

Server

service1()service2()

serviceN()…

**

requester provider


33

Client/Server Architectural Style •  Often used in database systems:

–  Front-end: User application (client) –  Back end: Database access and manipulation (server)

•  Functions performed by client: –  Customized user interface –  Front-end processing of data –  Initiation of server remote procedure calls –  Access to database server across the network

•  Functions performed by the database server: –  Centralized data management –  Data integrity and database consistency –  Database security –  Concurrent operations (multiple user access) –  Centralized processing (for example archiving)


34

Design Goals for Client/Server Architectural Style

•  Service Portability –  Service can be installed on a variety of machines and operating

systems and functions in a variety of networking environments •  Transparency, Location-Transparency

–  The server might itself be distributed, but should provide a single "logical" service to the user

•  Performance –  Client should be customized for interactive display-intensive tasks –  Server should provide CPU-intensive operations

•  Scalability –  Server should have spare capacity to handle larger number of

clients •  Flexibility

–  The system should be usable for a variety of user interfaces and end devices (eg. WAP Handy, wearable computer, desktop)

•  Reliability –  System should survive node or communication link problems


35

Peer-to-Peer Architectural Style •  Generalization of Client/Server Architecture •  Clients can be servers and servers can be clients •  More difficult because of possibility of deadlocks

Peer


serviceN()…

requester

provider

*

*

application1:DBUser

database:DBMS

application2:DBUser

1. updateData

2. changeNotification


36

Model/View/Controller •  Subsystems are classified into 3 different types

–  Model subsystem: Responsible for application domain knowledge

–  View subsystem: Responsible for displaying application domain objects to the user

–  Controller subsystem: Responsible for sequence of interactions with the user

•  MVC is a special case of a repository architecture: –  Model subsystem implements the central datastructure, the

Controller subsystem explicitly dictate the control flow

Controller

Model

subscriber notifier

initiator

*

repository 1

1

*

View


37

Sequence of Events (Collaborations)

:Controller

:InfoView

:Model

2.User types new filename

1. Views subscribe to event

3. Request name change in model

4. Notify subscribers 5. Updated views

:FolderView


38

Three-tier architectural style.

Interface

Application Logic

Storage

Connection

Form

Query


39

Four-tier architectural style.

Presentation Server

Application Logic

Storage

Connection

Form

Query

Presentation Client WebBrowser


40

Pipe and filter architectural style.

Pipe input output

output input * 1

* 1 Filter

% ps auxwww | grep dutoit | sort | more

dutoit 19737 0.2 1.6 1908 1500 pts/6 O 15:24:36 0:00 -tcsh dutoit 19858 0.2 0.7 816 580 pts/6 S 15:38:46 0:00 grep dutoit dutoit 19859 0.2 0.6 812 540 pts/6 O 15:38:47 0:00 sort

ps grep sort more


41

Intermediate Summary •  System Design

–  Reduces the gap between requirements and the (virtual) machine

–  Decomposes the overall system into manageable parts

•  Design Goals Definition –  Describes and prioritizes the qualities that are important

for the system –  Defines the value system against which options are

evaluated

•  Subsystem Decomposition –  Results into a set of loosely dependent parts which

make up the system Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

42

System Design Activities (continue)

– Hardware/Software Mapping – Persistent Data Management – Global Resource Handling and Access Control – Software Control – Boundary Conditions


43

Hardware/Software Mapping •  This activity addresses two questions:

–  How shall we realize the subsystems: Hardware or Software?

–  How is the object model mapped on the chosen hardware & software?

•  Mapping Objects onto Reality: Processor, Memory, Input/Output

•  Mapping Associations onto Reality: Connectivity

•  Much of the difficulty of designing a system comes from meeting externally-imposed hardware and software constraints. –  Certain tasks have to be at specific locations


44

UML: Component and Deployment diagrams

•  Models for physical implementation of the system •  Show system components, their structure and dependencies

and how they are deployed on computer nodes •  Two kinds of diagrams:

–  component diagrams –  deployment diagrams

•  Component diagrams show structure of components, including their interface and implementation dependencies

•  Deployment diagrams show the runtime deployment of the system on computer nodes

45

Component Diagrams (component interface)

<<component>> OnLinePayment

PaymentTransaction

IdentityManagement


<<interface>> PaymentTransaction

begin() commit() rollback() addLineitem() deleteLineItem() <<interface>>

IdentifyManagement

authenticate()

<<use>>

Adopted from Shaum

46

Component Diagram


PaymentTransaction

IdentityManagement

<<component>> InsuranceBrokerage

<<component>> MemberManagement

<<component>> EPayDay

Adopted from Shaum

47

Deployment diagrams

Web-Server PC

<<TCP/IP>>

stockholm:PCClient madrid:PCClient dehli:PCClient

boss:PCServer

<<TCP/IP>> <<TCP/IP>> <<TCP/IP>>

Adopted from Shaum

48

Deployment diagrams

:MainServer

:JBossServer :CertifiedClock <<J2EE Container>> <<device>>

Adopted from Shaum

49

Drawing Hardware/Software Mappings in UML

•  System design must model static and dynamic structures: – Component Diagrams for static structures

•  show the structure at design time or compilation time

– Deployment Diagram for dynamic structures •  show the structure of the run-time system


50

Deployment Diagrams (artifact)

•  Component

•  Artifact

51

Manifestation relationship between artifacts and components

52

Location of Artifacts on the node

53

Data Management •  Some objects in the models need to be persistent

•  A persistent object can be realized with one of the following –  Files

•  Cheap, simple, permanent storage •  Low level (Read, Write) •  Applications must add code to provide suitable level of

abstraction –  Database

•  Powerful, easy to port •  Supports multiple writers and readers


54

File or DB? When should you choose flat files? •  Voluminous data (e.g., images) •  Temporary data (e.g., core file) •  Low information density (e.g., archival files, history logs)

When should you choose a relational or an object-oriented database? •  Concurrent accesses •  Access at finer levels of detail •  Multiple platforms or applications for the same data

When should you choose a relational database? •  Complex queries over attributes •  Large data set

When should you choose an object-oriented database? •  Extensive use of associations to retrieve data •  Medium-sized data set •  Irregular associations among objects


55

Global Resource Handling

•  Discusses access control •  Describes access rights for different classes

of actors •  Describes how object guard against

unauthorized access


56

Access Matrix Implementations •  Global access table: Represents explicitly every cell in the

matrix as a (actor,class, operation) tuple. –  Determining if an actor has access to a specific object requires

looking up the corresponding tuple. If no such tuple is found, access is denied.

•  Access control list associates a list of (actor, operation) pairs with each class to be accessed. –  Every time an object is accessed, its access list is checked for the

corresponding actor and operation. –  Example: guest list for a party.

•  A capability associates a (class,operation) pair with an actor. –  A capability provides an actor to gain control access to an object

of the class described in the capability. –  Example: An invitation card for a party.

•  Which is the right implementation?


57

Decide on Software Control

Choose implicit control (non-procedural, declarative languages) –  Rule-based systems –  Logic programming

Choose explicit control (procedural languages): •  Procedure-driven control

–  Control resides within program code. Operations wait for input whenever they need data from an actor. Example: Main program calling procedures of subsystems.

–  Simple, easy to build, hard to maintain (high recompilation costs) •  Event-driven control

–  Control resides within a dispatcher calling functions via callbacks. –  Very flexible, good for the design of graphical user interfaces, easy

to extend


58

Centralized vs. Decentralized Designs

•  Should you use a centralized or decentralized design? –  Take the sequence diagrams and control objects from the analysis

model –  Check the participation of the control objects in the sequence

diagrams •  If sequence diagram looks more like a fork: Centralized design •  The sequence diagram looks more like a stair: Decentralized design

•  Centralized Design –  One control object or subsystem ("spider") controls everything

•  Pro: Change in the control structure is very easy •  Cons: The single control object is a possible performance bottleneck

•  Decentralized Design –  Not a single object is in control, control is distributed, that means,

there is more than one control object •  Cons: The responsibility is spread out – changes are not obvious •  Pro: Fits nicely into object-oriented development


59

Boundary Condition Questions •  Initialization

–  How does the system start up? •  What data need to be accessed at startup time? •  What services have to be registered?

–  What does the user interface do at start up time? •  How does it present itself to the user?

•  Termination –  Are single subsystems allowed to terminate? –  Are other subsystems notified if a single subsystem terminates? –  How are local updates communicated to the database?

•  Failure –  How does the system behave when a node or communication link

fails? Are there backup communication links? –  How does the system recover from failure? Is this different from

initialization? Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

60

Modeling Boundary Conditions

•  Boundary conditions are best modeled as use cases with actors and objects.

•  Actor: often the system administrator •  Interesting use cases:

– Start up of a subsystem – Start up of the full system – Termination of a subsystem – Error in a subystem or component, failure of a

subsystem or component


61

ManageServer Use Case

PlanningService

ManageDrivers

ManageMaps

ManageServer

Administrator StartServer

ShutdownServer

ConfigureServer

<<include>>

<<include>>

<<include>>


62

Summary In this lecture, we reviewed the activities of system design : •  Design goals identification •  System decomposition •  Concurrency identification •  Hardware/Software mapping •  Persistent data management •  Global resource handling •  Software control selection •  Boundary conditions

Each of these activities revises the subsystem decomposition to address a specific issue. Once these activities are completed, the interface of the subsystems can be defined.

63

Next lecture

•  Object design

Chapters 8 & 9

64

Identifying boundary cases

•  Configuration •  Start-up and shutdown •  Exception handling

– Hardware failure – Changes in operating environment – Software failures

65

Why models?

•  Reality R: Real Things, People, Processes happening during some time, Relationship between things

•  Model M: Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions.

•  We use models –  To abstract away from details in the reality, so we can

draw complicated conclusions in the reality with simple steps in the model

–  To get insights into the past or presence –  To make predictions about the future


66

Definition: Subsystem Interface Object?

•  A Subsystem Interface Object provides a service

– This is the set of public methods provided by the subsystem

– The Subsystem interface describes all the methods of the subsystem interface object

•  Use a Facade pattern for the subsystem interface object

67

ARENA Subsystem decomposition

Tournament

Component Management

User Management

Tournament Statistics

User Directory

User Interface

Session Management

Advertisement

68

ARENA Subsystem decomposition

Tournament

Component Management

User Management

Tournament Statistics

User Directory

Session Management

For adding games, styles, and expert

rating formulas"

Stores user profiles (contact &

subscriptions)"Stores results of archived

tournaments"Maintains state during matches."

Administers user accounts"

Advertisement

Manages tournaments, applications, promotions."

User Interface Manages advertisement banners and sponsorships."

69

Concurrency •  Identify concurrent threads and address

concurrency issues. •  Design goal: response time, performance.

•  Threads –  A thread of control is a path through a set of state

diagrams on which a single object is active at a time. –  A thread remains within a state diagram until an object

sends an event to another object and waits for another event

–  Thread splitting: Object does a nonblocking send of an event.


70

Concurrency Questions

•  Which objects of the object model are independent?

•  What kinds of threads of control are identifiable? •  Does the system provide access to multiple users? •  Can a single request to the system be decomposed

into multiple requests? Can these requests be handled in parallel?

71

N

Bedroom2 Master Bedroom

Dining

Hallway

Stairs

Bath

Kitchen Study

Bath

Kitchen

Master Bedroom Dining

Hallway

Stairs

Entrance

door

Master Bedroom

Bedroom2

Dining

Hallway

Stairs

Entrance door

Study

Study

Bath

Kitchen

Bedroom2

Entrance door

Version 1 Version 2

Version 3 72

Nonfunctional Requirements may give a clue for the use of Design Patterns

•  Text: “manufacturer independent”, “device independent”, “must support a family of products” –  Abstract Factory Pattern

•  Text: “must interface with an existing object” –  Adapter Pattern

•  Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated” –  Bridge Pattern


73

Textual Clues in Nonfunctional Requirements

•  Text: “complex structure”, “must have variable depth and width” –  Composite Pattern

•  Text: “must interface to an set of existing objects” –  Façade Pattern

•  Text: “must be location transparent” –  Proxy Pattern

•  Text: “must be extensible”, “must be scalable” –  Observer Pattern

•  Text: “must provide a policy independent from the mechanism” –  Strategy Pattern


74

A 3-layered Architecture

Repair Inspection Authoring

Augmented Reality

Workflow Modeling

75

UML deployment diagram

:WebServer

myMac:Mac :UnixHost

:IExplorer

aPC:PC

:Database

:UnixHost

:Safari


76

Sharpen the Design Goals •  Location-based input

–  Input depends on user location –  Input depends on the direction where the user

looks (“egocentric systems”) •  Multi-modal input

–  The input comes from more than one input device •  Dynamic connection

–  Contracts are only valid for a limited time •  Is there a possibility of further generalizations? •  Example: location can be seen as a special case of

context –  User preference is part of the context –  Interpretation of commands depends on context


77

Event-Driven Control Example: MVC

•  Model-View-Controller Paradigm (Adele Goldberg, Smalltalk 80)

:Control

:Model :View

:View

:View Model has changed

Update Update

Update


78

Quality of design •  Correct

–  if the analysis model can be mapped to the system design model •  Complete

–  if every requirement and every system design issue has been addressed

•  Consistent –  if it does not contain any contradictions

•  Realistic –  if the corresponding system can be implemented

•  Readable –  if developers not involved in the system design can

understand the model

79

The Purpose of System Design

•  Bridging the gap between desired and existing system in a manageable way

•  Use Divide and Conquer –  We model the new system to

be developed as a set of subsystems

Problem

Existing System

New System


80


System Design


81

Introduction Content 0. Overview of System Design 1. Design Goals 2. Subsystem Decomposition 3. Concurrency 4. Hardware/Software Mapping 5. Persistent Data Management 6. Global Resource Handling and Access Control 7. Software Control 8. Boundary Conditions

82

System as a set of subsystems communicating via a software bus

Authoring

Modeling

Augmented Reality

Workorder Repair

Inspection

Workflow

A Subsystem Interface Object publishes the service (= Set of public methods) provided by the subsystem


83

Client/Server Architectural Style •  One or many servers provides services to instances of



•  Response in general immediately •  Users interact only with the client

Client

Server


serviceN()…

**

requester provider


84

Client/Server Architectural Style •  One or many servers provides services to instances of



•  Response in general immediately •  Users interact only with the client

Client

Server


serviceN()…

**

requester provider


85

Peer-to-Peer Architectural Style •  Generalization of Client/Server Architecture •  Clients can be servers and servers can be clients •  More difficult because of possibility of deadlocks

Peer


serviceN()…

requester

provider

*

*

application1:DBUser

database:DBMS

application2:DBUser

1. updateData

2. changeNotification


86

Another view to ISO Model Application

Presentation

Session

Transport

Network

DataLink

Physical

Frame

Packet

Bit

Connection

Format

Message

•  A closed software architecture

•  Each layer is a UML package containing a set of objects


87

Services and Subsystem Interfaces

•  Service: A set of related operations that share a common purpose –  Notification subsystem service:

•  LookupChannel() •  SubscribeToChannel() •  SendNotice() •  UnscubscribeFromChannel()

–  Services are defined in System Design •  Subsystem Interface: Set of fully typed related operations.

–  Subsystem Interfaces are refined in Object Design –  Should be well-defined and small. –  Often called API: Application programmer’s interface - this term

should used during implementation, not during System Design

88

Subsystem Decomposition

Class parts

* System Part

*

Subsystem


89

Example: Subsystem Decomposition

Is this the right decomposition or is this too much ravioli?

Modeling

Authoring

Workorder Repair

Inspection

Augmented Reality

Workflow


90

Subsystem decomposition of MyTrip

PlanningSubsystem

MapDBStoreSubsystem TripFileStoreSubsystem

RoutingSubsystem

CommunicationSubsystem


91

File or Database? •  When should you choose a file?

–  Are the data voluminous (bit maps)? –  Do you have lots of raw data (core dump, event trace)? –  Do you need to keep the data only for a short time? –  Is the information density low (archival files, history logs)?

•  When should you choose a database? –  Do the data require access at fine levels of details by multiple

users? –  Must the data be ported across multiple platforms (heterogeneous

systems)? –  Do multiple application programs access the data? –  Does the data management require a lot of infrastructure?


92

Issues To Consider When Selecting a Database

•  Storage space –  Database require about triple the storage space of actual data

•  Response time –  Modern databases are I/O or communication bound (distributed

databases). Response time is also affected by CPU time, locking contention and delays from frequent screen displays

•  Locking modes –  Pessimistic locking: Lock before accessing object and release when object

access is complete –  Optimistic locking: Reads and writes may freely occur (high

concurrency!) When activity has been completed, database checks if contention has occurred. If yes, all work has been lost.

•  Administration –  Large databases require specially trained support staff to set up security

policies, manage the disk space, prepare backups, monitor performance, adjust tuning.


93

Data Management Questions •  Should the data be distributed? •  Should the database be extensible? •  How often is the database accessed? •  What is the expected request (query) rate? In the worst

case? •  What is the size of typical and worst case requests? •  Do the data need to be archived? •  Does the system design try to hide the location of the

databases (location transparency)? •  Is there a need for a single interface to access the data? •  What is the query format? •  Should the database be relational or object-oriented?


94

Global Resource Questions •  Does the system need authentication? •  If yes, what is the authentication scheme?

–  User name and password? Access control list –  Tickets? Capability-based

•  What is the user interface for authentication? •  Does the system need a network-wide name

server? •  How is a service known to the rest of the system?

–  At runtime? At compile time? –  By port? –  By name?


95

Allocation subsystems to hardware

RoutingSubsystem.jar PlanningSubsystem.jar

:OnBoardComputer :WebServer

96

General Design Activities

•  Identify design goals.

•  Design the initial subsystem decomposition.

•  Refine the subsystem decomposition to address the design goals.

97

Mapping the Subsystems Associations: Connectivity

•  Describe the physical connectivity of the hardware –  Often the physical layer in ISO’s OSI Reference Model

•  Which associations in the object model are mapped to physical connections?

•  Which of the client-supplier relationships in the analysis/design model correspond to physical connections?

•  Describe the logical connectivity (subsystem associations) –  Identify associations that do not directly map into physical

connections: •  How should these associations be implemented?


98

Logical vs Physical Connectivity

Application Layer Application Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Bidirectional associations for each layer"

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Processor 1! Processor 2!

Logical!Connectivity!Layers!

Physical!Connectivity!


99

An Example of Connectivity Drawing DistributedDatabaseArchi tecture Tue, Oct 13 , 1992 12:53 AM

Application Cl ient

Application Cl ient

Application Cl ient

Co mmunication Agent for

Application Clients

Co mmunication Agent for

Application Clients

Co mmunication Agent for Data

Server

Co mmunication Agent for Data

Server

Local Data Server

Global Data Server

Global Data Server

Global Data

Server

OODBMS

RDBMS

Backbone Network

LAN

LAN

LAN

TCP/IP Ethernet

Physical Connectivity

Logical Connectivity


100

Deployment specification

Adopted from UML2.0-03-08-02

101

Decomposition for an accident management system

Notification IncidentManagement

FieldOfficerInterface DispatcherInterface


102

Hardware/Software Mapping Questions

•  What is the connectivity among physical units? –  Tree, star, matrix, ring

•  What is the appropriate communication protocol between the subsystems? –  Function of required bandwidth, latency and desired reliability,

desired quality of service (QoS) •  Is certain functionality already available in hardware? •  Do certain tasks require specific locations to control the

hardware or to permit concurrent operation? –  Often true for embedded systems

•  General system performance question: –  What is the desired response time?


103

Overview of System Design Activities

Describe boundary conditions

Define Define subsystems

Map subsystems to hardware/

Manage

Select a

Define access

design goals

persistent data

control policies

global

Implement subsystems

software platform

control flow


104

Deployment Diagram

<<artifact>> Router.jar

:OnBoardComputer

<<artifact>> Planner.jar

:WebServer <<artifact>>

DB.jar


105

Defining Access Control

•  In multi-user systems different actors have access to different functionality and data. –  During analysis we model these different accesses by

associating different use cases with different actors. –  During system design we model these different access

by examing the object model by determining which objects are shared among actors.

•  Depending on the security requirements of the system, we also define how actors are authenticated to the system and how selected data in the system should be encrypted.


106

Peer

Client Server

107

Component Diagram (component realization)


IdentityManagement PaymentTransaction

<<realization>> Payment PaymentItem PaymentController

Payment PaymentItem PaymentController

Adopted from Shaum

108

Component Diagram

Scheduler

Planner

GUI

reservations

update

<<component>>

<<component>>

<<component>>

109


System Design


110

Literature used

•  Text Book Chapters 6 and 7

111

Introduction Content Overview of System Design Activities:

1. Design Goals 2. Subsystem Decomposition 3. Other activities Hardware/Software Mapping Persistent Data Management Global Resource Handling and Access Control Software Control Boundary Conditions

112

Documents

Modern methods in Software Engineering System …misha/ID2207/2014/lectures/Syste… · · 2014-09-15Modern methods in Software Engineering ... Using UML, Patterns, and Java 34