Room Booking System - Simplify and Automate Room Booking Process

1. Appendix ATerminology

2. Terminology Feature: Requirement with a business value Functional requirement: A functional feature Iteration: A time box to develop a limited number of features Non-functional requirement: A quality-related feature Product owner/PO: The user representative in a Scrum context Scenario: A particular example of a use case for certain given conditions Scrum master: The team enabler in a Scrum context Sprint: A Scrum iteration Task: Partial engineering work, part of a feature Team: The developers implementing features in a Scrum context Technical dept: Work needing to be done to have a healthy system Use case: Class of business functionality User story: A hint of a feature to be discussed further with the PO [Fowler] Extract Method [Fowler03b] Who needs an architect?

3. Appendix BRoom Booking System

4. Room Booking System – Key Features Scheduling for meetings and conference rooms Start of meeting, duration, number of attendees User defined set-up for rooms Room name, number of seats, size Notification for meetings by e-mail to participants and staff Booking of catering items from catering suppliers Price, description Book

5. Room Booking – Product Description Room Booking System (RBS) RBS should be designed to automate and simplify the booking and tracking of rooms. It should be a multi user application designed to support high volumes of bookings for large offices and facilities. When a meeting is booked, RBS should be able to notify the participants and necessary staff by e-mail. An administrator can configure rooms and manage users, staff etc. Key Features: Scheduling of unlimited number of meeting and conference rooms Custom configured rooms, user-definable room features and set-up Automatic confirmation reports for printing, faxing or e-mail delivery Notification of meetings by e-mail to participants and staff Call-back to the client upon confirmation from all the participants Booking and inventory of audio/visual equipment Complex daily, weekly and monthly repeated bookings Timeline view for visual, interactive room booking and management Support for fixed holidays and closures Booking, tracking and reporting of catering items and catering suppliers

6. Time Line View A timeline provides a view of rooms in a Gantt-chart styled view, providing a real time view of bookings and vacancies. Double click any displayed booking to quickly select it for editing or double click a vacant room and timeslot to quickly add a new booking. 08:00 09:00 10:00 11:00 12:00 Room 10B 16W New Edit Rooms Dates

7. Detailed Booking - Dialog 10B Attendees Room Reserved by Roger Moore Staff Phone 423-1978 ex 1024 Catering Date 05.05.2002 Notes Start Time 09:00 Duration 2:00 Equipment Room Repeats Cancel Update Help

8. Detailed Booking – Dialog (continued) RBS supports complex repeated bookings for meetings that recur on any daily, weekly, or monthly basis. Users can interactively select the frequency of the repeated booking as well as the start and end dates. An option is also provided to include or exclude weekends for repeated dates that may fall on non-weekdays. The system provides the option of moving a conflicting booking to another available timeslot, while maintaining the integrity of the repeated booking. When a booking is made, the room is reserved and the participants will automatically be notified through e-mail. The reservation is not confirmed until all participants have replied the e-mail with an OK. It is possible to queue for a room that is not yet confirmed, to become available. When a room is reserved, the staff responsible for the equipment is also notified. The staff will reply when all the equipment is arranged for.

9. Catering Items Items can be select from a previously configured list of suppliers and available items. Selected catering items and quantities are automatically linked to individual bookings to ensure that the correct items are delivered to the specified room at the correct time. A catering report is also available, check lists, all catering requirements for a specified time period and/or room. Supplier Item Amount Price ($) Duncan's Donuts 30 10.00 Duncan's 15 Coke 12.00 Systemet 200.00 2 Upper ten 222.00 Total= New Item Delete Order Cancel

10. Booking List - Dialog The booking list illustrates today’s bookings. The operator can select to view bookings for another day by clicking on the Date button. If he double clicks on a booking or if he uses the Select button when a booking is selected, the detailed information for that booking will be displayed. End Start Date 09:00 05.05.2002 09:00 12:00 12:00 06.07.2002 Room 10B 12X Time-Line View New Booking Select Date

