Preliminary Requirements Review Final Requirements...

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

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 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”!

KWIC Index Example Input: a file of titles!

``Computers in Crime'' <reference 1>!``The Fastest Computers'' <reference 2>!``Computer Fun'' <reference 3>!

•  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!

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"

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!

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

p u t e

(space)

(end of title)

Title_List ….

After Permuter

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms ….

After Permuter

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms ….

Before Sort_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

After Sort_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

Before Output_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

Before Sort_Titles

C o m p

u t e r

p u t e

(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!

alpha!list!info!

sorted_!perms!

Title_Lists_Store!

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!

Design!

Architecture!

(low level)!Design!

consistent!views!

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

And many others

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

More Finite State Machine Details

Time display mode

Datebook!mode!

Phone book!mode!

Alarm display!mode!

press button A

Time set mode

press button B

Datebook set mode

press button B press

button B

Datebook query mode

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 C

Alarm set mode

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!

Design!

Architecture!

(low level)!Design!

consistent!views!

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!

Design!

Architecture!

(low level)!Design!

consistent!views!

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

``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

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?

KWIC Index Example Input: a file of titles!

``Computers in Crime'' <reference 1>!``The Fastest Computers'' <reference 2>!``Computer Fun'' <reference 3>!

•  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!

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!

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"

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!

alpha!list!info!

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

p u t e

(space)

(end of title)

Title_List ….

After Permuter

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms ….

After Permuter

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms ….

Before Sort_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

After Sort_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

Before Output_Titles

C o m p

u t e r

p u t e

(space)

(end of title)

Title_List

All_Perms

Sorted_Perms

Before Sort_Titles

C o m p

u t e r

p u t e

(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!

alpha!list!info!

sorted_!perms!

Title_Lists_Store!

Now includes Pointers to each Permutation Starting point

Now includes Pointers to each Sorted Permutation Starting point

Design Decisions Implied

•  All shifts will be stored (in the indices) •  All circular shifts will be generated before

alphabetization begins •  Alphabetical orderings will be completed before

printing begins •  All shifts of one line developed before any shifts

of another line •  ``Uninteresting'' shifts eliminated at the time the

shifts are generated

Recall: Problems with Stepwise Refinement

•  What's the basis for determining whether design aspects are interdependent?

•  Later design decisions depend on earlier ones. [Same for information hiding.] –  But what is the basis for choosing the initial

decision to make? •  Once a representation decision is made, all

successive design decisions in that subtree of refinements may be dependent 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?

The Information Hiding Alternative

•  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

Examples of Information to Hide

•  Algorithms •  Data Representations •  Lower Level Modules •  Policies

Information Hiding in our Example

•  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!

alpha!list!info!

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!

alpha!list!info!

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

•  All circular shifts generated before alphabetization begins –  Precluding use of an insertion sort running

concurrently or as a coroutine with the shift generator

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...

– 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

– 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!

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!

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

–  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!

Internal Structure of Modules

•  Saw some of that in some of the module interfaces

–  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!

Components of an OOD Product

• List of classes!

• Attributes for each class!

• Operations (methods) for each class!

• Interobject visibility!

• Object interfaces!

• Implementations of objects!

Various OOD’s

•  BOOD (Booch Object Oriented Design) •  OMT (Rumbaugh)

–  Very similar to Booch –  But more diagram(s)

•  Jacobsen Use Cases –  Strong similarity to JSD (soon) –  Emphasis more on early phases

•  Shlaer-Mellor •  Etc., etc.

UML (Unified Modeling Language)

•  Merger of Booch, Rumbaugh, Jacobsen work – “The three amigos”

•  Comprehensive suite of diagrams – DFDs, CFGs, MSCs, FSAs, etc……

•  Some semantics in place – But not all

•  Processes for using them have been developed •  Currently a tidal wave of acceptance/adoption

Preliminary Requirements Review Final Requirements...

Documents

ReiningintheOutliersinMap-ReduceClustersusingMantriminlanyu.seas.harvard.edu/teach/csci599-fall12/papers/mantri_osdi1… · ReiningintheOutliersinMap-ReduceClustersusingMantri GaneshAnanthanarayanan†⋄

Cn Fall12 CH2

Scalable Internet Architecturesassets.en.oreilly.com/1/event/44/Scalable Internet Architectures Presentation 2.pdfArchitecture / discipline • Discipline is important in any job

Cn Fall12 CH1

Introduction to Database CS320 IS320 CS370 Lab #1 · Introduction to Database CS320 –IS320 –CS370 Lab #1. Agenda What is DBMS ? History of DBMS Introducing SQL and its relation

Tamanoi Mid Fall12

VLSI System Testing - people.ee.duke.edupeople.ee.duke.edu/~krish/teaching/ECE538/Overview2018.pdfarchitecture, VLSI design? ... –Worked on complex software development projects?

Business Alumni Magazine (Fall12/Winter 13)

CS320 - Scala Seminar Introduction to Functional Programming · / 84 CS320 - Scala Seminar Introduction to Functional Programming Jaemin Hong hjm0901@gmail.com September 5, 2018!1

Bb Childhood Diseases Fall12(1)

Fall12 Books Catalog

Retail Catalog Fall12 Linkable

Bb Musculoskeletal Fall12

Green River Community College Fall12 Schedule

RAPIDbus Architecture and Realization › pub_files › pub3 › willis_john_c_1982_1 › willis_john_c_1982_1.pdfArchitecture and Realization Abstract R APIDbus: Architecture and

SITKA Fall12 catalog

CS320 Digital Thermopile Pyranometer

CS320: Performance Evaluation Plotting data sets Semi log plots …cs320/fall20/slides/06... · 2020. 10. 23. · Semi log plot: y–axis on log scale x-axis linear slope: log base

Engl1102 Fall12 Nagel

CS320 Web and Internet Programming Java Beans and Expression Language (EL) Chengyu Sun California State University, Los Angeles