1. Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

2. Subjects

3. ADMS-BIS Software Engineering

4. ADMS-BIS What is software engineering? SE is an engineering discipline which is concerned with all aspects of software production – implied a systematic and organised approach to the development operation, and maintenance of software

5. ADMS-BIS Software Engineering – Why ? Software problems –Bugs: low quality –High cost: budget overrun –Late delivery: schedule overrun

6. ADMS-BIS Software Engineering – Goal Make quality software, on time, within budget –Large and complex systems –Exist in may versions and variants –Last for many years in a changing environment –Undergo frequent changes –Built by project teams

7. ADMS-BIS Software Engineering vs. System Engineering System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering Software engineering is part of this process

8. ADMS-BIS What is software Computer programs and associated documentation

9. ADMS-BIS Nature of software Intangible Easy to modify Trivial replication Labor-intensive

10. ADMS-BIS Types of software Software products may be developed for a particular customer or may be developed for a general market –Custom –Generic –Embedded

11. ADMS-BIS Another categorization of software Real time software –It has to react immediately to stimuli from the environment Data processing software –Is used to run business

12. ADMS-BIS Stakeholders in software engineering Users Customers (clients) Software developers Development managers

13. ADMS-BIS Quality Software Customer: solves problems at an acceptable cost in terms of money paid and resources used User: easy to learn; efficient to use; and helps get work done Developer: easy to design; easy to maintain; and easy to reuse parts Development manager: sells more and pleases customers while costing less to develop and maintain

14. ADMS-BIS Software Quality Usability Efficiency Reliability Maintainability Reusability

15. ADMS-BIS Software process A structured set of activities required to develop a software system Generic activities in all software processes are –Specification –Design –Validation –Evolution

16. ADMS-BIS Compare SE with building a house Search for a location What type of house Make a design (architect) Design  drawings Realise house Completion of the house Use of the house

17. ADMS-BIS Software Requirements Introduction

18. ADMS-BIS Requirements engineering Get a complete description of the problem –feasibility study Process of establishing the services that the customer requires from a system –elicitation –specification –validation

19. ADMS-BIS Domain analysis The process by which you learn about the domain to better understand the problem –The domain is the general field of business or technology in which the clients will use the software Benefits of performing domain analysis –Faster development –Better system –Anticipation of extensions

20. ADMS-BIS Starting point for software projects

21. ADMS-BIS Defining the problem A problem can be expressed as –A difficulty the users or customers are facing –Or as an opportunity that will result in some benefit

22. ADMS-BIS Defining the scope Narrow the scope by defining a more precise problem List all the things you might imagine the system doing –Exclude some of these things if too broad –Determine high-level goals if too narrow

23. ADMS-BIS Defining the scope Narrow the scope by defining a more precise problem List all the things you might imagine the system doing –Exclude some of these things if too broad –Determine high-level goals if too narrow

24. ADMS-BIS Question ? Narrow the scope of a university registration system browsing courses registering fee payment room allocation exam scheduling

25. ADMS-BIS What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification –Short and precise piece of information –Says something about the system –All the stakeholders have agreed that it is valid –It helps solve the customer’s problem

26. ADMS-BIS Types of requirements 1 User requirements –Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements –A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification –A detailed software description which can serve as a basis for a design or implementation. Written for developers

27. ADMS-BIS Types of requirements 2 Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development

28. ADMS-BIS Gathering and analyzing requirements Observation –Read documents and discuss with users –Shadowing important users doing their work –Session videotaping Interviewing –Specific details –Alternative ideas –Other sources of information –Draw diagrams

29. ADMS-BIS Requirements and design In principle, requirements should state what the system should do and the design should describe how it does this In practice, requirements and design are inseparable

30. ADMS-BIS Software Requirements A Use Case Approach

31. ADMS-BIS Software Requirements The Rock Problem ?! [Ed Yourdon]

32. ADMS-BIS Software systems nature Software systems by their nature are –intangible –abstract –complex –infinitely changeable

33. ADMS-BIS Software development Goal –to develop quality software that meets customers’ needs What is this software supposed to do? How will we know when the software does exactly that and nothing else?

34. ADMS-BIS Software requirement A software requirement –is a capability needed by the user to solve a problem to achieve an objective –is imposed on the system

35. ADMS-BIS Problem domain The problem domain –is the home of those people (real users, other stakeholders) –whose needs must be addressed –in order to build the perfect system.

36. ADMS-BIS Needs Features Software requirements problem domain solution domain

37. ADMS-BIS Stage Relative cost to repair a defect Derived from: Alan Davis, Software Requirements: objects,functions and states; Prentice-Hall, 1993 Requirements time Design Coding Unit test Acceptance test Maintenance.1-.2.5 1 2 5 20

38. ADMS-BIS Functional requirements Find the solution for the user needs by proposing objectives for the system that involves –problem definition –identifying the users –defining the solution system boundary –identifying the constraints