11. Login Dialog Administrators can interactively configure the various system options: Administrate regular users (who can book rooms) and anonymous users (who can display bookings but cannot change anything) Update catering lists of common catering selections available Configure A/V items available for assignment to room bookings Configure catering service suppliers and items Configure holidays Backup the database Administrator User Password ************** Login Change Password Cancel Help

12. Order Report – Dialog Available reports Room Bookings - displays all booking details in a selected date range Catering Report - displays only bookings with catering requirements Audio/Visual Items - displays an inventory of A/V items available Room Statistics - displays bookings by day of the week, total A/V bookings and average booking duration Room Bookings 10 Floor Catering Report Room 10B Start Date 01:05:2002 Audio/Visual Items End Date 01:06:2002 Room Statistics Floor Room Help

13. Room Set-up - Dialog The dialog illustrates how a room can be set up by the manger. The list of possible features is configured in a separate dialog. The features supported by the RBS database include an unlimited number of rooms, room features, AV items and catering items. 10B Features Room Location Simcence Place Flip Chart  Description North-East Meeting Room Project Screen  Floor 10  White Board Phone 423-1978 ex 324 Stackable Panels Maximum Attendees 8 Overhead  Search Update Cancel Help Description

14. Fixed Holidays Fixed holidays and closures can be marked on the holiday screen dialog. Any time a booking is attempted on a system registered holiday, a dialog is presented allowing you to either proceed with the booking on the holiday or to shift the booking forwards or backwards to another available date. Tu Mo Th Fr We Week 18 19 20 21 22 Next Prev Default Search

15. Appendix C –Some Basic Object Design and Refactoring Principles Understanding responsibilities is key to good object-oriented design Martin Fowler With kind permission of ProgramUtvikling as

16. Contents This appendix develops on some basic, object-oriented principles The principles are some of the foundations for building reliable, changeable software systems All of them may be realized with object-oriented technology The following design and refactoring principles are covered High Cohesion Data Encapsulation Information Expert Separation of Concerns Delegation Uniform Access Command-Query Separation Single Choice – DRY (Don’t Repeat Yourself) • Open-Closed • Tough Love • Organized Panic • Stop The Line • Replace Magic Number with Symbolic Constant • Extract Method • YAGNI – You Ain’t Gonna Need It • Principle of Least Surprise

17. Good Design • A piece of software that fulfils its requirements and yet exhibits any or all of the following three traits has a bad design • Rigidity: It is hard to change because every change affects too many other parts of the system • Fragility: When you make a change, unexpected parts of the system break • Immobility: It is hard to reuse in another application because it cannot be disentangled from the current application • Moreover, it would be difficult to demonstrate that a piece of software that exhibits none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfils all its requirements, has a bad design. • Thus, we can use these three traits as a way to unambiguously decide if a design is ”good” or ”bad” [DIP] Dependency Inversion Principle

18. High Cohesion Principle Problem How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling? Principle Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives. Comments In terms of object design, conesion (of more specifically, functional cohesion) is a measure of how strongly letated and focused the responsibilities of an element are. An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion. These elements include classes, subsystens, and so on. [Larman, Grasp]

19. Data Encapsulation Principle Problem How to present a well defined set of operations expressing the intentions for a class, and supporting correct us over time? Principle Treat the operations offered as an interface. Encapsulate the implementation to make it invisible and secure the operations with preconditions. Comments The implementation may be secured through preconditions The operations may have intelligible descriptions The implementation may be freely replaced by another one [Rusty, Encapsulation]

20. Information Expert Principle Problem What is a general principle of assigning responsibilities to objects? Principle Assign a responsibility to the information expert – the class that has the information necessary to fulfill the respoinsiblilty. Comments Start assigning responsibilities by clearly stating them A design may define thousands of classes and responsibilities Assigning responsibilities well makes is easier to understand, maintain, and extend and offers more opportunities to reuse of components [Larman] Chapter 17

