Software Design

1. Software Design An Introduction to Object Oriented Analysis and Design Using the Unified Modelling Language Bill Keller Spring 2004

2. Lecture 1: Introduction • Introduction • What the course is about • What the course is not about • Aims and Outcomes • Teaching and Assessment • Design Case Study • Design Task • Recommended Reading Software Design

3. What the course is about • An introduction to object-oriented analysis and design: • The software development process • Object-orientation • Requirements analysis and modelling • Software quality • The Unified Modelling Language (UML): • Use case diagrams • Static structure and the class model • Object collaboration and interaction • Object state and behaviour • Team-working • Managing the process Software Design

4. What the course isn’t about • To keep the course manageable, we won’t cover: • Requirements capture • Interface design and HCI Issues • Deployment and maintenance • Some UML dealt with only briefly or not at all: • Packages and components • Deployment diagrams • Object constraint language Software Design

5. Course Aims • An introduction to fundamental concepts of object-oriented analysis and design of software • practical experience of software modelling and design techniques • experience of team-working • an introduction to the Unified Modelling Language This course aims to provide first year students with: Software Design

6. Learning Outcomes • On successful completion of the course students should be able to: • Appreciate the problems inherent in the design of high-quality software • Demonstrate the skills needed to model software components using basic elements of the UML • Work effectively as a part of a software design team • Document design decisions appropriately Software Design

7. Why UML? • UML is a visual modelling language which • supports analysis and modelling at all stages • is an emerging standard for software modelling • Is process neutral: i.e. is not tied to any one particular design process • We will cover core aspects of UML, including: • Use-case diagrams, • Class diagrams, • Interaction diagrams: collaboration/sequence • Statechart and activity diagrams Software Design

8. Teaching Sessions: Lectures • Generally there will be two lectures each week: • Monday: ?? in the Biology Lecture Theatre • Wednesday: ?? in the Biology Lecture Theatre Software Design

9. Lecture Topics Introduction Software Development Object Orientation Requirements and Use Cases An Overview of UML Class Models and Diagrams More About Class Diagrams Collaboration Collaborations and Interactions Object Behaviour Other UML Notations Design Quality Product Quality Software Patterns Software Design

10. Design Case Study:Automated Teller Machine (ATM) Statement of purpose: An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement Software Design

11. Teaching Sessions:Design Workshops • There will be a design workshop each week • work together in small teams • focus on a single design task • Based around structured design exercises • work through the development process • hands-on experience of design techniques • develop understanding of lecture material Software Design

12. Formal Assessment • Assessment for the course: • is based entirely on coursework • focuses on a single software design task • Assessed work will consist of • two submissions of design documentation • an oral presentation • Each submission for assessment will involve: • a team component • an individual component Software Design

13. Design Task:Online Bookshop Statement of Purpose The eVersity online bookshop allows students and staff to purchase course books quickly and easily. A user is able to browse the book catalogue or search for individual items by title or author. Required books may be added to a purchase order. Payment is by debit card although college staff can also pay by salary deduction. College tutors can order in textbooks for courses that they teach. Software Design

14. Why Teamwork? • Software design is usually a team effort: • Real-world software systems too large and complex to be tackled by a single individual • good design requires various sorts of expertise • Successful design projects need: • planning, • communication • management • Teamwork plays a central role in this course Software Design

15. Course Texts • Key text: • Pooley, R and Stevens P (1998) Using UML: Software Engineering with Objects and Components, Addison-Wesley • Recommended texts: • Lunn, K. (2003) Software Development with UML, Palgrave • Bennet, S, McRobb, S, and R Farmer (2002) Object-Oriented Systems Analysis and Design, McGraw-Hill • Bennet, S, Skelton, J and K Lunn (2001) UML, Schaum’s Outlines series, McGraw-Hill • Budgen, D (1994) Software Design, Addison-Wesley Software Design

16. Other Resources • The course web site: • Course outline information • Lecture notes • Seminar notes • Details of design task and exercises • Etc. etc. • Look under: Informatics: home > teaching > course directory or http://www.cogs.susx.ac.uk/users/billk/sd.html Software Design

17. Summary • The course covers key ideas in • object oriented analysis and design • UML • Teaching is provided by a combination of • lectures • hands-on design workshops • Assessment is entirely by coursework • Based on a single design task • Students work together in design teams Software Design

