Architecture and Design Computer Science 320 Fall 2010 Prof. Leon Osterweil Course Roadmap • Preliminary Requirements Review Reactions – Today • Final Requirements Review – Oct. 14 • Peer Evaluations – Due Oct. 14 • Architecture Presentations by Company Heads – Preliminary Oct. 21 (?) – Final(?) on Oct. 26 • Preliminary Designs by teams – Nov. 4 (?) Preliminary Requirements Review • Quick reactions? • Level of Participation – Attendance – Interaction • Main issues raised – Stakeholders – Versioning – System Test Planning Final Requirements Review • Oct. 14 • Written Requirements due on Oct. 13 by 8PM • Focus on issues raised • Focus on system test planning • Anticipation of Architecture and Design Peer Evaluations • Submit by email to David Arbour – Due by 5PM on Oct. 14. • For each teammate (not including yourself): – Points out of 100 – Paragraph characterizing participation • Company leaders will, for each team member give: – Points out of 100 – Paragraph characterizing participation It would be a good idea for each group to have a conversation setting evaluation criteria Architecture Presentations • Made by company leaders • Preliminary will be on, or about, Oct. 21 • Final will be about one week later • Architecture is to be – Discussed by company, led by leader – Agreed to by company – Presented by company leader
24
Embed
Preliminary Requirements Review Final Requirements Reviewlaser.cs.umass.edu/courses/cs320.Fall12/documents/architectureanddesignr-6.pdfArchitecture and Design Computer Science 320!
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
– Due Oct. 14 • Architecture Presentations by Company Heads
– Preliminary Oct. 21 (?) – Final(?) on Oct. 26
• Preliminary Designs by teams – Nov. 4 (?)
Preliminary Requirements Review
• Quick reactions? • Level of Participation
– Attendance – Interaction
• Main issues raised – Stakeholders – Versioning – System Test Planning
Final Requirements Review
• Oct. 14 • Written Requirements due on Oct. 13 by 8PM • Focus on issues raised • Focus on system test planning • Anticipation of Architecture and Design
Peer Evaluations
• Submit by email to David Arbour – Due by 5PM on Oct. 14.
• For each teammate (not including yourself): – Points out of 100 – Paragraph characterizing participation
• Company leaders will, for each team member give: – Points out of 100 – Paragraph characterizing participation It would be a good idea for each group to have a conversation setting evaluation criteria
Architecture Presentations
• Made by company leaders • Preliminary will be on, or about, Oct. 21 • Final will be about one week later • Architecture is to be
– Discussed by company, led by leader – Agreed to by company – Presented by company leader
Design Presentations
• Preliminary presentations about one week after final Architecture presentation
Requirements Spec.!
Test Plan!
Test Results must !match required behavior!
Design!
Characteristics of!System to be ! built must!match required!characteristics!
Architecture!
(low level)!Design!
Code!
Code must!implement!design!
Hi level design must!show HOW requirements!can be met!
consistent!views!
Test plan!exercises!this code!
Design is essentially a modeling activity!
What is the Nature of Design? • Addresses the question: HOW? • Goal: Indicate how to develop a solution system that
will satisfy requirements • Complements:
– Requirements: WHAT – System Test Plan: HOW WOULD I KNOW IT IF I
SAW IT • Design is a very broad and encompassing area
– Hard to separate it from requirements – Hard to separate it from code
• Too hard to be done in one large step – Especially because of execution platform variation
How Does One Go About Designing
• Process by which design is built is understandably complex
• Various authors have differing ideas about this – Brooks’ book has good ideas about this
• For this course, we separate WHAT from HOW
What Do Designs Model (and Why)?
• Conceptual, architectural, high-level designs model how requirements might be met – Vehicles for "what-if" discussions – Help clarify requirements--by being related to them – Often merge and intersperse with requirements – Help suggest implementation issues/concerns
• Coding specs model the form, content, structure of the eventual code – Increasing emphasis on evolvability, rapid
modification, and flexible deployment
How are Designs Represented?
• Familiar approaches – Use of hierarchy to conquer size/complexity – Use of multiple views to capture different
aspects – Use of pictures and diagrams to appeal to non-
technical stakeholders • Connected to requirements elements they
respond to • Connected to code elements that implement them
Design by Stepwise Refinement
• Top-down technique for decomposing an architecture into lower levels
• Proceed by: – Isolating design aspects that are not interdependent – Postponing representation choices as long as possible – Showing that each successive refinement step is a
faithful expansion of the previous steps
Design by Stepwise Refinement
``Divide and Conquer''!• start with system function!• break into major functions!• break each into sub-functions!• concurrently refine program and data!• continue until implementation is “immediate”!
• Top-down technique for decomposing an architecture into lower levels
• Proceed by: – Isolating design aspects that are not interdependent – Postponing representation choices as long as possible – Showing that each successive refinement step is a
• Output: an alphabetized, permuted index – Computer Fun <reference 3> – Computers in Crime <reference 1> – Computers, The Fastest <reference 2> – Crime, Computers in <reference 1> – Fastest Computers, The <reference 2> – Fun, Computer <reference 3> – in Crime, Computers <reference 1> – The Fastest Computers <reference 2>
Data Flow Diagram Design for First KWIC Decomposition
title_list!
title_list!
all_perms!
sorted_perms!
sorted_!perms!
input_titles!
permuter!
sort_titles!
output_titles!
Stepwise Refinement Step 1: Print_Kwic (title_list); Step 2: Print_Kwic: input all titles; generate and save all interesting circular shifts; alphabetize saved lines; print alphabetized lines;
Step 3b: generate and save all interesting circular shifts: for each line in input do begin generate and save all interesting
circular shifts of this line; end;
More Detailed DFD Title_list!
title_list!
all_perms!
sorted_perms!
input_titles!
permuter!
sort_titles!
output titles!
Title_Lists_Store!
title_list!
all_perms!
sorted_perms!
title list!info!
circular!shifts!info!
alpha!list!info!
sorted_!perms!
CFG for permuter first title"location"
input titles"store"
retrieve next"title"
raw title"
permute"one title"
permuted titles"store"
is this"last title?"
number"of titles"
current title"count"
yes"
no"
permuted " titles"info"
Leads to more Detailed DFD title_list!
title_list!
all_perms!
sorted_perms!
input_titles!
permuter!
sort_titles!
output titles!
title_list!
all_perms!
sorted_perms!
title list!info!
circular!shifts!info!
alpha!list!info!
sorted_!perms!
title_list! all_perms! sorted!_perms!
Title_Lists_Store!
Refinement of Title_Lists_Store • title_list entries:
– Packed 4 characters per word • all_perms entries:
– A vector of indices, showing starting address of each title • sorted_perms entries: same idea….
(Don't duplicate storage of each line as a result of ``generating'' circular shifts)"all_perms:"
Address"of this title"
Address of 1st character" of this permuation"
sorted_perms:"Same idea as all_perms"
After Input_Titles
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List ….
….
After Permuter
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
All_Perms ….
….
….
….
After Permuter
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
All_Perms ….
….
….
….
Before Sort_Titles
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
All_Perms
Sorted_Perms
….
….
….
….
….
….
After Sort_Titles
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
All_Perms
Sorted_Perms
….
….
….
….
….
….
Before Output_Titles
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
All_Perms
Sorted_Perms
….
….
….
….
….
….
Before Sort_Titles
C o m p
u t e r
F u n
C o m
p u t e
r s I
n C r
(space)
(space)
(space)
(end of title)
Title_List
Sorted_Perms
….
….
….
….
More Detailed DFD title-list!
title_list!
all_perms!
sorted_perms!
input_titles!
permuter!
sort_titles!
output titles!
title_list!
all_perms!
sorted_perms!
title list!info!
circular!shifts!info!
alpha!list!info!
sorted_!perms!
title_list! all_perms! sorted!_perms!
Title_Lists_Store!
circular!shifts!info!
Now includes Pointers to each Permutation Starting point
Now includes Pointers to each Sorted Permutation Starting point
There are Big Problems With this Approach
• Probably more suitable at the conceptual level • But less suitable as an implementation approach • We will see some specifics soon
Peer Evaluations
• Submit by email to David Arbour – Due by 5PM on Oct. 14.
• For each teammate (not including yourself): – Points out of 100 – Paragraph characterizing participation
• Company leaders will, for each team member give: – Points out of 100 – Paragraph characterizing participation It would be a good idea for each group to have a conversation setting evaluation criteria
Architecture Presentations
• Made by company leaders • Preliminary will be on, Oct. 26 • Final will be one week later • Architecture is to be
– Discussed by company, led by leader – Agreed to by company – Presented by company leader
Design Presentations
• Preliminary presentations about one week after final Architecture presentation
• Depends on how quickly we move through the lecture material
Requirements Spec.!
Test Plan!
Test Results must !match required behavior!
Design!
Characteristics of!System to be ! built must!match required!characteristics!
Architecture!
(low level)!Design!
Code!
Code must!implement!design!
Hi level design must!show HOW requirements!can be met!
consistent!views!
Test plan!exercises!this code!
Software Architecture vs. Design • Architecture
– High level system design – Concerned with components and the interactions
among components, and with the world – Not with the algorithms or data structures
• Low Level Design (coding specs?) – Emphasis on data structures and algorithms – Focus on implementation issues
• Stepwise refinement • Evolvability • Use of abstraction
• Illustrative example coming up soon
Central Entities in a Software Architecture
• Components--conceptual computational capabilities – Subsystems – Data Stores – Objects – Where do they reside?
• Connectors--interaction models – Which components are connected to which? – How are they connected? – What semantics do the connectors have?
Case Study: A system for simulating systems
• What is a simulation? – Representation internal to computer of how a
system will behave • Why simulate?
– See what characteristics system will have before committing to building it
– Evaluate alternatives • Some examples:
– Electronic election system – System for treating emergency room patients – System for automatically testing computer software
(Very) High Level Requirements
• Functional – Inputs:
• System model • Models of behaviors/performance of
participants • Desired kinds of outputs
– Outputs • Performance characteristics
More Requirements
• Environmental – User Interface
• Easy to input simulation parameters • Easy to configure output reports • Easy to monitor progress of simulation
– Interfaces • Must interface with existing systems that
will support the proposed system
More Requirements
• Speed/Efficiency – Much faster than the real system – Fast enough to support decisions
• Accuracy – Results need to conform to what real system
would do • Flexibility
– Easy to change all inputs – Easy to model all kinds of systems
Notes on these Requirements
• Very high-level and vague • Not at all complete • MUCH MORE DETAIL AND SPECIFICATION ARE
REQUIRED BEFORE ACTUALLY ARCHITECTING, DESIGNING, IMPLEMENTING – So this is only to give an idea of what an
architecture is like….
Architecture definition
• A high level specification that defines the components, connectors, constraints and the inter-relationships among these entities
• The basis for evaluating how well an architecture satisfies a requirement specification
• The basis for beginning work on coding specifications
Agenda Manager
Agent Manager
Agendas
Artifact Manager
System Model
Non-Human Agents
Step Sequencer
Outputs
Agenda Item
Example: System Interpreter Architecture
Human Agents
Agenda Manager
Agent Manager
Agendas
Simulated Human Agents
Artifact Manager
Non-Human Agents
Agent Behaviors
Step Sequencer
Simulation Results
User TimeLine
Agent Behaviors Specification
Events
Agenda Item
Example: A Simulator Architecture
How well does this architecture meet the requirements?
• Functional • Environmental
– User Interfaces – Other systems
• Speed/efficiency • Accuracy
Different issues require different approaches
• Functional requirements – Maybe OK based upon our diagram
• User interface – Diagram is no help at all – But, note different types of “users”
• Other Systems – Some hope for understanding that
• Efficiency – No help
• Accuracy – No help
Some notations used to define software architectures
• Data Flow Diagrams (DFDs) • Finite State Machines (FSAs) • Class Diagrams • UML • Message Sequence Charts • BOOD (Booch Object Oriented Design) • JSD (Jackson System Development) • RDM (Rational Design Method) • Shlaer-Mellor • ...
Some notations used to define software architectures
• Data Flow Diagrams (DFDs) • Finite State Machines (FSAs) • Class Diagrams • UML • Message Sequence Charts • BOOD (Booch Object Oriented Design) • JSD (Jackson System Development) • RDM (Rational Design Method) • Shlaer-Mellor • ... These are notations:
What are they used for?
What kinds of things are they used to model?
• User Modeling – By means of Use Cases
• Interaction Modeling – By means of “Ladder diagrams”
• Real World interaction modeling – JSD
• Real World State modeling – E.g. Finite State Machines
What kinds of things are they used to model?
• User Modeling – By means of Use Cases
• Interaction Modeling – By means of “Ladder diagrams”
• Real World interaction modeling – JSD
• Real World State modeling – E.g. Finite State Machines
And many others
What kinds of things are they used to model?
• User Modeling – By means of Use Cases
• Interaction Modeling – By means of “Ladder diagrams”
• Real World interaction modeling – JSD
• Real World State modeling – E.g. Finite State Machines
An architecture definition usually employs Various notations to build various models
Flow Diagrams
• Support modeling functionality • Can be helpful in supporting speed/efficiency • Can show roles of different agents (?) • BUT: Our example shows how limited they are
Use Cases • Specify “actors” and how they interact with
system • System is a collection of “use
cases” (ie.functional capabilities) • Represented using schemas and diagrams • Diagrams show flow of “uses” between
actors and use cases • An Important emphasis of architecture
– Who does what when and why
Use Case diagrams
functions
communications
Use Case schema
Sequence Diagrams
• Sometimes called “ladder charts” • Represent a particular sequence of messages
exchanged between entities • Popular in object-oriented methods to
represent communications between objects • Shows one particular communication
sequence in one run of the system – Shows behavior as well as communication
• Can be extended with conventions to represent looping, casing, timeouts, global conditions across different entities, delayed message reception, etc.
Sequence Diagrams
communicating entities time
message
Collaboration Diagrams • Popular in object-oriented methods to represent message exchanges between objects
• UML extended with annotations that represent dataflows between the communicating objects
• Differ from other notations – Nodes represent objects, not activities (as in DFDs, activity diagrams, activity charts, and block diagrams)
– Nodes represent object instances, not object classes
• As in sequence diagrams, represent the sequence of messages in one particular scenario, not all possible communications scenarios.
Collaboration Diagrams
entity
communication
Class diagram for juice plant
additional object class • would be modeled by a control process in dataflow models.
Finite State Machines • Primary appeal is visualizability--clarity! --Circles represent states! --(Curved) arrows represent transitions! --Arrows are annotated with inputs!
• Intuitively: Can "watch" a stream of inputs "drive"! the behavior of the system as a sequence of movements! from state to state!
Finite State Machine for Digital Watch
Time display mode
Datebook!mode!
Phone book!mode!
Alarm display!mode!
press button A
press button A
press button A
press button A
More Finite State Machine Details
Time display mode
Datebook!mode!
Phone book!mode!
Alarm display!mode!
press button A
press button A
press button A
press button A
Time set mode
press button B
press button B
Datebook set mode
press button B press
button B
Datebook query mode
press button C
press button C
press button B
Phone book set mode
press button B
Phone book query mode
press button C
press button B
press button B
press button C
Alarm set mode
press button B
press button B
JSD (Jackson System Design)
• Real-world modeling – Model types of entities in the world – Model the actions they perform and suffer
• Model their interactions – How they affect each other – How they communicate with each other
• System design is evolved from that
The Library Book Process The Library Book Process
Alternation"
Multiple Instantiation"
Two More Processes
The Book Process
With Actions and Attributes
Course Project Architectures
• Done by company managers • Will provide the structure within which teams
define and design their modules • Will use various diagrams as appropriate
– (Optional) UML text has details of UML – (Optional) Jalote text has details of other
notations • Done in collaboration/consultation with entire team
Requirements Spec.!
Test Plan!
Test Results must !match required behavior!
Design!
Characteristics of!System to be ! built must!match required!characteristics!
Architecture!
(low level)!Design!
Code!
Code must!implement!design!
Hi level design must!show HOW requirements!can be met!
consistent!views!
Test plan!exercises!this code!
Software Architecture vs. Design • Architecture
– High level system design – Concerned with components and the interactions
among components, and with the world – Not with the algorithms or data structures
• Low Level Design (coding specs?) – Emphasis on data structures and algorithms – Focus on implementation issues
• Stepwise refinement • Evolvability • Use of abstraction
• Illustrative example coming up soon
Requirements Spec.!
Test Plan!
Test Results must !match required behavior!
Design!
Characteristics of!System to be ! built must!match required!characteristics!
Architecture!
(low level)!Design!
Code!
Code must!implement!design!
Hi level design must!show HOW requirements!can be met!
consistent!views!
Test plan!exercises!this code!
The Focus of Lower Level/Implementation-Oriented Software
Design is on Modules
What is a Module?
What is a Module? • Notion of module is defined carefully by Parnas
What is a Module? • Notion of module is defined carefully by Parnas • Module is the locus of responsibility for a function or
task – Hides decision(s) about implementation – May be nested – Provides services only through strict, impenetrable
interfaces – Intended to be replaceable by alternate(s) having
the same interface(s) to facilitate system migration
What is a Module? • Notion of module is defined carefully by Parnas • Module is the locus of responsibility for a function or
task – Hides decision(s) about implementation – May be nested – Provides services only through strict, impenetrable
interfaces – Intended to be replaceable by alternate(s) having
the same interface(s) to facilitate system migration • A modular system is typically built as hierarchical
family of modules – Basis for conceptualization of system – Basis for implementation of system
Information Hiding • Each design unit hides internal details of processing
activities • Design units communicate only through well-defined
interfaces (as opposed, e.g. to global variables) • Each design unit is specified by as little information as
possible • If internal details change, client units should need no
change • Example decisions to hide ?
Information Hiding • Each design unit hides internal details of processing
activities • Design units communicate only through well-defined
interfaces (as opposed, e.g. to global variables) • Each design unit is specified by as little information as
possible • If internal details change, client units should need no
change • Example decisions to hide
– Algorithms – Data representations – Lower-level modules – Policies
The Typical Alternative: Design by Stepwise Refinement
• Top-down technique for decomposing an architecture into lower levels
• Proceed by: – Isolating design aspects that are not interdependent – Postponing representation choices as long as possible – Showing that each successive refinement step is a
faithful expansion of the previous steps
The Typical Alternative: Design by Stepwise Refinement
``Divide and Conquer''!• start with system function!• break into major functions!• break each into sub-functions!• concurrently refine program and data!• continue until implementation is “immediate”!
• Top-down technique for decomposing a design into lower levels
• Proceed by: – Isolating design aspects that are not interdependent – Postponing representation choices as long as possible – Showing that each successive refinement step is a
faithful expansion of the previous steps
Problems with Stepwise Refinement • What's the basis for determining whether design
aspects are interdependent? • Later design decisions depend on earlier ones.
– But what is the basis for choosing the initial decision to make?
• Once a representation decision is made, further decomposition decisions depend on it.
• Promotes development of a sequential design solution (as opposed to concurrent)
• If the initial function is ``huge'' how do you start to decompose it?
• Internal representation of data to be processed • Representation of circular shifts • Time at which circular shifts are computed • Method of alphabetization (sorting) • Time at which alphabetization is carried out • Input formats • Output formats
Modularized Design
• Line Storage is a module • Defined in terms of its interfaces • Other modules use this by method calls • Internal implementation details invisible • This facilitates
– Change of line storage implementation details – Parallel development of modules – Module interchanging
Before title_list!
title_list!
all_perms!
sorted_perms!
input_titles!
permuter!
sort_titles!
output titles!
title_list!
all_perms!
sorted_perms!
title list!info!
circular!shifts!info!
alpha!list!info!
sorted_!perms!
title_list! all_perms! sorted!_perms!
Title_Lists_Store!
Before title-list!
title_list!
all_perms!
sorted_perms!
input_titles!
permuter!
sort_titles!
output titles!
title_list!
all_perms!
sorted_perms!
title list!info!
circular!shifts!info!
alpha!list!info!
sorted_!perms!
title_list! all_perms! sorted!_perms!
Title_Lists_Store!
Decisions about"storage of titles,"permutations, sorted"permutations are not"hidden"
Changes must be"agreed upon by"others"
After title-list!
input_titles!
permuter!
sort_titles!
output titles!
Line_Storage!
sorted_!perms!
Print_KWIC!
represents procedure invocation!
Line_Storage Interface
• Line_Storage – char (r,w,c) --- returns the c-th character in
the w-th word in the r-th input line – setchar (r,w,c,d) --- performs char (r,w,c) := d – words(r) --- number of words in line r – numchars(r,w) --- number of characters in w-
th word of line r – others are also possible (e.g. numlines,
setword), depending upon needs of other modules
sort_titles Interface
sort_titles – alph --- performs module initialization – ith (i) --- index of the circular shift that comes i-th
in alphabetical order
permuter Interface • permuter
– Assumptions: • if i<j then shifts of input line i precede shifts of input
line j in the ordering of all shifts maintained by this module
• initial shift of a given title is the original line, next is one-word rotation, etc.
– cs_char (l,w,c) --- returns the c-th character of the w-th word in the l-th circular shift
– cs_words (l) --- number of words in l-th circular shift – (num_shifts(r) --- number of shifts generatable from
input line r --- is a redundant, but related notion) – ... – cs_setup --- performs module initialization
Design Decisions, Revisited • All shifts will be stored
– As opposed to computed on demand – Assumes you have enough memory to store everything
Design Decisions, Revisited • All shifts will be stored
– As opposed to computed on demand – Assumes you have enough memory to store everything
• All circular shifts generated before alphabetization begins – Precluding use of an insertion sort running
concurrently or as a coroutine with the shift generator
Design Decisions, Revisited • All shifts will be stored
– As opposed to computed on demand – Assumes you have enough memory to store everything
• All circular shifts generated before alphabetization begins – Precluding use of an insertion sort running
concurrently or as a coroutine with the shift generator • Alphabetical orderings completed before printing begins
– Precluding concurrency and demanding more storage – (e.g. after first half printed, storage could be reused)
Design Decisions, Revisited • All shifts will be stored
– As opposed to computed on demand – Assumes you have enough memory to store everything
• All circular shifts generated before alphabetization begins – Precluding use of an insertion sort running
concurrently or as a coroutine with the shift generator • Alphabetical orderings completed before printing begins
– Precluding concurrency and demanding more storage – (e.g. after first half printed, storage could be reused)
• Do all shifts of one line before any shifts of another – Perhaps faster to do all first shifts first, then – alphabetization of them, then second shifts...
Design Decisions, Revisited • All shifts will be stored
– As opposed to computed on demand – Assumes you have enough memory to store everything
• All circular shifts generated before alphabetization begins – Precluding use of an insertion sort running
concurrently or as a coroutine with the shift generator • Alphabetical orderings completed before printing begins
– Precluding concurrency and demanding more storage – (e.g. after first half printed, storage could be reused)
• Do all shifts of one line before any shifts of another – Perhaps faster to do all first shifts first, then – alphabetization of them, then second shifts...
• ``Uninteresting'' shifts eliminated when shifts generated – Burying this policy decision within the shift generator
Differences • Are in the way the modules are divided into work
assignments and in the the interfaces between modules • Changeability
– E.g., Changing property 1 (internal data representation) could cause change in all modules of first scheme (and in only one of second scheme)
• Independent Development – Scheme 1: formats and table organizations are
complex and (too) essential to efficiency – Scheme 2: interfaces more abstract, containing
function names and their parameters • Comprehensibility
– In order to understand the output module in Scheme 1 you need to understand previous modules, the "whole system", as opposed to just one module in Scheme 2.
Some Observations • Scheme 1: makes each major step in processing a module • Scheme 2: uses information hiding, where modules need
not correspond to processing steps – E.g. alphabetization may or may not correspond to a
processing phase – Every module in Scheme 2 is characterized by its
knowledge of a design decision which it hides from the others
• (Start decomposition with a list of design decisions!) – Interfaces reveal as little as necessary about internal
module workings – Scheme 1 has important design decisions visible in
interfaces • Clean decomposition and hierarchical structure are
independent properties of system structure
Structure of your Design Specification • Module List
– Enumeration of all modules • Module Interface Specifications
– How modules can be accessed and exploited – Interface methods, for example
• Interaction Hierarchy – Which modules depend upon which others – And in which ways
• Internal Structure of Modules – Probably should be hierarchical – Lowest level of hierarchy should be close to
coding specifications • Description of the information being hidden by the
module
Module List
• Could be a list of modules • Could have the list structured • Redundant with later specifications
E.g. DFD for KWIC Decomposition
title_list!
title_list!
all_perms!
sorted_perms!
sorted_!perms!
input_titles!
permuter!
sort_titles!
output_titles!
Or as an invocation structure title-list!
input_titles!
permuter!
sort_titles!
output titles!
Line_Storage!
sorted_!perms!
Print_KWIC!
represents procedure invocation!
Module Interface Specifications
• Here are some examples that we just saw
What secret(s) does each hide?!
Line_Storage Interface
• Line_Storage – char (r,w,c) --- returns the c-th character in
the w-th word in the r-th input line – setchar (r,w,c,d) --- performs char (r,w,c) := d – words(r) --- number of words in line r – numchars(r,w) --- number of characters in w-
th word of line r – others are also possible (e.g. numlines,
setword), depending upon needs of other modules
sort_titles Interface
sort_titles – alph --- performs module initialization – ith (i) --- index of the circular shift that comes i-th
in alphabetical order
permuter Interface • permuter
– Assumptions: • if i<j then shifts of input line i precede shifts of input line j in the
ordering of all shifts maintained by this module • initial shift of a given title is the original line, next is one-word
rotation, etc. – cs_char (l,w,c) --- returns the c-th character of the w-th word in the
l-th circular shift – cs_words (l) --- number of words in l-th circular shift – (num_shifts(r) --- number of shifts generatable from input line r ---
is a redundant, but related notion) – ... – cs_setup --- performs module initialization
Interaction Hierarchy
• A structure showing which modules interact with each other in which ways
Invocation interactions title_list!
input_titles!
permuter!
sort_titles!
output titles!
Line_Storage!
sorted_!perms!
Print_KWIC!
represents procedure invocation!
Internal Structure of Modules
• Saw some of that in some of the module interfaces
permuter Interface • permuter
– Assumptions: • if i<j then shifts of input line i precede shifts of input
line j in the ordering of all shifts maintained by this module
• initial shift of a given title is the original line, next is one-word rotation, etc.
– cs_char (l,w,c) --- returns the c-th character of the w-th word in the l-th circular shift
– cs_words (l) --- number of words in l-th circular shift – (num_shifts(r) --- number of shifts generatable from
input line r --- is a redundant, but related notion) – ... – cs_setup --- performs module initialization
• Might be some utilities used to facilitate doing this • If so, then indicate that here
Information being hidden
• Data structures • Algorithms • Implementation tricks • Other modules used • Other external capabilities used
Structure of your Design Specification • Module List
– Enumeration of all modules • Module Interface Specifications
– How modules can be accessed and exploited – Interface methods, for example
• Interaction Hierarchy – Which modules depend upon which others – And in which ways
• Internal Structure of Modules – Probably should be hierarchical – Lowest level of hierarchy should be close to
coding specifications • Description of the information being hidden by the
module
Connecting Design and Requirements
• Important to verify internal consistency of design • Important to verify that design is consistent with
requirements • Important to use design to complete
requirements • All of the above are done better when design (and
requirements) are defined more rigorously
Object Oriented Design • Focus is on later stages of design and on coding!
• Philosophically derived from Parnas modularity ideas!
• Stresses importance of modeling the real world!
• Primary focus is on data, not on activities!
• Currently the most popular design methodology approach!
• Wide variety of adaptations of this idea!
• Often used subsequent to high-level/architectural! design!
History • Related to/descended from Parnas notion of Module!
• In keeping with popular emphasis on reuse, !!comprehensibility!
• Interest strengthened by disillusion with older design! ideas (eg. iterative refinement)!
OOD Characteristics
• Primary organization of design is as a collection of objects!
• Activities are organized according to objects they affect !
• Stresses importance of insulation from effects of change!
• More focus on potentially reusable components!
• Claim: Design is clearer, more modifiable!
• Strongly suggests implementation modules!
• Meshes nicely with modern languages that emphasize! strong support for Modularity (e.g. Java) !
What is an Object? According to Booch: It is an entity that!
• Has state! --Distinguishes this clearly from a function/activity!
• Is characterized by actions it suffers/requires of other !!objects!
• Is an instance of a class or type!
• Is denoted by a name! --But may have many names (aliases)!
• Has restricted visibility to (and by) other objects!
• Is divided into two parts: specification and implementation! --Implementation may be in terms of other objects!
Characteristics of Classes/Objects • A Class is very much like a type! --It usually has instances! --It has operations upon it!
• Class is defined in terms of its operations (methods)! --Not in terms of its structure/representation/etc.!
• Class may have attributes! --Often defined as values returned by methods!
• Operations are defined as part of the type, but operate on! instances, not on the type itself! --Similarly for attributes!
• Two types of operations:! --Constructors change object state (eg. by creating it,! destroying it, changing it in some way)! --Selectors gain access to all or part of the state! --Booch adds iterators, enables visiting all objects in a class!
Inheritance • Not all authors (eg. Booch) consider inheritance to be! essential to object-orientedness!• Inheritance is a way of organizing/classifying the classes! in a system, organization, etc.!
!--It facilitates reuse!• Classes organized into hierarchies!• Child classes are elaborations on their ancestor classes! --Add new methods and/or attributes!• Helps develop new classes (build upon the old ones)!• Helps developers find classes (follow the hierarchy down)!• But, the world is generally not strictly hierarchical! --Often classes may need to inherit from more than one! line of descent (multiple inheritance)! --Often classes have methods that descendents don't need! --Often classes need to override methods from ancestors!• These needs lead to various multiple inheritance schemes!• None of this seems integral to OOD!