1. Lecture 6: Design Concepts and Architecture

2. 1. Software Design Principles

3. Software Design Model Interface Architectural Data Procedural

4. The Purpose of Software
The purpose of software is to perform some sort of information processing
Information processing means to act on or transform information according to specified algorithms and rules
Information means data and associated semantics

5. Software Design Process (1)
Start with the DATA
Requirements analysis will provide all required data
Use cases will hint the data flow
Data
Interface
Procedural
Design Model
Architectural

6. Software Design Process (2)
Select an architecture
This means combining data with semantic and organizational features
Requirements analysis and use cases will tell the story
Initial result should be platform independent
Data
Interface
Procedural
Design Model
Architectural

7. Software Design Process (3)
Define interfaces
This defines how the system will interact with the rest of the world
Requirements analysis and use cases will tell the story
Initial result should be platform independent
Data
Interface
Procedural
Design Model
Architectural

8. Software Design Process (4)
Fill in the semantic details
Define the mechanics behind the interfaces
Define all the internal states and transitions
This is a recursive refinement
Verify with use cases and requirements!
Data
Interface
Procedural
Design Model
Architectural

9. Software Specification Process (1)
Data
Interface
Proc. DM
Architectural
Start with the DATA
From the requirements, extract the top level data and associated semantics
Based on this, create a top level description of the system
Recursively refine the data definitions and create a data dictionary

10. Software Specification Process (2)
Data
Interface
Proc. DM
Architectural
Follow the subdivisions of the system and create a separate chapter for each subsystem
Guided by requirements and use cases describe the top level semantics
Include use case, interaction and activity diagrams
Define package structure and high level classes

11. Software Specification Process (3)
Data
Interface
Proc. DM
Architectural
Define the interfaces for each section of the system
For user interfaces eventually sketch window layouts, etc.
Recursively refine the interface definitions guided by requirements, use cases, interactions and architectural costraints

12. Software Specification Process (4)
Data
Interface
Proc. DM
Architectural
Recursively define and refine all operations of the system
Always check specifications against requirements
Review data, architecture and interfaces
At the end you should have a solid, detailed and unambiguous specification

13. 2. Architecture Principles

14. Software Design Model Interface Architectural Data Procedural

15. What is Architecture?
It is the first design step, taken on a very high level of abstraction
It defines shape, structure and appearance
It defines semantic and behavioral properties
It does not define the implementation
It is a kind of art

16. Architecture Levels (1)
Platform Independent Architecture
Defines a system in terms of abstract components
Defines only the semantics, does not specify a particular implementation
This is a very important step, it preserves the intellectual property across system versions
Will be mapped on a platform specific architecture in the next step

17. Architecture Levels (2)
What is this?
Every key represents a distinct tone
The keyboard defines clear semantics for each key
But it does not imply an implementation
This is a Platform Independent Architecture!

18. Architecture Levels (3)
The platform independent architecture of a Piano consists of:
88 Keys (36 black and 52 white)
The keys are organized into groups of 12 (with two fractional groups on both ends)
Each key is assigned to a particular tone, which has a well-known frequency
But this architecture does not define
How a key is tied to the tone
How the tone frequency is generated

19. Architecture Levels (4)
Conforming Implementations

20. Architecture Levels (5)
Conforming Implementations

21. Architecture Levels (6)
What was called “Conforming Implementations” can be re-grouped as a set of Platform Specific Architectures
These architectures are implementation-specific but still on an elevated level of abstraction
They play an important role in the discovery of reusable elements

22. Future Trends
The next generation of system and software design methodologies will work with platform independent models as principle design unit Keyword: Model-Driven Architectures
You will see increasing usage of modeling languages like UML in the design phase
Future programming models will mostly rely on code generation techniques, this requires a clean architecture development style

23. The Piano Use Case

24. The Piano Interfaces (1)

25. The Piano Interfaces (2)
Our use case represents two interfaces:
CommandInput – representing the keyboard
Has operation sampleKey() which reports
Which key had been pressed
The characteristics of the key operation
ToneOutput – representing the acoustic device
Has operation emitWave() with arguments
Frequency
Volume

