Bouwkundige Informatiesystemen ADMS 2006 UML part 1

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

2. Subjects • Software Engineering • Software Requirements • Introduction • A use case approach • UML : Use Case Modelling • Exercise UCD • Discussion exercise UCD • UML Introduction • UML : Activity Diagram • Microsoft Visio • Task UML-part 1

3. Software Engineering

4. 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. Software Engineering – Why ? Software problems • Bugs: low quality • High cost: budget overrun • Late delivery: schedule overrun

6. 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. 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. What is software Computer programs and associated documentation

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

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

11. 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. Stakeholders in software engineering • Users • Customers (clients) • Software developers • Development managers

13. 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 Quality Software 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. Software Quality • Usability • Efficiency • Reliability • Maintainability • Reusability

15. 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. 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. Software RequirementsIntroduction

18. 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. 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. Starting point for software projects

21. 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. 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. 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. Question ? Narrow the scope of a university registration system browsing courses room allocation registering exam scheduling fee payment

25. 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. 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. Types of requirements 2 • Functional requirements Describe what the system should do • Non-functional requirements Constraints that must be adhered to during development

28. 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. 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. Software Requirements A Use Case Approach

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

32. Software systems nature • Software systems by their nature are • intangible • abstract • complex • infinitely changeable

33. 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. 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. 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. problem domain Needs Features solution domain Software requirements

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

38. 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. Defining solutions system boundary System Inputs Outputs inputs / system / outputs relationship • Of concern: • Our system • Things that interact with our system actor

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

41. System perspective NewSolution System Boundary Library system Users Catalog system

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

43. Example Use Cases

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

45. Use Case Modelling

46. 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. Actors • An actor represent a coherent set of roles that users of use cases play when interacting with these use cases.

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

49. 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. Include (Uses) relationship • This relationship is used when there is a common chunk of behaviour across more than one use case.