KF5008 Program Design & Development. Introduction to the Module

Transcription

1 KF5008 Program Design & Development Introduction to the Module

2 Why Program Design? Up to now the programs you have written have been quite small even if you don t think so! How big do you think real programs are? <= 1000 lines of code? <= lines of code? Bigger? In this module we look at the techniques we need to use in writing bigger programs.

3 Handling Complexity Engineers have been building complex things for many centuries particularly civil engineers. Engineers make models of the things they are going to build. The models are abstractions: Concentrate on essentials, filter out nonessentials.

4 Software Modelling There is a big difference between software engineering and other types of engineering. What is it? Civil engineers can build scale models of the things they are working on. Can apply to other engineers too. You can t build a scale model of software! What to do? Over a long period, a number of diagrammatic notations have been developed you ve already met some of these (use case diagrams?) A visual model.

5 Needed for Visual Modelling Tool Notation Process Notation UML Process Agile but rigorous? Tool StarUML

6 Agile focus Focus is end software Use visual modelling but do it because it adds value Model the aspects of the system which require modelling And module is also about programming

7 Agile Methods Agile methods are adaptive rather than predictive Unlike other engineering methods, agile methods welcome change. Agile methods are people oriented rather than process oriented. They assert that no processes will ever make up the skill of the development team, so the role of the process is to support the development team in their work. All agile methods centre around small iterations

8 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

9 Why UML? Some sort of diagramming / modelling is probably helpful Best practice model Consolidation of other languages That doesn t mean it s flawless! Internationally accepted ISO standard - ISO/IEC Managed by the Object Management Group (OMG)

10 Why UML? UK government mandate e-government Interoperability Framework (e-gif) Intuitive Tool support Widely used Same types of diagrams can be used in Business Analysis, Analysis, Design and Implementation Focus upon slightly different levels of abstraction Use same tool to explore different aspects

11 Types of Requirements Functional Requirements What the system does or is expected to do Non-functional Requirements How well the system provides functional requirements Constraints Usability Requirements Match between functional requirements and the tasks the users of the system are going to undertake Definitions derived from Bennett Chapter 6

12 4 + 1 View of Architecture How are functional requirements dealt with? Software Module organisation Logical View Development View Process View Scenario View Physical View Where will the software run? Key processes in the system and how they communicate What is it going to do? Any constraints?

13 Scenario View What the system is going to do Clients requirements in terms of stories Scenarios describing what is required Functional Stories Non-functional Stories Usability Stories

14 Logical View Primarily supports functional requirements Decompose system into key abstractions (objects or classes or both) Identify common mechanism across the system Represent in the form of class and object diagrams Consider defining internal behaviour with state diagrams Sometimes E-R diagrams are used instead

15 Process View Behavioural aspects Communication Sequence diagrams Examine behavioural aspects by behavioural modelling Includes non-functional attributes such as performance, availability Tasks A thread of control that can be uniquely executed Processes Groups of tasks which form an executable unit Addresses concurrency and distribution

16 Development View Software module organisation Layers required Package diagrams Component diagrams

17 Physical View Where does software run? Takes into account non-functional requirements such as availability, reliability, performance, scalability Nodes represent physical hardware Mapping of tasks / processes to nodes Deployment diagrams

18 What does the use case model provide? Functional Requirements Who / What interacts with the system Actors Sets of high level user goals Use Cases Details of how these are achieved Use Case Descriptions Set of user stories which describe what we want the system to do

19 What does the Use Case Model not provide? Usability High level interactions No details Structured but still need to be read Maybe difficult to visualise what the system looks like No guide for how interfaces should be designed Non functional requirements Limited support Focuses on what it does not how well it does it Need some stories to capture these

20 Non-functional requirements / Quality attributes We need a set of stories which describe our functional requirements Which is better and why? The system will perform efficiently A lecturer requesting student enrolment module information will receive a report within 5 seconds at peak hours The second is Testable Needs to be defined with clients Establish testable scenarios for quality attributes

21 How can we specify non-functional requirements? Consider the following: 1. The system will be reliable 2. The system will be available 95% of the time 7 days a week between 8:00 am and 8:00pm 3. The system will be available 95% of the time 7 days a week between 8:00 am and 8:00pm allowing access to 100 users simultaneously on average. In groups of 3-4 consider which of these is best, why and what else should be included? ( Hint: think Black box testing?)

22 How can we specify non-functional requirements? 3rd is best Why? More testable! Average usage (averages can be misleading) In black box testing we re also concerned with boundaries What is peak usage? When is peak usage? Better as: The system will be available 95% of the time 7 days a week between 8:00 am and 8:00pm allowing access to 100 users simultaneously on average Peak usage is between 12:00 and 2pm when a maximum of 500 users are expected

23 Non-functional requirements Need specs for: Performance Availability Scalability Security Maintainability Technical constraints Accessibility Legal requirements Ethical requirements

24 Tools StarUML CASE tool Computer-Aided Software Engineering BlueJ The command line Eclipse Java IDE, widely used in industry Open source, cross platform

25 Java Revision You used Java in first year modules using BlueJ BlueJ is just one IDE. There are several others: NetBeans Eclipse IntelliJ You don t have to use an IDE at all. You can just use a text editor and compile via the command line. This may be best for a 'small' job.