1: Software Development and.net. An approach to building software

Transcription

1 1: Software Development and.net An approach to building software

2 Overview Programming in software development Life-Cycles for software development Object-orientation and modelling Requirements analysis and specification Algorithms Task decomposition The.NET framework

3 Programming Programming is only one activity in the process of developing software Analogous to the Construction phase in building (i.e. missing out architecture, surveying, logistics etc.) Before programming can commence, we need to determine what to do (requirements analysis) and how we will do it (design) To build good software, it is necessary to perform a lot of organizational tasks breaking up the overall job, deciding on what will be implemented, combining components into a system, testing what we have built etc.

4 Software Life-Cycle Most software developers accept that software is created over a sequence of tasks that are often called the life-cycle Depending on the required system, the tools used, the developers doing it and other environmental factors, any one of many different styles of life-cycle can be used

5 Common Life Cycle Models 1 The Waterfall Model Well established Predictable Easy to cost But Inflexible Software appears late

6 Common Life Cycle Models 2 Based on Waterfall Staged Delivery Software Concept Requirements Analysis Architectural Design Good for complex systems with many independent components Quick to get working Initial design is simple But Can cause feature creep Stage 1: Detailed design, code, debug, test and delivery Stage 2: Detailed design, code, debug, test and delivery Stage n: Detailed design, code, debug, test and delivery

7 Common Life Cycle Models 3. Evolutionary prototyping Based on a cycle of rapid design, build, evaluate, modify design etc. Initial Concept Design and implement partial prototype Refine prototype until acceptable Complete and release prototype Good for systems where requirements are ambiguous (e.g. new type of software) Customer involved throughout But Difficult to predict Duration Cost

8 Common Life Cycle Models 4 Extreme Programming (XP) A radical and very recent development model Eschews traditional phase-oriented approach, reasoning that requirements are impossible to freeze early in a project s life Promotes a set of practices based on programmer s experience: Small teams Form of Staged/Evolutionary Delivery, but many more stages (mini-milestones) Team MUST include a client representative developers require constant access to clarify requirements and demonstrate stages of delivery Team agrees of code standards, which are held rigidly Development progresses as: Define a requirement (a story) Devise a test of the requirement Write software to pass the test (simple as possible)

9 Life Cycles in Practice There are in fact many more forms of life-cycle than the 4 described here See Rapid Development, by Steve McConnell for an overview of the main ones Most SD companies have their own variation on a common life cycle Corporate culture is a major influence on how a life-cycle model is applied to a real project It is common to mix-and-match aspects of the standard life-cycles described in text and research papers e.g. Staged Delivery with an Evolutionary approach in problem stages There is no one-size-fits-all approach to building software

10 Life-cycle Influencing factors Size of project the number of people involved in the project the size of the company employing the developers the level of formality adopted by the company the type of software being developed the expertise and experience of the developers, the knowledge that the customer or end-user has about software and software development The customers and developers understanding of the nature of the proposed software

11 Life-Cycle for building OO programs in Visual Basic requirements: support for an object-oriented development model support for the Visual development model espoused by Visual Basic (and several other development systems) scalability that is, a facility to enable the use of the life cycle model for projects in a range of sizes ease of use we have no wish to wrap up an already complex task in layers of bureaucracy best use of the high adaptability and rapid-development features inherent in object-oriented programming and visual development

12 Object Orientation A Life-Cycle is a process model that does not take the detailed nature of the project into account A life-cycle model is not specifically objectoriented Individual phases will be affected, since the output of each phase is some form of software analysis/design/implementation product

13 Modelling and Designing Software Many established software design methods Typically, a set of standards for diagrams, charts, tables etc. that can be used to describe software UML is the current industry standard Well established Flexible Provides sufficient detail for many types of software project

14 UML Unified Modelling Language the integration of several design techniques useful in software development Diagram based, since engineering communications work better using visual models Software tools (e.g. Visio, Rational Rose) can be used to create the framework of a program from a UML model CASE (Computer-Based Software Engineering) Faster development Fewer human errors Reduction of drudgery in programming