39. ADMS-BIS Defining solutions system boundary System InputsOutputs inputs / system / outputs relationship Of concern: 1.Our system 2.Things that interact with our system actor

40. ADMS-BIS System boundary Our Solution Users Other Systems System Boundary I/O

41. ADMS-BIS System perspective New Solution Users Catalog system System Boundary Library system

42. ADMS-BIS Use Case approach Lending services User administration Books database Library user Library staff library system

43. ADMS-BIS Example Use Cases

44. ADMS-BIS NS Ticket machine – a use case approach Traveler Purchase Ticket Maintenance basic data NS Take ticket Destination

45. ADMS-BIS Use Case Modelling

46. ADMS-BIS Use Cases A use case is a set of sequences of actions a system performs that yield an observable result of value to an actor.

47. ADMS-BIS Actors An actor represent a coherent set of roles that users of use cases play when interacting with these use cases.

48. ADMS-BIS Organizing Use Cases Use cases can be organized by specifying generalization, include, and extend relationships.

49. ADMS-BIS Generalization It means that the child use case inherits the behaviour and meaning of the parent use case; the child may add behaviour of its parent.

50. ADMS-BIS Include (Uses) relationship This relationship is used when there is a common chunk of behaviour across more than one use case.

51. ADMS-BIS Extend relationship It is used to add behaviour to the base use case at certain extension points { pushing behaviour into other use cases that extend it}

52. ADMS-BIS Model the Context of a System Identify the boundaries Identify the actors Organize actors

53. ADMS-BIS Exercise: Use Cases & the context of the system A simple word processor is required to create new and edit existing documents. Also the ability to print is required.

54. ADMS-BIS Use Cases and Scenarios The behaviour of a use case can be described by a flow of events; Separate main (base) versus alternative flows; A scenario is an instance of a use-case.

55. ADMS-BIS Example of a Use Case Text

56. ADMS-BIS Template of a Use Case Text

57. ADMS-BIS Use Case Diagram Subject Use cases Actors Dependency, generalization, and association relationships

58. ADMS-BIS Model the Requirements of a System Establish the context of the system Factor common behaviour and variant behaviour into new use cases AND –Model the use cases, actors and their relationships –Describe each use case and define the scenarios

59. ADMS-BIS Exercise: NS Ticket Service machine Use Case Diagram Describe the Use Case Diagram of the NS ticket machine Describe one use case Take ticket Destination Single / Retour No Reduction / 40% reduction 2e class / 1e class

60. ADMS-BIS Use Case diagram ‘NS Ticket Service’

61. ADMS-BIS

62. Short Summary

63. ADMS-BIS Core Elements

64. ADMS-BIS Core Relationships

65. ADMS-BIS Core Relationships

66. ADMS-BIS Study Matter Ian Sommerville Software Engineering, 6 th edition – Ch.6 Addison Wesley Dean Leffingwell & Don Widrig Managing Software Requirements, 2 nd edition Addison Wesley Grady Booch, James RumBaugh & Ivar Jacobson The Unified Modeling Lnaguage – Covers UML 2.0, 2 nd edition Addison Wesley Martin Fowler UML Distilled, 3 nd edition Addison Wesley Fowler & Scott UML beknopt, 2 nd edition Addison Wesley Sander Hoogendoorn Pragmatisch modelleren met UML 2.0 Addison Wesley

67. ADMS-BIS Exercise A library lends books to borrowers, who are registered in a membership file. A borrower can reserve a book that is not currently available in the library. In a file of books the loaning or reservation of a book will be kept up to date. The librarian is an employee of the library who interacts with the customers (borrowers). o Design a simple library system for borrowing and returning books. The file of books and the membership file may be considered as actors. o Describe one or more use cases by means of a use case text.

68. ADMS-BIS Exercise Solution : UCD

69. ADMS-BIS Exercise Solution : Use Case Text

70. ADMS-BIS Exercise UCD Starting point is the MKW case Make a Use Case Diagram of the MKW system and describe the use cases with a use case text.

71. ADMS-BIS Date2date Date2date is een commerciële online dating service, waarmee singles in betrekkelijke anonimiteit contact kunnen leggen met andere alleenstaanden.  De slides m.b.t. Date2date zijn ontleend aan het boek van Sander Hoogendoorn, zie “Study Matter”.

72. ADMS-BIS Date2date : the context Date2date

73. ADMS-BIS Date2date : UCD van een Use Case (element)

74. ADMS-BIS Date2date : UCD van een Use Case (element)

75. ADMS-BIS Date2date : UCD van een Use Case (element)

76. ADMS-BIS Date2date : use case text van “versturen bericht”

77. ADMS-BIS Date2date : use case text with scenario’s

78. ADMS-BIS Next 9 Oktober 2006 Study of UML exercises and examples Each group works on Exercise UCD (slide 70)