21. Separation of Concerns Principle Problem How to avoid uncertainty about the responsibilities of an object? Principle Modularize or separate distinct concerns into different areas, so that each has a cohesive purpose. Comments This is an application of the High Cohesion principle It achieves prominence during architectural analysis, to keep objects in a layer strongly related to each other and not mixed with responsibilities of other layers. [Larman] Pp 441, 204, 554

22. Delegation Principle Problem How to handle a complex task in an intelligible way, so that each part of the task is done by the most qualified object? Principle Hand over the responsibility of partial tasks to named operations of the Information Experts of those tasks. Your task is reduced to synthesizing a series of tasks delegated to others. Comments Delegation may be ”the” most common OO ”design pattern” As a result, object-oriented methods rarely exceed around 10 lines Successful use of extensive delegation requires quality modelling [Larman] Chapter 17

23. Uniform Access Principle Problem How to allow a property of an object to be either stored or computed, and to allow this decision to change over time without affecting the clients? Principle Supply the service in a uniform notation, which does not betray whether it is implemented through storage or through computation. Comments In Java, getters are frequently used to get the value of properties, whether they are stored or computed. The syntax is that of a method. In Boo and C#, properties serve the same purpose, in the syntax of an attribute. [Meyer] Chapter 3

24. Command-Query Separation Principle Problem How to avoid that if a function is called repeatedly, it returns different answers and the confusion that may follow? Principle Functions should not produce observable side effects Comments Traditional style for getting the top element of a stack topElement = aStack.Pop() Pops off the top element and returns its value Gives different result each time Cleaner style Separate getting the top element and removing it Query: topElement = aStack.Top() Command: aStack.Pop() [Meyer] Chapter 23

25. Single Choice Principle Problem How to allow variants of a module without having to update all the client software whenever a new variant appears? Principle Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. Solution This may be achieved with polymorphism objects through dynamic binding DRY generalizes to duplication of information at all Information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency [Meyer] Chapter 3

26. Open-Closed Principle Problem How to allow a module to be closed Given a well-defined, stable description So as to be available for use by other modules And at the same time be open Available for further extensions For instance new operations or data structures? Principle Modules should be both open and closed Comments Use inheritance to add new functionality to a module, without having to alter the base, still benefiting from potential improvements in the first module [Meyer] Chapter 3

27. Tough Love Principle Problem How to avoid situations in which a software module needs to take decisions for which it does not have the necessary context? Principle You may serve your clients better by being more restrictive Comments Use demanding design contracts with strong preconditions Makes clients responsible for ensuring validity of calls Supplier promises meaningful results in all defined cases Supplier avoids situations where it lacks appropriate context Precondition restrictions should be reasonable Justifiable in terms of the specification only [Meyer] Page 362

28. Organized Panic Principle Problem How to handle an exception that occurs during the execution of a routine? Principle There are only two legitimate responses: Retry from start, if that has any chance to succeed, or Fail, indicating that you could not assert the routine’s postcondition Comments Failure is through ”Organized Panic” Clean up the environment, make sure all invariants are reestablished and report failure to the caller through an appropriate exception. Under no circumstances should the routine return normally if it was not possible to establish the postcondition The caller in turn should follow the same strategy [Meyer] Page 417

29. Stop The Line Principle Problem How to detect anomalies that occur during production, so that the cause for the problem may be remedied, to prevent a disease from spreading or repeating? Principle To avoid the disease from spreading, the system must be halted Comments: Stop the line Let the program autonomatically shut down automatically as soon as it detect an anomaly Take actions to draw immediate attention to the problem Unless life critical, despite the deficiencies, do not restart the system until the cause of the problem has been detected and remedied Similar to our autonomic coughing when swallowing something bad or withdrawing the hand if we touch something hot [Poppendieck] Page 6, 139