15 UML and Software Products A series of Diagram standards for describing various stages in the development of software UML s 4+1 View model Use-case view for defining requirements Design view for defining the logical structure of software Implementation view describes physical components of system Process view depicts the ways different elements interact Deployment view describes how the various physical components are organised (e.g. how parts are allocated across a network).

16 Requirements Analysis & Specification Need to find out what a computer system will be required to do Information comes from: Initial proposal statement Interviews with customers/end users Developers knowledge and experience Analysis and observation of manual system (e.g. for office software) Determining inputs and desired outputs Result of all this analysis is a specification document, containing statements that say what the system is expected to do in general terms Typically a Use-Case diagram

17 Use-Cases and Use-Case Diagrams Travel Agency System Use-Case view Depict a system from an end-user s perspective Creates a model of the functions (use-cases) a system will perform Provides a starting point from which to determine the objects that will make up a system Use-cases are scenarios that require detailed descriptions A Use-Case Diagram is a shorthand view of these Travel Agent Add Customer Details Book Package Holiday Retrieve Booking Data Retrieve Customer Data Exchange Currency Generate Invoice Exchange Clerk

18 Objects and Requirements From a full description of system requirements, we need to determine the components a system will be made up of These are Objects in OOP terminology The manufactured world is full of objects, many of which are components of bigger objects We need to know what they are, what they must be capable of, and how they will need to interact E.g. a pen has a body, an ink reservoir, a nib and ink, each with properties (ink is blue) and operations (ink runs out, nib transfers ink to paper) Software objects are made up of data (properties) and operations (methods). Operations execute in response to external stimuli (messages) Several objects may collaborate to meet any given system requirement

19 Objects and Classes A Class is a design (or template) for a type of object Efficient design once, deploy many times An object is an Instance of a class Classes are designed to: Represent parts of a system, e.g. A Printing sub-system An Invoice A Customer Record Define objects that can interact in functional ways A Customer may be associated with a number of invoice The Printing sub-system can print an Invoice (Much) more on this later

20 Algorithms All software is built on the basis of a computer following simple instructions Could be to extract data from a disk file, perform some arithmetic, display a result Objects are convenient ways of organising sets of instructions Easier to conceptualise e.g. a Customer can print an Invoice (using the Printer sub-system) The actual instructions are defined as Algorithms An algorithm is a set of instructions for solving a problem or task. When the instructions are followed, it must eventually stop with an answer

21 Algorithms and Tasks Many algorithms are described in texts and research papers, and many have been handed down for hundreds of years (e.g. Euclid s algorithm for finding the GCD of two numbers) Typically these are descriptions of mathematical calculations or logical manipulations In a lot of cases, a computer algorithm is simply a translation of the manual way of doing a job e.g. filling in a tax form (which is even depicted like an algorithm in the tax form itself) e.g. following a recipe The main principle is that an algorithm is simple to follow The clever bit can be in devising it

22 Task Decomposition One approach to describing a task as an algorithm is to perform Task Decomposition (a.k.a. Stepwise Refinement) Break a complex task into a number of smaller subtasks If the sub-tasks are still complex, consider each to be a separate task and go back to previous step This simple approach (also an algorithm) is the basis used for solving most computer programming problems

23 VB.NET for creating software Visual Basic.NET is a programming language that is used to build Software Solutions A Solution is an applications program, that can be composed of one or many Assemblies An Assembly is either a program or a program component that can be used by other programs. As the name suggests, an Assembly is typically composed of a number of separate items, each of which occupies a Visual Basic Code file. A Project is a combination of code files, that is used to create an Assembly Visual Studio allows you to work on single Projects and complete, multi-project Solutions. A Project can be a stand-alone program, or a component that can be used with several programs. Each project in a solution defines a separate Assembly

24 Components of a Solution Code File Assembly Code File Visual Basic Compiler Assembly Code File VB Project Visual Studio Assembly VS Solution

25 Summary There is more to software development than programming Life-Cycles Modelling and Design UML Requirements analysis and Use-Case diagrams Classes and Objects Algorithms Task Decomposotion.NET Projects and Solutions