CC2007N: Design

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

Where Do We Begin? modeling Prototype Spec Design

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

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

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

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

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

Sizing Modules: Two Views

Functional Independence

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.

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

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

Introduction – Method and Tools The Environmental Model The Internal Model

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.

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

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)

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!

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

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.

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

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

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,…

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!

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.

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.

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

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

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

Connecting DFD fragments CUSTOMERS Order ORDERS Order_No Place Cancel

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.

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!

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!

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!

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.

Think on The incremental model