18. Lecture 2: Software Development • Software Development Terminology • Design Objectives and Design Problems • Why Do Things Go Wrong? • Project Life Cycles • The waterfall model • The spiral model • The Unified Process Software Design

19. Software Development:Terminology • Systems Analysis: • Process of seeking to understand organization of system • Investigation and modelling of system requirements • Software Design: • Process of producing solution to analysed requirements • Specifying detail of how system will meet requirements • Software Engineering: • Application of a systematic, disciplined approach • Adherence to high standards of professional ethics Software Design

20. What Do We Need? • We need software that is: • Useful and usable: ‘fit for purpose’ • Reliable: free of bugs • Flexible: can adapt to changing needs of users • Affordable: to buy and to maintain • Available: delivered, portable and maintainable • Objectives are: • Easy to state, but… • …may be hard to achieve in practice! Software Design

21. What Are the Problems? • Total failure of software: • The London Ambulance Service • TAURUS stock trading system • ARIANE 5 Launcher • August 14th 2003, east coast USA power blackout • Failure can be catastrophic and very costly • but, it’s the exception rather than the rule • Nature of problem depends on stakeholder you ask • The end users • The ‘clients’ • The software developers Software Design

22. The End-user’s Perspective The new system doesn’t: • do the right thing: • wrong tasks • incomplete • do things right: • dreadful to use • poor interface • doesn’t arrive: • ‘vapourware’! Software Design

23. The Client’s Perspective I would never have agreed if: • I’d known the cost • Development costs way over budget • I’d know how long it would take • It was needed months ago • The system is already obsolete • I’d had a choice • I didn’t want it in the first place! Software Design

24. The Developer’s Perspective Don’t blame me: • It’s what you said you wanted • I can’t help it if you’ve changed your minds • It’s the best I could do in the time available • I’ve never done Java/OOA/GUI design/etc. … before • I always said it was impossible anyway • I don’t know how it’s supposed to work • The system’s fine • it’s the users! Software Design

25. Why Do Things Go Wrong? • No one reason for failure • Complexity of software • Complexity of development process • Failures broadly due to: • Unacceptable quality • Poor productivity Software Design

26. Avoiding the Problems We need to: • Adopt a well-defined development process • Clear phases with deliverables • Built in verification and validation • Effective management • Be clear about project requirements • Make use of relevant knowledge • Make sensible use of tools Software Design

27. Project Life Cycles • The development process can be divided into various phases • A number of different models: • The traditional waterfall life cycle • The spiral model (Boehm 1988) • The unified process Software Design

28. The Waterfall Life Cycle Waterfall model: process moves from one stage to another, but never back! Analysis Design Construction Testing Deployment Maintenance Software Design

29. Pros and Cons of the Waterfall • Advantages: • Highly structured with clear phases and deliverables • Easy to evaluate project progress • Can be effective for risk management • Disadvantages: • Requires perfect decision-making • Projects rarely follow a simple sequence • Iterations and revisions are almost inevitable Software Design

30. Waterfall with Iteration Analysis Models ability to revise earlier stages in the process. Design Construction Testing Deployment Revision can be costly and difficult to manage Maintenance Software Design

31. The Spiral Model (Boehm 1988) Design, deploy, test Evaluate Analyse requirements for this iteration Analyse risks and plan Software Design

32. Advantages of the Spiral Model • Iteration • embraces iterative nature of process • Prototyping • each loop of the spiral leads a system prototype • Risk analysis • adds notion of risk management as a central concept Software Design

33. The Unified Process(Booch, Jacobson, Rumbaugh) • Four distinct phases: • Inception: determine scope and purpose of the project • Elaboration: requirements capture and system architecture • Construction: build software system • Transition: installation • Workflows within each phase: • Requirements, Analysis, Design, Deployment, Test Software Design

34. The Unified Process • Project passes through four stages in a sequential manner (phases) • Iterations occur within each phase (spiral model) • Each iteration involves a series of different activities (workflows) • Amount of work spent on each activity changes between phases/iterations Software Design

35. Other Process Models • Phased release model: • Waterfall extended to include incremental development • The evolutionary model • Emphasizes overlap in loops of spiral model • Makes explicit differing amounts of effort needed • Concurrent engineering model • Accounts for the divide and conquer principle • Extreme programming Software Design

