Logical And Physical Design

1. Logical And Physical Design • Logical Design :- • Describes inputs, outputs, data bases ( stores), procedures – as per user requirements. • The design covers the following:- • Reviews the current physical system. • Prepares Input and Output Specifications. • Prepares edit, security, control specifications. • Specifies implementation plan. • prepares a walkthrough. • review benefits, costs, target dates, system constraints

2. Physical Design:- • Design the physical system • I/O media • database & backup procedures • Physical info flow & design walkthrough. • Plan system implementation • Conversion Schedule & Target date • training procedures, courses • New h/w & s/w tests and implementation plan • Update benefits, costs……etc ( physical system)

3. Structured Design S.Eng, D.Tree, D.table Sys Sp. DFD Data Dic Process Info

4. Data-flow based methodology • Identifies I/Ps and O/Ps and Functions • system specifications used for DFDs ( data flows/processes) • DFDs --- data dictionary & structured tools ( def. of modules and their relationships) • Partitions a program into small, independent modules • Arranged in hierarchy • Top-down or Bottom-up approach • Minimize complexity by subdividing • Modularization or decomposition • Top-Down --- each module having single entry/exit

5. Advantages of this design:- • Critical interfaces are tested first • early versions of design ( incomplete) are useful to resemble the real system • Structuring provides--- control and improves morale • Procedural Characteristics define order that determines processing. • Functional Decomposition • It is a graphic tool for representing hierarchy and it has three elements:- • Module • Set of statements A

6. 2. Connection Linking two modules A calls B A calls C 3. Couple Data items moved from one module to another. A B C A K L M B C

7. Functional decomposition approach – S/w partitioned into independent small manageable modules. Module connections to other modules:- Module coupling – number of connections between calling and called module. Module cohesion – relationship among the elements within a module. More cohesive – only one task poorly cohesive – multiple tasks

8. Object-Oriented Design • Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design • An object contains encapsulated data and procedures grouped together to represent an entity. • The 'object interface', how the object can be interacted with, is also defined. • Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented analysis.

9. from Business perspective, Object Oriented Design refers to the objects that make up that business. For example, in a certain company, a business object can consist of people, data files and database tables, artifacts, equipment, vehicles, etc. • Object-oriented concepts • The five basic concepts of object-oriented design are:- • Object/Class: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do.

10. An object can be part of a class, which is a set of objects that are similar. Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is the superclass and then it has its own set of functions and data. Interface: The ability to define the functions or methods signatures without implementing them. Polymorphism: The ability to behave differently in different environments.

11. Form-Driven Methodology IPO (Input-Process-Output) chart — A chart that describes or documents the inputs to, the outputs from, and the functions (or processes) performed by a program module. • HIPO (Hierarchy plus Input-Process-Output) — • A tool for planning or documenting a computer program that utilizes a hierarchy chart to graphically represent the program’s control structure and a set of IPO (Input-Process-Output) charts to describe the inputs to, the outputs from, and the functions performed by each module on the hierarchy chart.

12. Objectives:- • Provide a structure of the whole system. • State the functions rather than program statements. • Provide a visual description of inputs and outputs. • Procedure for generating HIPO diagrams:- • Highest level of abstraction– define inputs & outputs • Identify processing steps • Document each element • Identify subprocesses – define inputs & outputs

13. HIPO Package :- Visual table of contents – structure of diagram, relationships of functions, how symbols are used. Overview diagrams – major functions, detail diagrams I/O section Process section Extended description, non-HIPO documentation 3. Detail diagram -- extd. description – each process

14. Major Developmental Activities 1. Data base design:- design of physical database, Access paths ……by pointers, chains….etc. 2. Program Design :- programming lang. to use (OS), flowcharting, coding, debugging procedures. plans + test cases (testing), training of user staff. Minimize user resistance. 3. System test preparation :- system testing – after all programming & testing completed. Actual operations, user interface…etc are tested. 4. Program test preparation :- System + program test – part of design specification.

15. Acceptance testing -- To convince the user that the candidate system will meet the stated requirements. Conducted in the presence of user, audit representatives or entire staff. 5. System interface specification:- how the user should enter and leave the system, Formats for machine- machine or human-machine defined before implementation. user manual prepared – how to install, input, output, operate the system. 6. User documentation:- manual => install, operate, provide I/P and O/P, access, update, retrieve info, display, what format……

16. Personnel Allocation • past --- More emphasis on number of persons for speeding up implementation rather than talent. • Structured approach – useful in planning. More emphasis on allocating right programmers. • structure chart gives a realistic outline of work to b done • A team of programmers --- subsystem i.e strongly cohesive and loosely coupled to other subsystems. Roles are allocated within each team. • Modules at the bottom are utility n database access modules.

17. Features of a good system design Practical Economical Efficient Flexible Reliable Secure Political and operational constraints

18. Audit Considerations Processing controls and Data Validations :- Several methods to control processing activities. Batches of work are checked for errors. Other checks can be:- Completeness check :- ensures all the data is present in the record(s). Consistency check :- relevance of one type of data to another. Reasonableness check :- evaluates a transaction against a standard to determine whether it meets the test.

19. 4. Sequence check :- data records are in sequence before processing. Also checks for duplicates. • Audit Trail and Documentation Control :- • A routine designed to allow the analyst, user, or auditor to verify a process or an area in the new system. • Manual systems – journals, ledgers, and other documents auditor can use.

20. Computerized systems -- record content and format makes it difficult. bcoz:- • 1. records stored(magnetic medium) can be read only • by computer/program. • 2. data processing act – diff to observe • 3. record sequence diff to check without comp. system • 4. direct data entry eliminates physical documentation for audit program.