1 / 78

Bouwkundige Informatiesystemen ADMS 2006 UML part 1

ADMS-BIS. Bouwkundige Informatiesystemen ADMS 2006 UML part 1. Jan Dijkstra - 25 september 2006. Subjects. Software Engineering Software Requirements Introduction A use case approach UML : Use Case Modelling Exercise UCD Discussion exercise UCD UML Introduction

keita
Download Presentation

Bouwkundige Informatiesystemen ADMS 2006 UML part 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related