26. The Piano Top Level Architecture

27. The Refined Architecture

28. Our Example Order Entry System
Two alternative views are presented
Data Flow oriented
Function oriented

29. Use Case: Order Handling (1)

30. Data Flow Architecture (1)

31. Data Flow Architecture (2)

32. Functional Architecture

33. Benefits of Architecture Effort
Provides a first feeling how the design fulfills the requirements
Is a creative stage, allows inexpensive experimentation
Helps to structure a project
technically
organizationally
Reduces the risk of a project

34. 3. Architecture and Design (a more traditional view)

35. Data Design Refine data objects and develop a set of data abstractions
Implement data object attributes as one or more data structures
Review data structures to ensure that appropriate relationships have been established
Simplify data structures as required

36. Data Design - Component Level (1)
The systematic analysis principles applied to function and behavior should also be applied to data.
All data structures and the operations to be performed on each should be identified.
A data dictionary should be established and used to define both data and program design.
Low level data design decisions should be deferred until late in the design process.

37. Data Design - Component Level (2)
The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure.
A library of useful data structures and the operations that may be applied to them should be developed.
A software design and programming language should support the specification and realization of abstract data types.

38. Architectural Styles (1)
Each style describes a system category that encompasses:
a set of components (e.g., a database, computational modules) that perform a function required by a system
a set of connectors that enable “communication, coordination and cooperation” among components

39. Architectural Styles (2)
constraints that define how components can be integrated to form the system
overall properties of a system by analyzing the known properties of its constituent parts

40. Architectural Styles (3)
Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures
(Not considering distributed architectures here)

41. Data-Centered Architecture
Client
Software
Client
Software
Client
Software
Client
Software
Data Store
(Repository or Black Board)
Client
Software
Client
Software
Client
Software
Client
Software

42. Data Flow Architecture
Filter
Filter
Filter
Filter
Filter
Filter
Filter
Filter
Filter
Pipes
Filter
Pipes and Filters
Filter
Filter
Filter
Filter
Batch Sequential

43. Call and Return ArchitectureM a b c d e f g h i j k l m n o p q r
Depth
Width
Fan-out
Fan-in

44. Layered Architecture

45. Analyzing Architectural Design (1)
Collect scenarios
Elicit requirements, constraints, and environment description
Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:
module view
process view
data flow view

46. Analyzing Architectural Design (2)
Evaluate quality attributes by considered each attribute in isolation
Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style
Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5

47. Architectural Design customer requirements architectural design
"four bedrooms, three baths,
lots of glass ..."
architectural design

48. Program Architecture
Defines the control hierarchy that connects modules in the system to one another … M A B C D E G F H I J

49. Deriving Program Architecture

50. Partitioning the Architecture
“horizontal” and “vertical” partitioning are required

51. Horizontal Partitioning
Define separate branches of the module hierarchy for each major function
Use control modules to coordinate communication between functions
function 1
function 3
function 2

52. Vertical Partitioning: Factoring
Design so that decision making and work are stratified
Decision making modules should reside at the top of the architecture
decision-makers
workers

53. Why Partitioned Architecture?
Results in software that is easier to test
Leads to software that is easier to maintain
Results in propagation of fewer side effects
Results in software that is easier to extend

54. Structured Design
Objective: to derive a program architecture that is partitioned
Approach:
the DFD is mapped into a program architecture
the PSPEC and STD are used to indicate the content of each module
Notation: structure chart

55. Structure Chart Data Control Flag
used to represent data that flow between modules, can be labeled
Module A
Module B
Module C
Module D
Module E
Module F
Module G
Module H

56. Flow Characteristics
Transform flow
Transaction
flow

57. General Mapping Approach
Isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center
Working from the boundary outward, map DFD transforms into corresponding modules
Add control modules as required
Refine the resultant program structure using effective modularity concepts

58. Transform Mapping

59. Factoring

60. First Level Factoring
Main
Program
Controller
Input
Processing
Output

61. Second Level Mapping

62. Transaction Flow
incoming flow
action path T