30. Replace Magic Number with Symbolic Constant Problem You have a literal number with a particular meaning Principle Create a constant, name it after the meaning, and replace the number with it Code Smells are hints that the code is not well structured. Magic numbers are not explanatory and are fragile. They should be avoided. Comments For example: in return 4.0 * Seats Replace the magic number 4.0 with a symbolic constant final ventilationPerPerson = 4.0 return ventilationPerPerson * Seats [Fowler] Replace Magic Number with Symbolic Constant

31. Extract Method Problem You have a code fragment that can be grouped together Principle Turn the fragment into a method whose name explains the purpose of the method Comments For example, in def GetLast() as Room: current = first while current.Next != null: current = current.Next return current.Value Extract the body to a method GetLastNode() and replace it by return LastNode().Value [Fowler] Extract Method

32. YAGNI – You Ain’t Gonna Need It • Problem: How to avoid • Taking time from adding, testing or improving necessary functionality • Debugging, documenting, and supporting features not asked for • Constraints preventing implementing a necessary feature later • Defining improperly what a feature should do and to test it • Code bloat; the software becoming larger and more complicated • Unspecified and unrevised features unknown to programmers who could make use of it • Suggesting other, unneeded features, resulting in a snowball effect • Principle • Programmers should not add functionality until it is necessary • Solution • Stick to the prioritized, fully known requirements [YAGNI]

33. Wikipedia: Principle of Least Surprise • In user interface design, programming language design, and ergonomics, the principle (or rule) of least astonishment (or surprise) states that • When two elements of an interface conflict or are ambiguous, the behaviour should be that which will least surprise the human user or programmer at the time the conflict arises, because the least surprising behaviuor will usually be the correct one • Corollary: In programming, name the classes, functions and variables to reflect the usage or outcome • Name classes after which concept they represent, not what they do • Name functions after what they result in, not what they do • E.g. product(a, b) rather than multiply(a, b) • Name variables after their intention, not simply their value [astonish] Principle of least astonishment

34. Appendix DSome Architectural Patterns

35. Separate Presentation Ensure that any code that manipulates presentation only manipulates presentation, pushing all domain and data source logic into clearly separated areas of the program How it Works This pattern is a form of layering, where we keep presentation code and domain code in separate layers With the domain code unaware of presentation code It is good to use logical packaging (.NET namespaces) to separate the layers But not required When to use it Most of examples you'll see from me follow Separate Presentation, simply because I find it such a fundamental design technique [Fowler-06] Development of Further Patterns of Enterprise Application Architecture

36. Observer Synchronization Synchronize multiple screens by having them all be observers to a shared area of domain data How it works Each screen, with its associated screen state, acts as an observer on a common area of session data All changes to the session data implicitly result in events which the screens listen to and respond by reloading from the session data Even the screen that makes the change doesn't need to refresh itself explicitly The observer mechanism will trigger the refresh in the same way as if another screen made the change When to use it When you have multiple active windows that share common data [Fowler-06] Development of Further Patterns of Enterprise Application Architecture

37. Flow Synchronization Synchronize screens with an underlying model based on the flow of the user interaction between the screens How it Works Each time you do something that changes state that's shared across multiple screens, you explicitly tell each screen to update itself Every screen is somewhat coupled to the other the other screens in the application When to use it If the user interface is simple Only one or two screen are active at the same time Sequences of screens (such as wizards) A root screen with modal children [Fowler-06] Development of Further Patterns of Enterprise Application Architecture

38. Façade Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. Goal To minimise the communication and dependencies between subsystems. Applicability You want to layer your subsystems. Use a façade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communication with each other solely through their façades. [Gamma] Design Patterns, Elements of Reusable Object-Oriented Software

39. Service Stub Removes dependence upon problematic services during testing Enterprise systems often use services out of the developer’s control Breaks development and testing process when not available Make a gateway interface (or abstract class) defining the service In a separate package, implement the service against the supplier Also implement the service using a simple stub implementation Use a factory method to instantiate the service implementation A Plugin allows decision to be made through configuration [Fowler-03] Patterns of Enterprise Application Architecture

