1. CC2007N: Design

2. Analysis to Design d u THE ANALYSIS MODEL THE DESIGN MODEL E n t i y -R e l a o s h p D g r m F w S T c P f ( C ) O b j
THE ANALYSIS MODEL d u
THE DESIGN MODEL

3. Where Do We Begin?
modeling
Prototype
Spec
Design

4. Fundamental Concepts Abstraction - data, procedure, control
Refinement - elaboration of detail for all abstractions
Modularity - compartmentalization of data and function
Architecture - overall structure of the software
Structural properties
Extra-structural properties
Styles and patterns
Procedure - the algorithms that achieve function
Hiding - controlled interfaces

5. Data Abstraction door manufacturer model number type swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure

6. Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter

7. Stepwise Refinement open walk to door; reach for knob;
repeat until door opens
open door;
turn knob clockwise;
walk through;
if knob doesn't turn, then
close door.
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

8. Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
optimal number
of modules
cost of
software
number of modules
module
integration
cost
module development cost

9. Sizing Modules: Two Views

10. Functional Independence

11. Architecture
“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]
Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods .
Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.

12. Information Hiding module clients • algorithm controlled
interface
• data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision

13. Why Information Hiding?
reduces the likelihood of “side effects”
limits the global impact of local design decisions
emphasizes communication through controlled interfaces
discourages the use of global data
leads to encapsulation—an attribute of high quality design
results in higher quality software

14. Introduction – Method and Tools
The Environmental Model
The Internal Model

15. Introduction
The Essential (Logical) Model - specifies user’s requirement in ‘logical terms’ i.e. with as little as possible said about HOW the system will be implemented. The emphasis is on WHAT the system is supposed to do.
Various ‘physical’ issues (e.g. physical organisation of data) are not analysed at this stage.

16. Introduction (Cont.) The essential model ‘consists of’ :
Environmental model - defines the boundary of the system and interactions between the system and its environment
Internal model - describes the required behaviour and structure of the insides of the system necessary to interact successfully with its environment

17. The Environmental Model
The Statement of Purpose ( a brief textual statement of the purpose of the system)
The Context Diagram (terminators, input and output data flows, the boundary, shared data stores (rare!))
The Event List (list of stimuli’ that occur in the environment to which the system must respond)

18. The Event List Flow-oriented events (associated with data flows)
Temporal events ( triggered by the ‘arrival’ of a point in time)
Control events (external stimuli that occur at some unpredictable points in time). Rare in business application. Important in real time control applications.
Please note that Yourdon’s events are similar to SSADM’s events. Basically events activate processes/functions! So there is 1-1 correspondence between events and functions!

19. Building the Environmental Model
For small systems – not very difficult
For large systems/project – a great deal of work can be involved because of many external terminators, many (perhaps hundreds) incoming and outgoing data flows, and the event list can be pretty long!!

20. Constructing the Event List
Events for business information systems correspond to ‘chunks’ of functionality which will be used by users.
In most cases the easiest way to identify the relevant events for a system is to visualize the system in action; we examine each terminator and ask what effect the terminator’s actions can have on the system.

21. Which Comes First, Context Diagram or Event List?
You can begin with either. It really doesn’t matter, as long as you eventually produce both and CHECK their CONSISTENCY!
Consistency checks should confirm:
Each input flow should be needed by the system to recognize that an event has occurred, or it should be needed by the system to produce a response to an event, or both.
Each output flow should be a response to an event

22. Which Comes First (cont.)
More consistency checks:
Each non-temporal event should have input from which the system can detect that the event has occurred.
Each event should either produce an immediate output as its response, or it should store data (in a data store) to be output later (as a response or part of response to some other event), or it should cause the system to change its state (mainly for real-time control systems).

