Principles of Structured System Development (CSA2821 – Diploma Course)

1. Principles of Structured System Development(CSA2821 – Diploma Course) Dr. Ernest Cachia Department of Computer Science & A. I.

2. Who should you be? • People equipped with the following: • A basic interest in the field of software development as a whole • A basic awareness of traditional programming methods • Receptive to new ideas (even willing to try them out) • Able to impose discipline on your thoughts and actions, even on what might seem trivial © 2003 - Dr. Ernest Cachia

3. Structured Specification A possible generic definition: • “A pre-defined set of steps aimed at producing an efficient description of what is to be done.” A possible s/w-oriented definition: • “A set of clear and un-ambiguous guidelines, tools and methods to aid in the production of a valid and usable description of what a software system is to achieve.” © 2003 - Dr. Ernest Cachia

4. I/O requirements of specification • Input to specification: • A complete feasibility study • A confident understanding of user requirements (usually in abstract form) • Output from specification: • Graphic (and textual were necessary) descriptions of all system aspects • Feed-back of any system-forced constraints © 2003 - Dr. Ernest Cachia

5. Some specification properties • If carried out MUST precede design • Will aid the design process • Must be structured to correctly specify user needs • Should contain no embellishments • Should predominantly be graphic • Should be easily and clearly understood • Should make provisions for prototyping © 2003 - Dr. Ernest Cachia

6. How does specification help? • Forces one to better and more comprehensively analyse a situation • Forces the analyst (i.e. the person producing a description of the system) to interface more closely and seriously with the system user(s) (i.e. bridges the gap between the supplier’s and the customer’s fields of knowledge) • Offers the ideal starting point for sound system design © 2003 - Dr. Ernest Cachia

7. S/w specification until recently • User requirements took second-stage to actual system implementation • Specification was never taken seriously • “Seasoned” programmers felt degraded when asked to specify what they thought they already knew well • Quite often systems were specified after their implementation (often bug-driven) © 2003 - Dr. Ernest Cachia

8. Reasons for specification neglect • Previous personal nature of software • Previous software system size • Previous software system demands • Warped ideas about specification being a tool for people who can’t think well (give the poor guys something to help organise their thoughts with) • Basic laziness and “cross-your-fingers-and-hope” attitude © 2003 - Dr. Ernest Cachia

9. Structured specification Tools • Graphic: • Data Flow Diagrams (DFDs) • Finite State Machines (FSMs) • Data Structure Diagrams (DSDs) • Etc. • Textual: • Natural language (eg. English) • Structured Natural Language • Program syntax • Etc. © 2003 - Dr. Ernest Cachia

10. The “Analyst” • Someone with the ability to capture user and system needs at different levels • Someone who can envisage a system from different aspects (points of view) • Someone who can communicate ideas on a non-technical basis • Someone who can save (or cost) an organisation a lot of effort and money © 2003 - Dr. Ernest Cachia

11. The importance of specification (1/2) Requirements 56% Designing 27% “Other” 10% Coding 7% • Distribution of s/w errors © 2003 - Dr. Ernest Cachia

12. The importance of specification (2/2) Requirements 82% Designing 13% Coding 1% “Other” 4% • Error rectification costs © 2003 - Dr. Ernest Cachia

13. The Specification Process • Generally referred to as Systems Analysis • Systems Analysis: “A problem solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose” [J. L. Whitten] © 2003 - Dr. Ernest Cachia

14. Visual Flow of System Analysis Feasibility Study The issue Authorisation and Problem definition Scope, budget, schedule, resources, etc. Business Case Problem Analysis The development team Physical factors Finalised system objectives Refinements, priorities, etc Ideas, structure, reports, etc. Statement of Requirements Decision Analysis Requirements Analysis © 2003 - Dr. Ernest Cachia

15. © 2003 - Dr. Ernest Cachia

16. The Model-Driven Approach • Structured Analysis • Process-centred • Information Engineering • Data-centred • Object-Oriented Analysis • Both process and data-centred (i.e. object-centred) © 2003 - Dr. Ernest Cachia

17. The Accelerated Analysis Approach • Discovery Prototyping • Involves the use of cheap and fast partial implementation of certain system features • Prototypes allow system stakeholders to learn about the final system • Rapid Architecture • Based on reverse engineering principles • Don’t re-invent the wheel – understand its function and improve on it! © 2003 - Dr. Ernest Cachia