40. Service Stub Environment

41. Appendix EReferences

42. References (1 of 3) [astonish] Wikipedia, Principle of least astonishment, http://en.wikipedia.org/wiki/Principle_of_least_astonishment, as of 16 June 2006 [Backlog item practice] Agile Game Development, Proper product backlog item practice?, http://groups.google.com/group/Agile-Game-Development/browse_thread/thread/63130cbe4edd6b75/b43d5598d6308082?#b43d5598d6308082 as of 28 Sep 2007 [DIP] ObjectMentor, The Dependency Inversion Principle, http://www.objectmentor.com/resources/articles/dip.pdf as of 24th of September 2007 [Feather.UnitTestRulz] Michael Feathers, Unit Test Rulz,http://tech.groups.yahoo.com/group/extremeprogramming/message/111829 as of Sep 6, 2005 [Fowler] Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley [Fowler.CI] Martin Fowler, Continuous Integration, http://martinfowler.com/articles/continuousIntegration.html as of 01 May 06 [Fowler03b] Martin Fowler, Who needs an architect?, IEEE Software, July/August 2003, http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf as of 2006-09-29 [Kniberg 08] Henrik Kniberg, Technical Debt - How not to ignore it, Presentation at Agile2008, Toronto, http://blog.crisp.se/henrikkniberg/2008/08/08/1218174720000.html as of 080808 [Larman, GRASP] General Responsibility Assignment Software Principles, Craig Larman, Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design and Iterative Development,, Third Edition, Pearson Education, 2005, ISBN 0-13-148906-2

43. References (2 of 3) [Malan] Malan, Bredemeyer, Less is More with Minimalist Architecture, IT Pro, Sept/Oct 2002, p. 48 [Meyer] Meyer, Bertrand, Object-Oriented Software Construction, Second Edition, Prentice Hall, 1997, ISBN 0-13-629155-4 [MoSCoW] Wikipedia, MoSCoW Method, http://en.wikipedia.org/wiki/MoSCoW_Method as of 25 July 2008 [MSF] Microsoft Solution Framework, http://msdn.microsoft.com/vstudio/teamsystem/msf [PU] Course material, ProgramUtvikling as, http://programutvikling.no [Pareto] Wikipedia, Pareto principle, http://en.wikipedia.org/wiki/Pareto_principle as of 31 July 2008 [Planning Poker] Wikipedia, Planning poker, http://en.wikipedia.org/wiki/Planning_poker as of 29 July 2008 [Poppendieck 06] Mary and Tom Poppendieck, Implementing Lean Software Development, From Concept to Cash, Addison Wesley 2006, ISBN 0-321-43738-1, http://www.poppendieck.com/ilsd.htm [Royce 70] Dr. Winston W. Royce, Managing the Development of Large Software Systems, Proceedings, IEEE WESCON, August 1970, pages 1-9, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf (Aug 2, 2008)

44. References (3 of 3) [Rusty, Encapsulation] Elliotte Rusty Harold, The Three Reasons for Data Encapsulation, http://cafe.elharo.com/java/the-three-reasons-for-data-encapsulation/, June 1st, 2006 [Scrum 07] Advanced Development Methods, Inc, What is Scrum?, http://www.controlchaos.com/about/, Jan. 2007 [TWISTING THE TRIAD] Andy Bower, Blair McGlashan, TWISTING THE TRIAD, The evolution of the Dolphin Smalltalk MVP application framework, Tutorial Paper for ESUG 2000, http://www.object-arts.com/papers/TwistingTheTriad.PDF [Waterfall] Wikipedia, Waterfall model, http://en.wikipedia.org/wiki/Waterfall_model as of 29 July 2008 [YAGNI] XP, c2Wiki, You Ain’t Gonna Need It, an ExtremeProgramming practice, http://www.extremeprogramming.org/rules/early.html as of 2008-08-02, http://c2.com/cgi/wiki?YouArentGonnaNeedIt as of 2007-09-24