63. Transaction Example fixture fixture setting servos commands operator
process
fixture setting
report
robot control
fixture
servos
display
screen
robot
control
software
in reality, other
would also be shown
assembly
record

64. Refining the Analysis Model
Write an English language processing narrative for the level 01 flow model
Apply noun/verb parse to isolate processes, data items, store and entities
Develop level 02 and 03 flow models
Create corresponding data dictionary entries
Refine flow models as appropriate
... now, we're ready to begin design!

65. A Simple Verification Technique
Processing narrative for " process operator commands"
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
the robot control system.
Process operator command software
reads
operator
commands
from
the cell
. An
error message is
displayed
for
invalid commands .
The
command type
determined
valid commands
and appropriate
action is
taken
. When
fixture commands
are
encountered ,
fixture
status
analyzed
and a
fixture setting
output
to the
fixture servos
When a
report
selected,
the
assembly record file
read
and a
report is
generated
and
on the operator
display screen
When
robot control switches
selected
control value
s are
sent to
robot control system.
noun-verb
parse

66. A Simple Verification Technique
Processing narrative for " process operator commands"
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
the robot control system.
Process operator command software
reads
operator
commands
from
the cell
. An
error message is
displayed
for
invalid commands .
The
command type
determined
valid commands
and appropriate
action is
taken
. When
fixture commands
are
encountered ,
fixture
status
analyzed
and a
fixture setting
output
to the
fixture servos
When a
report
selected,
the
assembly record file
read
and a
report is
generated
and
on the operator
display screen
When
robot control switches
selected
control value
s are
sent to
robot control system.
noun-verb
parse

67. Unified Modeling Language
(The Object Constraint Language)

68. The Object Constraint Language
is part of UML
is not a graphical language
is intended to provide a formal way to specify constraints and expressions

69. What OCL is it is a formal language it is a pure expression language
Expressions are guaranteed to be without side-effects
it is a typed language
Each expression has a type, and must conform to be well-formed

70. What OCL is it is a specification language
All implementation issues are out of scope
Expression evaluation is instantaneous and atomic
State of objects cannot change during evaluation

71. What OCL is not OCL is not a programming language
Does not support program logic or flow control
Cannot invoke processes or activate non-query operations

72. OCL is used for Specification of invariants for Classes and Types
Specification of invariants for Stereotypes
Specify pre- and post-conditions on Operations and Methods

73. OCL is used for To specify constraints on operations To specify Guards
As navigation language

74. OCL Syntax (1)
Each expression is evaluated in the context of an Object
context TypeName
The context can be named
context c : TypeName

75. OCL Syntax (2) You refer to the object using the keyword “self”
self.numberOfEmployees > 50
Or you use the context name if you are working in a named context
c.numberOfEmployees > 50

76. OCL Syntax (3) The expression can specify an invariant of the object
context Company inv:
Or it can specify pre- and post-conditions
context T_name::op_name(par1: T1,..): Ret
pre: par1 > ...
post: result = ...

77. OCL Syntax (4) You can set also a package context
package Package::SubPackage

78. OCL Types Boolean Integer Real String
UML Classifiers are types in OCL if expression is attached to the model

79. OCL Operations Boolean and or xor not implies if-then-else
Integer * + - / abs()
Real * + - / floor()
String toUpper() concat()

80. Let Expression Allows local reuse of an expression context Person inv:
let income : Integer = self.job.salary->sum()
let hasTitle(t : String) : Boolean =
self.job->exists(title = t) in
if isUnemployed then
self.income < 100
else
self.income >= 100 and self.hasTitle(‘manager’)
endif

81. Definition Constraint
Allows global reuse of an expression
context Person def:
let income : Integer = self.job.salary->sum()
let hasTitle(t : String) : Boolean =
self.job->exists(title = t)

82. OCL Example Married people are of age >= 18
context Person inv:
self.wife->notEmpty() implies self.wife.age >= 18 and
self.husband->notEmpty() implies self.husband.age >= 18
A company has at most 50 employees
context Company inv:
self.employee->size() <= 50