Intermediate Software Engineering 2

1
Intermediate Software Engineering 2

• Design
• to work out the structure or form of something,
  by making a sketch, outline or pattern, or plans
• The designers goal is to produce a model or
  representation of a thing which is to be built

2
Design

• 1st stage of transformation of spec into code
• Translates what of spec into how of solution
• Includes design of the software, modules and
  their interactions, data structures, choice of
  algorithms
• Various structured methods exist, consisting of
  a set of guidelines and notation for creating a
  good design, embodying good software engineering
  principles (maintainability, reliability ...)

3
Design Methodologies

• 5 main design methodologies
• Structured or Top-Down Functional design
• Yourdon, Constantine, Jackson etc
• Most widely used methodology
• System viewed as a series of functions
• Design is refined iteratively
• Object-Oriented design
• More recent development
• System viewed as a collection of objects rather
  than functions
• Data-Driven design
• User Interface design / user-centred design
• Prototyping

4
Prototyping (1)

• See Sommerville p 138 - 144
• Software customers and end users usually find it
  very difficult to express their real
  requirements. There is no real substitute for
  trying out a requirement before committing to it.
  This is possible if a prototype of the system to
  be developed is available.
• System prototypes allow users to experiment with
  requirements and to see how the system supports
  their work.

5
Prototyping (2)

• The objective of evolutionary prototyping is to
  deliver a working system to end-users.
• The objective of throw-away prototyping is to
  validate or derive the system requirements (e.g.
  build a system like this one.
• Evolutionary prototyping used where it is
  difficult or impossible to develop a detailed
  system specification e.g. AI experiments.
• Cant use throw-away prototypes as the final
  system changes made during prototype development
  will degrade the system structure.

6
Design Notation

• 3 main types make up the design documentation
• Graphical notations
• display the components of the system and their
  relationships
• give an excellent overall picture
• Program Description Languages (PDLs)
• resemble pseudo-code
• include parameters, functions and return values
• loose form of Ada often used
• Natural language
• used when more formal notations cannot provide
  the full picture

7
Levels of Abstraction

• The human mind cannot consider the whole problem
  at once
• We can only understand one part of the system at
  a time
• We can consider it in levels of abstraction
• broad terms
• slightly more detail
• final detail
• Design is therefore iterative

8
Stepwise Refinement

• How do we arrive at the different levels of
  abstraction?
• We decompose the complexity of the problem,
  iteratively, into smaller and smaller, less
  complex and more manageable parts or modules
• For example, one module representing a whole VB
  or C program would (hopefully) be decomposed into
  smaller modules representing functions or
  procedures
• Each module should have 1 role, i.e. should do 1
  thing, or else should be further decomposed
• Think about entering a room through a closed
  door

9
Structured or Top-Down Functional Design

• Basic component is a function rather than an
  object
• Involves data flow diagrams (DFDs), structure
  charts, data dictionaries, state transition
  diagrams (STDs)
• Very well developed and documented methodology
• Familiar
• The most appropriate methodology for systems
  which share little data and are naturally
  functional in nature e.g. cash dispenser systems

10
Cash Dispenser SystemUnderstanding how system
works is based on the identification of its
functions, which are largely independent of each
other and so a functional design is appropriate

• display Welcome message and ask for card to be
  inserted
• read in PIN number
• get account details from database
• devour card (wrong PIN number)

• throw up menu screen
• dispense cash
• order chequebook
• order statement
• print balance
• eject card and request its removal
• update account

11
Structure Charts

• A Structure Chart is a graphical representation
  of a design, illustrating the partitioning of a
  system into its component functions.
• They show
• a hierarchy of program units built up from
  subunits
• the communication which takes place between
  modules
• Their advantages
• they picture the system, increasing clarity
• they are modular, making later stages easier
  (coding, testing, maintaining)
• they encourage reuse of their modules in other
  systems
• they clearly reveal prewritten components, reused
  from elsewhere

12
Structure Chart Components

• Rectangles representing functional components or
  modules
• Arrows linking rectangles, showing module
  hierarchy
• Short arrows representing communication between
  modules - input to or output from modules
• plain arrows represent data
• arrows with blobs at the end represent flags or
  control information
• diamond - white condition
• diamond - black selection
• curved arrows iteration
• pentagon connector
• rectangle with tramlines pre-written function
• black-hatted modules represent key operations
  WITHIN a module.

13
Structure Chart Example

• Draw a structure chart to represent the following
  passage of text
• You are having a night out on the town. At the
  start of the evening you go to the pub, and at
  closing time you go home.
• While youre at the pub you buy a number of
  drinks, and with each drink you buy a packet of
  crisps. The drinks you like are Guinness, Best
  Scotch and lager.

14
(No Transcript)
15
Structure Charts - points to note

• Labels
• The label in a box is very important, and states
  the function of the whole subsystem it controls
• Interconnection of modules
• Structure Charts are hierarchical and are read
  from top to bottom
• Submodules are not necessarily called in left to
  right order
• If 2 modules call a 3rd, the 3rd must only appear
  once on the structure chart, to reduce
  inconsistencies. This is possible because left to
  right order is not imposed
• Structure charts show how modules are related,
  but not the order in which they are called