4 Fundamental Concepts Abstraction - data, procedure, control Refinement - elaboration of detail for all abstractionsModularity - compartmentalization of data and functionArchitecture - overall structure of the softwareStructural propertiesExtra-structural propertiesStyles and patternsProcedure - the algorithms that achieve functionHiding - controlled interfaces
5 Data Abstraction door manufacturer model number type swing direction insertslightstypenumberweightopening mechanismimplemented as a data structure
6 Procedural Abstraction opendetails of enteralgorithmimplemented with a "knowledge" of theobject that is associated with enter
7 Stepwise Refinement open walk to door; reach for knob; repeat until door opensopen door;turn knob clockwise;walk through;if knob doesn't turn, thenclose door.take key out;find correct key;insert in lock;endifpull/push doormove out of way;end repeat
8 Modularity: Trade-offs What is the "right" number of modulesfor a specific software design?optimal numberof modulescost ofsoftwarenumber of modulesmoduleintegrationcostmodule development cost
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 policyclients"secret"a specific design decision
13 Why Information Hiding? reduces the likelihood of “side effects”limits the global impact of local design decisionsemphasizes communication through controlled interfacesdiscourages the use of global dataleads to encapsulation—an attribute of high quality designresults in higher quality software
14 Introduction – Method and Tools The Environmental ModelThe Internal Model
15 IntroductionThe 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 environmentInternal 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 difficultFor 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 thedetails of customer orders for books, as well as shipping, invoicing, and back-billingof customers with overdue invoices.Information about book orders should beavailable for other systems, such as marketing, sales and accounting.Context Diagram (DFD).Orders,Cancelled ordersReprint ordersInvoice,Books arriving atwarehouseShipping listWeeklysales reportCredit statusInvoiceAjaxBook OrderSystemCUSTOMERSMANAGEMETPRINTERSACCOUNTINGThe Event List(incomplete!):1.Customer places order (flow-oriented event)2.Customer cancels order (flow3.Management requires weekly sales report (temporal event)4.Book reprint order is to be created (control event)…………NB. Alternative names for these events couldbe more ‘function oriented’ e.g.Accept customer order, Cancel order, Produce weekly sales report, Create bookreprint order,…
24 The Internal Model The model is described using: DFDs, Pspecs, Data Dictionary (with data flow, data store and entity definitions)E-R DiagramState 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) CUSTOMERSOrderOrder_NoOrder_DetailsORDERSPlace Order
28 DFD Fragment for “ Customer Cancels Order” Event (Event 2) Order_NoORDERSCancelorder
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).
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 DictionaryEach 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 PspecsPspecs against Data DictionaryERD against DFD and Pspecs and Data DictionaryEtc.