18. System Planning Moving on to System Planning © 2003 - Dr. Ernest Cachia

19. What is (and isn’t) System Planning • A formal definition: “An outline, sketch, or layout of the form or structure of a work.” - Random House College Dic. (1972) – modified by author • Software system planning: “transforming what is required to be done (i.e. the task) into a blueprint of how a solution is to be achieved” - Autor (1997) • System planning does not guarantee correctness or uniqueness of a particular solution © 2003 - Dr. Ernest Cachia

20. Goal of Software System Planning • To obtain the smoothest possible transition from “what is” to “how is” a solution obtained • Offer tools (graphic) and guidelines to facilitate problem comprehension and its transition to “how” to plan its construction • Offer some sort of criteria by which to gauge the quality of a specific solution © 2003 - Dr. Ernest Cachia

21. How Does System Planning Help? • Better s/w system understandability • Improved system reliability • Better s/w system flexibility • Longer system durability (effective use) • Smoother s/w development process • Better end-user efficiency © 2003 - Dr. Ernest Cachia

22. Effort Associated with System Planning • More thought (re. the s/w system) • More discipline (both thought & actions) • Training in the use of specific tools • Training in the use of specific techniques © 2003 - Dr. Ernest Cachia

23. The situation till very recently • Little or no requirements specification • Little or no system specification • Only cosmetic system architecture design • System planning was more a “forced” activity than recognised need • Difficult system component integration • Primitive (usually empirical) testing • Large maintenance costs (~75%) © 2003 - Dr. Ernest Cachia

24. How Did We Get Here? • Historical evolution (good programmers are not necessarily good designers) • The nature of software has radically and rapidly changed (and is constantly changing) to reflect changes in our society • Plain laziness and human (sometimes) rebellious nature © 2003 - Dr. Ernest Cachia

25. Know your enemy (meaning task) • Clear your mind of pre-conception as to which model your system is to follow • Never try to force a design on to a model • Leave “how” to as later on as possible • “What” should lead to “how” not vice-versa © 2003 - Dr. Ernest Cachia

26. Major thrusts of System Planning • System simplification • Natural Hierarchical system structure • Graphic tools (methods) • Design elaboration (overall & detailed) • Design solution evaluation © 2003 - Dr. Ernest Cachia

27. System Simplification • Divide & conquer (Julius Caesar) • Identify “isolatable” tasks within a larger one • Tackle smaller tasks at different levels of design • Design the right relationship between tasks • Design system structure using tasks as blocks • Black-Box concept (also Mr. J. Caesar) • Clearly defined I/O • Clearly defined function • Internals may be ignored (at that given point) © 2003 - Dr. Ernest Cachia

28. Hierarchical System Organisation • Very old concept (even older than J. C.) • Permeates our whole existence • Tantamount to nature itself e.g. • The Universe: Galaxies, star-clusters, solar systems, planets, land masses, continents,… sub-atomic particles, and who knows what else! • Company structures • Government establishments • Society, etc. © 2003 - Dr. Ernest Cachia

29. Graphic Tools • A picture is (can be) worth a thousand words - this is a physiological fact that has to do with brain evolution • Examples of graphic tools for design and specification include • Structure Charts (SCs) • Data Flow Diagrams (DFDs) • Structure Diagrams (SDs) • (Good old) Flow Charts (FCs) © 2003 - Dr. Ernest Cachia

30. Design Elaboration • Definitely requires a precise well-defined problem statement (i.e. a good specification) • Guidelines and general strategies by which to smoothly transit from specification representations to design ones • Will progress through different levels © 2003 - Dr. Ernest Cachia

31. Design Solution Evaluation • Software is by nature prone to intense subjectivity • Subjective entities are very difficult to quantify of qualify (criteria might vary) • Any design solution can only be evaluated with respect to the specification of the problem being solved • A good design has definite demonstrable properties © 2003 - Dr. Ernest Cachia

32. Summary • Structured design attempts to impose some form of discipline on activities that were traditionally ad hoc (i.e. haphazard) • The main aspects of structured design: • force the problem to guide the solution • improving system understandability • use of system modeling tools • use of strategies to move from “what” to “how” • provide criteria by which to evaluate system quality © 2003 - Dr. Ernest Cachia