23. An Example The statement of purpose.
The purpose of the Ajax Book Processing/Ordering System is to handle all of the
details of customer orders for books, as well as shipping, invoicing, and back -
billing
of customers with overdue invoices.
Information about book orders should be
available for other systems, such as marketing, sales and accounting.
Context Diagram (DFD).
Orders,
Cancelled orders
Reprint orders
Invo
ice,
Books arriving at
warehouse
Shipping list
Weekly s
ales report
Credit status
Invoice
Ajax
Book Order
System
CUSTOMER S
MANAGEMET
PRINTERS
ACCOUNTIN G
The Event List
(incomplete!) : 1.
Customer places order (flow -
oriented event) 2.
Customer cancels order (flow 3.
Management requires weekly sales report (temporal event) 4.
Book reprint order is to be created (control event)
…………
NB. Alternative names for these events could
be more ‘function oriented’ e.g.
Accept customer order, Cancel order, Produce weekly sales report, Create book
reprint order,…

24. The Internal Model The model is described using:
DFDs, Pspecs, Data Dictionary (with data flow, data store and entity definitions)
E-R Diagram
State Transition Diagrams (primarily for real-time systems)
NB. All three aspects of the system: processing/functionality, data, dynamics are addressed!

25. Developing a Set of Levelled DFDs
The Yourdon’s approach is different from the ‘classical’ top-down approach used e.g. in SSADM and other methods!
His approach can be called MIDDLE-OUT and it starts with the development of DFD fragments for each event. These DFD fragments constitute the ‘middle level’.
Next, UPWARD and DOWNWARD levelling is done to produce (if necessary) upper and lower levels.

26. Developing DFD fragments (at the ‘middle level’)
A single process is drawn for each event from the event list.
The process is named (the name ‘reflects’ the nature of the event).
Appropriate input and output flows are drawn (some of them are already included in the context DFD). Appropriate data stores are drawn.
The resulting DFD fragments are checked against the context diagram and the event list for completeness and consistency.

27. DFD Fragment for “Customer Places Order” Event (Event 1)
CUSTOMERS
Order
Order_No
Order_Details
ORDERS
Place Order

28. DFD Fragment for “ Customer Cancels Order” Event (Event 2)
Order_No
ORDERS
Cancel
order

29. Connecting DFD Fragments
So far processes in DFD fragments are not connected to each other i.e processes do not communicate with each other!
These ‘middle level’ processes should be connected via common data stores!
Processes can not communicate directly (via data flows) since they represent responses to ASYNCHRONOUS events (or in other words they ‘process’ asynchronous events).

30. Connecting DFD fragments
CUSTOMERS
Order
ORDERS
Order_No
Place
Cancel

31. Levelling the Preliminary ‘Middle-Level’ DFD
So far the DFD consists of a single level (‘middle’).
If there are too many ‘middle level’ processes some of them (related) should be grouped into meaningful clusters, each of which will represent a process in a higher level diagram. This is ‘upward’ levelling.
More complex ‘middle level’ processes may require downward partitioning into lower level DFDs using classical top-down approach to decomposition.

32. Developing the Data Dictionary and Process Specifications (Pspecs)
Data flow and data store definitions should be placed in the Data Dictionary
Each bottom layer (i.e. elementary/atomic) process should be specified (Pspec).
Some elementary processes belong to the ‘middle level’ (if they deal with ‘simple’ events) , some belong to the lower level(s) if the ‘middle level’ process has been decomposed!

33. Developing the Data Model (E-R Diagram and Entity Definitions)
E-R diagram should be developed and entities should be specified. Please note that entities ‘reside’ in data stores (i.e. data stores store instances/occurrences of entities).
When developing DFDs we must ‘remember’ about entities!

34. Developing the State-Transition Diagram(s)
Yourdon suggests that STDs should be developed for real time systems only.
However STD can also be developed for some (more ’complex’ ) entities to specify their ‘life’. In SSADM for example we produce ELHs which ‘roughly’ serve the same purpose!

35. Balancing (cross-checking) Various Models
Inter-model errors, that is inconsistencies between one model and another should be removed. Sometimes this process of cross-checking is called balancing the models.
We should check:
DFD against Data Dictionary and Pspecs
Pspecs against Data Dictionary
ERD against DFD and Pspecs and Data Dictionary
Etc.

36. Think on
The incremental model