1: Software Development and .NET An approach to building software
Overview � Programming in software development � Life-Cycles for software development � Object-orientation and modelling � Requirements analysis and specification � Algorithms � Task decomposition � The .NET framework
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.
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
Common Life Cycle Models 1 � Well established � The Waterfall Model � Predictable � Easy to cost But… � Inflexible � Software appears late
Common Life Cycle Models 2 � Based on Waterfall � Good for complex � Staged Delivery systems with many independent components Software � Quick to get working Concept � Initial design is simple Requirements Analysis But… Architectural � Can cause ‘feature Design 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
Common Life Cycle Models 3. � Based on a cycle of rapid design, build, � Evolutionary prototyping evaluate, modify design etc. � Good for systems Initial Design and Refine Complete and Concept implement prototype release where requirements are partial until prototype ambiguous (e.g. new type prototype acceptable of software) � Customer involved throughout But… � Difficult to predict � Duration � Cost
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)
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
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
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
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 ‘object- oriented’ � Individual phases will be affected, since the output of each phase is some form of software analysis/design/implementation product
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
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
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).
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
Use-Cases and Use-Case Diagrams Travel Agency System � Use-Case view Add Customer Deta ils � Depict a system from an end-user’s perspective Book Package Holiday � Creates a model of the ‘functions’ (use-cases) Retrieve a system will perform Booking Data � Provides a starting point from which to Travel Retrieve determine the objects Customer Data Agent that will make up a system Exchange Currency � Use-cases are ‘scenarios’ that require Generate detailed descriptions Exchange Invoice Clerk � A ‘Use-Case Diagram’ is a shorthand view of these
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
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
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
Recommend
More recommend