33. The “Designer” Risks… • Never heard of him/her (no job title) • No specific job description • Can take on different meanings (depending on the background or interest of who tackles it) • Is generally considered to be either an analyst or a programmer © 2003 - Dr. Ernest Cachia

34. The way one treats design (1/2) • Should be associated with experienced programmers more than with analysts • Programmers deal in terms of code so they should be in a better position to apply design to specific parts of the software system • Analysts deal in terms of strategies and general software system layouts so their idea of design is usually very generic • Should be approached as objectively as possible © 2003 - Dr. Ernest Cachia

35. The way one treats design (2/2) • Should ALWAYS be taken very seriously • Should ALWAYS precede coding • Should NEVER be bound to a specific form of coding (eg. a particular programming language) • Should be used to help simplify matters rather than show how complicated a system is © 2003 - Dr. Ernest Cachia

36. Identifying “sick” software • It’s unreliable (numerous bugs or breaks down often) • It’s difficult to manage and maintain • It’s difficult to alter • It’s not that good an aid to your work efforts and/or productivity • It’s difficult to come to terms with © 2003 - Dr. Ernest Cachia

37. The main phases in the software development process 1. Specifying the requirements of the system 2. Specifying the system itself 3. Designing the system 4. Implementing the system 5. Testing the system 6. Maintaining the system © 2003 - Dr. Ernest Cachia

38. Implications from development • The more time you invest in thinking about and planning your software the less time you will spend testing and maintaining it • The amount of thought effort spent on coding should be very minimal • The earlier (in the development process) an error is detected the it costs to rectify © 2003 - Dr. Ernest Cachia

39. Some graphic examples of s/w development effort spread Specification 10% Designing 15% Requirements 10% Coding 20% Testing 45% © 2003 - Dr. Ernest Cachia

40. Some graphic examples of s/w development cost spread Testing 15% Coding 7% Designing 5% Specification 3% Requirements 3% Maintenance 67% © 2003 - Dr. Ernest Cachia

41. What is “un-maintainable” • An un-maintainable systems is one that is: • Difficult to comprehend • Difficult to assess its requirements impact • Difficult to test (“fully”) • Difficult to change any of its aspects • Difficult to establish which parts need to be changed • Has confusing (mis-matching) documentation © 2003 - Dr. Ernest Cachia

42. Basic design elements Consider such elements as... • The module • The data • The relationships Apply to them the basic principles of... • Abstraction • Formality • Divide and conquer • Hierarchical ordering © 2003 - Dr. Ernest Cachia

43. The module • Abstract entity (not necessarily a procedure) • Completely non-hardware dependent entity • Self-contained entity • Fully (fromally) defined entity (both functional and structural) • Entity to localise system functionality • Basic “non-decomposable” entity © 2003 - Dr. Ernest Cachia

44. Module attributes • Name or meaningfull identification • Input (required data) • Output (produced data) • Function (converting input to output) • Communication details (interfacing) • Mechanics (internal actions) • Internal data (data used solely by module) © 2003 - Dr. Ernest Cachia

45. Module example ……. Module interface Module implementation (aka Module body) The module © 2003 - Dr. Ernest Cachia

46. Various module implementations • In Pascal: Procedure, function, unit • In C: Function • In Modula-2: Module interface and its implementation • In English: Paragraph, section, chapter • In drawings: Quadrilateral, circle, specific symbols, etc. • In Assembly: Routines • In human thought: Module! © 2003 - Dr. Ernest Cachia

47. The data • Abstract entity • Internal or external (to module) entity • Share-able entity • Decompose-able entity • Completely non-hardware dependent entity • Communicate-able © 2003 - Dr. Ernest Cachia

48. Data attributes • Name or meaningfull identification • Type • Structure • Nature (control or information-driven) • Location(s) • Passage (source-destination) © 2003 - Dr. Ernest Cachia

49. Data examples Module A Module B destination co-ordinates (a) completion signal Module X count, index: integer; temp_xcoords: array[1..10] of integer; temp_ycoords: array[1..10] of integer; complete: boolean; (b) © 2003 - Dr. Ernest Cachia

50. Various data representations • In programming languages: Declarations, implicit use, explicit naming conventions, etc. • In natural languages: Facts, principles, subjects, quantities, values, measures, etc. • In drawings: Text, directed arcs, specific symbols, etc. • In human thought: Data! © 2003 - Dr. Ernest Cachia