36. Summary • Software development is a complex process • Many possible paths from start to end-product • Involves balancing needs of various stakeholders • Development has distinct stages (waterfall) • Software life cycle iterative (e.g. spiral) • Prototyping • Risk management • There is no one ‘best’ process model • Different methodologies suit different projects Software Design

37. Lecture 3: Object-Orientation • What is object-orientation? • Analysis, Design and Programming • Why object-orientation? • Objects concepts: • State, behaviour and identity • Abstraction and Encapsulation • Modularity • Classes and inheritance • Summary Software Design

38. What is Object Orientation? An approach to problem-solving which: • organizes process and data around discrete, coherent units known as objects • represents real-world entities in terms of objects and their composition • models system behaviour in terms of object interaction Software Design

39. OOA, OOD and OOP • OO Analysis: uses object concepts to analyse a particular problem domain or existing system • OO Design: uses objects to model static and dynamic aspects of a proposed application • OO Programming: uses objects and classes to organize code Software Design

40. Why object-orientation?In the beginning… • First computer languages mixed process and data: • machine code, assembler language • difficult to produce – limited in application • Second generation languages separated data from process: • Cobol, Fortran, Pascal, C programs = data structures + algorithms • Batch data-processing applications served well: • large-scale banking applications; scientific calculation Software Design

41. Why object-orientation?Batch and Interactive Systems • Batch systems process lots of similar data at once: • e.g. run all the payroll calculations overnight • fixed process with little variation from run to tun • Modern interactive systems do things differently: • small sets of relevant data processed almost instantly • event-driven user interfaces with much flexibility • This needs different organization of software: • group bits of processing and related data together • organize software around collaborating objects Software Design

42. Why object-orientation? • Object-oriented languages emerged in modern form around 1980: • Smalltalk and OO window system released by Xerox • Subsequently C++, Java etc. • Objects provide a natural and productive way of developing interactive systems: • Natural to think of GUIs in terms of different objects • Objects can be linked to provide complex behaviours • Objects support code re-use Software Design

43. What is an object? • Objects are the building blocks of OO systems: • An object: • has attributes that define its state • has operations that define its behaviour • has an identity distinct from other objects • A well-designed object: • Provides a coherent view of something (abstraction) • Limits access to just what is needed (encapsulation) Software Design

44. State, Behaviour and Identity • State: all the data that an object encapsulates (values of attributes) • what do I know? • Behaviour: the way in which an object reacts to messages that it understands – • what can I do? • Identity: objects persist; you can refer to object by name; identity versus equality – • who am I? Software Design

45. Abstraction • Object typically represent real-world entities: • Physical things (buildings, people, peripherals…) • Conceptual entities (dates, plans…) • Objects abstract away from inessential details: • Procedural abstraction: • don’t need to know how a procedure is implemented, just how to communicate with it • Data abstraction: • collect together relevant data Software Design

46. sam:Employee dob: 17.02.80 address: 20, Foobar Road salary: 25000 position: programmer Example: Objects and Abstraction sam:Employee dob: 17.02.80 address: 20, Foobar Road height: 5 feet 8 inches weight: 112lb eye_colour: blue hair_colour: brown shoe_size: 8 ….. Software Design

47. Encapsulation • Details of object’s implementation hidden • Only way that an object can be manipulated is through its operations • Consequently, users don’t need to know: • State: how data is represented or structured • Behaviour: how operations are implemented • Object has a well-defined interface: • public: provide access to essential data and methods • private: for internal use only Software Design

48. sam:Employee -dob: 17.02.58 -address: 20, Foobar Road -salary: 25000 -position: programmer +get_dob() +getAddress() +setAddress() Example: Object and Interface An object has a public and a private interface Attributes hidden from view All interaction with the object must go through the operations Software Design

49. Modularity • Modular systems have discrete units with • high cohesion – package together relevant/coherent information (abstraction) • low coupling – provide clean and limited interface (encapsulation) • Modular systems are easier to: • understand (high cohesion is intuitive) • modify (low coupling/dependency between modules) • extend Software Design

50. Class, Instance and Object • Objects may have much in common: • e.g. employees of a company share certain properties and behave in similar ways • In class-based OO languages: • Classes describe commonality • Objects belong to classes (are instances of classes) • Ensure consistency of behaviour • Provide for type-checking Software Design