Object-Oriented Software Development Using UML and Rational Rose


		Object-Oriented Software Development Using UML and Rational Rose Chapter 1 - Introduction Why Process Is Needed The Role of Notation The History of the Unified Modeling Language Iterative and Incremental Development The Rational Process Chapter2 - Software Lifecycle Phases Inception The Inception Phase Activities Definingthe Problem Identifying Actors Identifying Use Cases Elaboration The Elaboration Phase Activities Analyzing the Problem Domain Establishing the Architectural Foundation Developing the Project Plan Construction The Construction Phase Activities Building an Iteration Transition The Transition Phase Activities Chapter3 - Case Study Case Study Background Course Registration System Problem Statement The Role of Tools Project Summary The Inception Phase Business Goals and Needs Definition of Actors Definition of Use Cases Drawing a Use Case Diagram in Rational Rose The Elaboration Phase Development of Scenarios Creating "Real World" or "Business" Classes Software Architecture Iteration Planning The Construction Phase Construction Activities Building an Iteration The Transition Phase Chapter 1 Introduction Why Process Is Needed The Role of Notation The History of the Unified Modeling Language Iterative and Incremental Development The Rational Process Why Process Is Needed A successful development project satisfies or exceeds the customer's expectations,is developed in a timely and economical fashion, and is resilient to change and adaptation. The development lifecycle must promote creativity and innovation.At the same time, the development process must be controlled and measured to ensure that the project is indeed completed. "Creativity is essential to the crafting of all well-structured object-oriented architectures, but developers allowed completely unrestrained creativity tend to never reach closure. Similarly, discipline is required when organizing the effortsof a team of developers, but too much discipline gives birth to an ugly bureaucracy that kills all attempts at innovation." ¹A well-managed iterative and incremental lifecycle provides the necessary control without affecting creativity. The Role of Notation Notation plays an important part in any methodology - it is the glue that holds the process together. The Unified Modeling Language (UML) provides a very robust notation, which grows from analysis into design. Certain elements of the notation (for example, classes, associations, aggregations, inheritance) are introduced during analysis. Other elements of the notation (for example, containment indicators and properties) are introduced during design. "Notation has three roles: It serves as the language for communicating decisions that are not obvious or cannot be inferred from the code itself. It provides semantics that are rich enough to capture all important strategic and tactical decisions. It offers a form concrete enough for humans to reason and for tools to manipulate." ² The History of the Unified Modeling Language "UML is a language used to specify, visualize, and document the artifacts of an object-oriented system under development. It represents the unification of the Booch, OMT, and Objectory notations, as well as the best ideas from a number of other methodologists as shown in Figure 1. By unifying the notations used by these object-oriented methods, the Unified Modeling Language provides the basis for a defacto standard in the domain of object-oriented analysis and design founded on a wide base of user experience."³ The UML is an attempt to standardize the artifacts of analysis and design: semantic models, syntactic notation, and diagrams. The first public draft (version 0.8) was introduced in October, 1995. Feedback from the public and Ivar Jacobson's input were included in the next two versions (.9 in July, 1996 and .91 in October,1996). Version 1.0 will be presented to the Object Management Group (OMG)for standardization in January, 1997. *Figure 1 The Unified Modeling Language* Iterative and IncrementalDevelopment In an iterative and incremental lifecycle (Figure 2), development proceeds as a series of iterations that evolve into the final system. Each iteration consists of the following process components: requirements analysis, analysis,design, implementation, and test. The developers do not assume that all requirements are known at the beginning of the lifecycle; indeed changeis anticipated through out all phases. This type of lifecycle is a risk mitigation driven process. Technical risks are assessed and prioritized early in the lifecycle and are revised during the development of each iteration. Risks are attached to each iteration so that successful completion of the iteration mitigates the risks attached to it. The releases are scheduled to ensure that the highest risks are tackled first. Building the system in this fashion exposes and mitigates the risks of the system early in the lifecycle. The result of this type of lifecycle is less risk coupled with minimal investment.⁴ *Figure 2 Iterative and Incremental Development* The Rational Process Control for an iterative and incremental lifecycle is provided in the Rational Objectory Process--an extensive set of guidelines that address the technical and organizational aspects of software development focusing on requirements analysis and design.⁵ The process used in this book is a simplified version of the Rational Unified Process. The Rational process is structured along two dimensions: Time--division of the lifecycle into phases and iterations. Process components--production of a specific set of artifacts with well-defined activities. Both dimensions must be taken into account for a project to succeed. Structuring a project along the time dimension involves the adoption of the following time based phases: Inception--the specification of the project vision. Elaboration--planning the necessary activities and required resources; specifying the features and designing the architecture. Construction--building the product as a series of incremental iterations. Transition--supplying the product to the user community (manufacturing,delivering, and training). Structuring the project along the process component dimension includesthe following activities: Requirements analysis--description of what the system should do. Design--how the system will be realized in the implementation phase. Implementation--the production of the code that will result in an executable system. Test--the verification of the entire system. Each activity of the process component dimension is applied to the each phase of the time based dimension. Figure 3 shows how the process componentsare applied to each time based phase. *Figure 3 The Development Process* ¹ Booch, Grady. ObjectSolutions. Redwood City, Calif.: Addison-Wesley, 1995. ² Ibid. ³The Unified Method,Draft Edition (0.8), Rational Software Corporation, October 1995. ⁴ More informationon the application of an iterative and incremental approach to software development may be found in the article "A Rational Development Process"by Philippe Kruchten, CrossTalk, 9(7), July 1996, pp. 11-16. ⁵ Rational SoftwareCorporation. The Objectory Process--Introduction, 1996. This introduction may be found on the Rational Rose CD-ROM. Chapter 2 Software Lifeycle Phases Inception The Inception Phase Activities Defining the Problem Identifying Actors Identifying Use Cases Elaboration The Elaboration PhaseActivities Analyzing the Problem Domain Establishing the Architectural Foundation Developing the Project Plan Construction The Construction PhaseActivities Building an Iteration Transition The Transition Phase Activities Inception The Inception Phase Activities The purposes of the Inception Phase are to establish the business case for the system and to specify the project scope. In order to accomplish this, all external entities with which the system will interact (actors) are identified and the nature of this interaction is defined at a high level (use cases). The business case includes success criteria, risk assessment, an estimate of the resources required and a phase plan. Some projects will also develop a prototype during this phase. At the end of the inception phase, the lifecycle objectives of the project are examined and a decision as to whether or not to proceed with the project is made. Defining the Problem "The most important question to ask when developing a system is neither a methodological nor a technical question. It is a most simple question:"Is this the right system to make?" Unfortunately, this question is often neither asked nor answered."¹ During the inception phase of the development process, the appropriate questions are asked and research is performed to answer the questions. Often, a "proof of concept" prototype is created to help answer the tough development questions. The end result of this phase is a set of system requirements for the system to be developed. Identifying Actors "To fully understand the purpose of a system we have to know who the system is for, that is, who will use it."²An actor is a role played by a physical person or system when interacting with the system. Actors are discovered by examining: Who directly uses the system. Who is responsible for maintaining the system. External hardware used by the system. Other systems interacting with the system. Identifying Use Cases A use case is a specific way of using a system--some functionality is performed by the system in response to a stimulus from an actor. Use cases model a dialogue between an actor and the system. Use cases provide a vehicle to: Capture the requirements about the system. Communicate with the end users and domain experts. Test the system. "The description of a use case defines what happens in the system when the use case is performed; it corresponds to a sequence of transactions performed by the system, which yields a measurable result of value to a particular actor."³ Elaboration The Elaboration PhaseActivities The purposes of the elaboration phase are to analyze the problem domain, establish an architectural foundation, develop the project plan, and to eliminate the highest risk elements of the project. Analyzing the ProblemDomain During this phase of development scenario and class diagrams are created and matured. The diagrams initially contain "real world" or "business"classes--classes that represent the "what" not the "how". Objects and classes are discovered by examining the use cases developed during the inception phase. Scenarios (instances of a use case) are developedand graphically depicted in Sequence Diagrams. Objects in the scenarios are identified and grouped into classes. Classes are then grouped into packages. Relationships between classes are established to allow communication between the objects in the scenarios. The relationships are either associations or aggregations. An association is a bi-directional relationship between classes which defines a static or dynamic relationship between objects in the associated classes. A static relationship between objects shows the structure of the model in terms of which objects are aware of others. A dynamic relationship between objects shows how objects interact. An aggregation is a stronger form of association--it is a relationship between a whole and its parts. Attributes (structure) and operations (behavior) are added to the classes to allow the functionality of the scenarios to be accomplished. Super classes are created to hold common structure, behavior and/or relationships. Establishing the Architectural Foundation "Establishing a sound architectural foundation is absolutely essential to the success of an object-oriented project. Some teams try to ignore this phase, either because they are in such a rush to get a product out quickly they feel they don't have time to architect, or because they don't believe that architecting provides them any real value. Either way, the resulting head-long rush to code is always disastrous: fail to carry out this step properly, and your project will likely experience software melt down."⁴ The architecture of an object-oriented system is organized in terms of distinct layers. Each layer represents a coherent abstraction and contains a well-defined and controlled interface. Additionally, each layer of the system is built upon well-defined and controlled facilities at lower levels of abstraction. The architecture establishes the basic structure of the system. Executable prototypes of the architecture are built to verify that the design decisionsare correct. "Building something executable is absolutely essential, because it forces the development team to validate their design assumptions in the harsh light of reality."⁵ Software architecture is not a one-dimensional thing - it is made up of concurrent multiple views. Figure 4 shows the "4+1" views of architecture.⁶ The use case view describes the system as sets of transactions from the point of view of external actors. This view is initially created in the inception phase of the lifecycle and drives the rest of the process. The logical view contains the collection of packages, classes,and relationships. This view is initially created in the elaboration phase and matured in the construction phase. The process view contains processes, threads, inter-process communication and synchronization mechanisms. This view is initially created in the elaboration phase and matured in the construction phase. The implementation view contains modules and subsystems. This view is initially created in the elaboration phase and matured in the construction phase. The deployment view contains the physical nodes in the system and the connections between the nodes. This view is created in the elaboration phase of the process. *Figure 4 The "4+1" View of Architecture* Developing the Project Plan The project plan prescribes schedules for the iterations developed during the construction phase of development. "Such a plan must identify a controlled series of architectural releases, each growing in its functionality and ultimately encompassing the requirements of the complete production system."⁷Use cases and scenarios developed in earlier phases are the main input to this phase of design. "Scenarios should be grouped so that for each release, they collectively provide a meaningful chunk of the system's behavior and additionally require the development team to attack the project's next highest risks."⁸ The project plan is developed by following the steps outlined below: Identify and prioritize the major risks for the project. Select a small number of scenarios that address the highest priority risks."Scenarios are examined and prioritized according to risk, importance to the customer, and the need to develop certain basic scenarios early."⁹ Select the classes and relationships to be implemented by analyzing the scenarios. Implement the selected classes and relationships. Develop test cases. Test the classes and relationships to verify that the functionality ofthe scenario is carried out. Integrate and test with previous iterations. Evaluate the iteration and assign any needed re-work to a future iteration. Remember, the main reason for using an iterative approach: not all requirements are known in the beginning. It is not unusual for some risks to not be eliminated as planned, for new risks to be discovered, and for some code to be discarded due to the evaluation of an iteration. Construction The Construction Phase Activities The purpose of the Construction Phase is to develop a software product which is ready to be introduced into the user community. The product is evolved as a series of iterations. Building an Iteration Each iteration addresses a set of risks identified in the elaboration phase. An iteration is typically the implementation of one or more use cases.The process of building an iteration involves: 1. Identifying the classes and relationships to be implemented. 2. Completing the design for the selected classes and relationships: Data types for attributes. Operation signatures. Addition of other operations (for example, access, management, helping operations). Addition of implementation level classes (for example, container and controller classes). Specification of association/aggregation design decisions (for example,navigation and containment decisions). Specification of inheritance design decisions (for example, abstract classesand virtual inheritance). 3. Creating the code for the iteration. 4. Creating/updating the documentation for the iteration. 5. Testing the iteration: Does it perform the functionality specified in the use cases implementedin the iteration? 6. Integrating and testing the iteration with any previous iterations. The process of building iterations continues until the software product is complete. Transition The Transition Phase Activities The purpose of the Transition Phase is to deploy the software product into the user community and train the users. This phase typically starts witha beta release of the software product to selected users. Typically problems are discovered in the beta release and corrected in subsequent beta releases. After the beta period is complete, the product is released to the community. ¹ Rational SoftwareCorporation and Lockheed Martin. Succeeding With the Booch and OMT Methods.RedwoodCity, Calif.: Addison-Wesley, 1996. ² Rational SoftwareCorporation. The Objectory Process - Introduction. 1996. ³ Jacobson, Ivar.Object-oriented Software Engineering. Redwood City, Calif.: Addison-Wesley, 1992. ⁴ Booch, Grady.Object Solutions. Redwood City, Calif.: Addison-Wesley, 1995. ⁵ Ibid. ⁶ Kruchten,Philippe. Software Architecture and Iterative Process. Santa Clara, Calif.:Rational Software Corporation, 1994. ⁷ Booch, Grady.Object Solutions. Redwood City, Calif.: Addison-Wesley, 1995 ⁸ Ibid. ⁹ Rational Software Corporation and Lockheed Martin. Succeeding With the Booch and OMT Methods.RedwoodCity, Calif.: Addison-Wesley, 1996. Chapter 3 Case Study Case Study Background Course Registration System Problem Statement The Role of Tools Project Summary The Inception Phase Business Goals and Needs Definition of Actors Definition of Use Cases Drawing a Use Case Diagram in Rational Rose The Elaboration Phase Development of Scenarios Creating "Real World" or "Business" Classes Software Architecture Iteration Planning The Construction Phase Construction Activities Building an Iteration The Transition Phase Case Study Background Course registration at the local university is currently done by hand. Students fill out forms that contain their course selections and return the forms to the registrar. Clerks then enter the selections into a database and a process is executed to create student schedules. The registration process takes from one to two weeks to complete. The university decided to investigate the use of an online registration system. This system would be used by professors to indicate the courses they would teach, by students to select courses, and by the registrar to complete the registration process. Course Registration System Problem Statement At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions. The new on-line registration system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system, so the student can be billed for the semester. Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offering. For each semester, there is a period of time that students can change their schedules. Students must be able to access the on-line system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time. The Role of Tools Any software development method is best supported by a tool. This bookuses the tool Rational Rose 4.0. Rational Rose is organized around thearchitectural views - use case, logical, component and deployment. This case study will map the steps of the process into the views contained in the tool. Project Summary This system will have a short inception phase during which prototyping is used to select the database. The use case diagram is started in the inception phase and matured in the elaboration phase. By the end of the elaboration phase, an architectural iteration is complete. The system is evolved in the construction phase in two iterations. The process components of requirements analysis, design, implementation and test are used in allp hases of the project lifecycle. The Inception Phase Business Goals and Needs The first question to address is the need for a new registration system. Does the University have the resources needed to design and implement the new system? In addition to the assessment of need for the system, the risks posed by the new system are elaborated. In the case of an on-line registration system, one of the major risks is the ability to store the informationin a manner that is easily and quickly accessible by all. For the purposes of this case study it was decided that the new systemshould be built. Prototypes were completed to address the database risks. Definition of Actors The following actors were defined for the problem: Student--someone who is registered to take courses at the University. Professor--someone who is licensed to teach at the University. Registrar--someone who is responsible for the maintenance of the RegistrationSystem. Billing System--external system that bills students each semester. Definition of UseCases The following use cases were elaborated for each actor: Student Register for courses. Professor Select courses to teach. Request course offering roster. Registrar Generate course catalogue. Maintain professor information. Maintain student information. Maintain curriculum. Drawing a Use Case Diagram in Rational Rose The use case diagram is contained within a class diagram in the use case view of the tool. Actors are shown as stickmen and use cases are shown as ovals. The use case diagram is shown in Figure 5. *Figure 5 Use Case Diagram* A brief description is created for each use case. The brief descriptionis entered in the Documentation field of the use case specification inthe tool. The brief description of each use case follows: Register for courses The use case is started by the student. It provides the capability to create,review, modify, and delete a course schedule for a specified semester.All pertinent billing information is sent to the Billing System. Request class roster This use case is started by the professor. It provides the capability to request a printed list of all students assigned to a specified course offering. Select courses to teach This use case is started by the professor. It provides the capability to select, review, modify, and delete a list of courses to teach for a specifiedsemester. Maintain professor information This use case is started by the registrar. It provides the capability to create, review, modify, and delete professor information. Maintain student information This use case is started by the registrar. It provides the capability to create, review, modify, and delete student information. Maintain curriculum This use case is started by the registrar. It provides the capability to create, review, modify, and delete a list of course offerings for a givensemester. Generate catalogue This use case is started by the registrar. It provides the capability to generate a catalogue containing a list of course offerings for a specifiedsemester. During Inception, the flow of events (including any identified alternateflows) for the most important use cases is documented. In Rose 4.0, the flow of events is entered via a link to an external document. The flow of events for the Register for Courses use case is shownbelow. Flow of Events: Register for Courses Use Case This use case begins when the student enters the student id number.The system verifies that the student id number is valid and prompts the student to select the current semester or a future semester. The student enters the desired semester. The system prompts the student to select the desired activity: Create a schedule. Review a schedule. Change a schedule: Delete a course. Add a course. The student indicates that the activity is complete. The system will print the student schedule and notify the student that registration is complete.The system sends billing information for the student to the billing system for processing. Alternate flow If an invalid id number is entered, the system will not allow access to the registration system. If an attempt is made to create a schedule for a semester where a schedule already exists, the system will prompt for another choice to be made. Create a Schedule The student enters 4 primary course offering numbers and 2 alternate course offering numbers. The student then submits the request for courses.The system then: Checks that prerequisites are satisfied for the requested course. Adds the student to the course offering if the course offering is open. Alternate flow If a primary course offering is not available, the system will substitutean alternate course offering. Review a Schedule The student requests information on all course offerings in which the student is registered for a given semester. The system displays all courses for which the student is registered including course name, course number,course offering number, days of the week, time, location, and number of credit hours. Change Schedule - Delete a Course The student indicates which course offerings to delete. The system checks that the final date for changes has not been exceeded. The system deletes the student from the course offering. The system notifies the student that the request has been processed. Change Schedule - Add a Course The student indicates which course offerings to add. The system checks that the final date for changes has not been exceeded. The system then: Verifies that the maximum course load for the student has not been exceeded. Checks that prerequisites are satisfied for the requested course. Adds the student to the course offering if the course offering is open. The Elaboration Phase During Elaboration, some of the most important and critical use cases are implemented. During this phase, the focus is good class structure and architecture. Development of Scenarios Each use case is a web of scenarios. Scenarios are documented using Sequence Diagrams. Objects are represented as vertical lines and messages between objects are shown as directed horizontal lines. Sequence diagrams are drawnin the Use Case View of the tool. The Sequence Diagram for the Add a Course scenario is shown in Figure 6. *Figure 6 Sequence Diagram for the Add a Course Scenario* Creating "Real World"or "Business" Classes Objects are discovered by examining the use cases and scenarios and grouped into classes. Each class should have a definition which states the purpose of the class. Packages are created to hold logical groups of classes. Classes and packages are drawn in the Logical View of the tool. The following packages and classes have been created for the registration system: People StudentInfo--Information about the student actor needed by the registration system (for example, name, address, phone, idNumber, major, gradDate). ProfessorInfo--Information about the professor actor needed by the registration system (for example, name, address, phone, idNumber, tenureStatus). UniversityArtifacts Course--General information about selections for a semester (for example,name, description, creditHours). CourseOffering--Specific information about selections for a semester (forexample, daysOffered, timeOfDay, location). StudentSchedule--Output report containing the list of registered course offerings generated when a student registers for a course. CourseRoster--Output report containing the list of registered studentsfor a specific course offering generated for a professor. Interfaces RegistrationForm--Form which provides the capability for a student to select registration options. Add/DropForm--Form which provides the capability for a student to modify a course schedule. CourseSelectionForm--Form which provides the capability for a professor to add/drop courses to teach. StudentMaintenanceForm--Form which provides the capability for the registrar to add/delete/modify student information. ProfessorMaintenanceForm--Form which provides the capability for the registrar to add/delete/modify professor information. CourseMaintenanceForm--Form which provides the capability for the registrar to add/delete/modify course and course offering information. Class diagrams are created to graphically depict the packages and classes in the model. The Main class diagram typically contains only packages.Each package contains its own class diagrams. The Main class diagram fora package contains the public classes of the package (classes that communicate with classes in other packages). Other class diagrams are created as needed. Class diagrams are contained in the Logical View of the tool. Use cases and scenarios are examined to determine the relationships needed by the system. Relationships between classes are created and displayed on selected class diagrams. Attributes (structure) and operations (behavior) are added to the classes to carry out the functionality specified in the use cases. Sequence diagrams are updated to show the allocation of objects to classes and the replacement of messages with operations. Some class diagrams for the Registration System are shown in Figures7 through 11. An updated sequence diagram is shown in Figure 12. *Figure 7 Main Class Diagram* *Figure 8 Main Class Diagram for the People Package* *Figure 9 Main Class Diagram for the University Artifacts Package* *Figure 10 Course Reporting Class Diagram in the UniversityArtifactsPackage* *Figure 11 Main Class Diagram for the Interfaces Package* *Figure 12 Updated Sequence Diagram* Software Architecture As the elaboration phase of development continues, decisions concerning the architectural framework for the project are made. Scenarios are updated to show the interaction of the real world objects with the objects representing the architectural decisions. Packages and classes that carry out the architectural functionality are added to the logical view. In the Course Registration system, the following architectural decisions were made: Containers and GUI classes to be used are in the MFC class library. A commercial relational database was chosen and classes to communicate with the database were created. A set of error classes were created to facilitate common error handling strategies. The updated Main Class Diagram and an updated Sequence Diagram are shownin Figures 13 and 14. *Figure 13 Main Class Diagram* *Figure 14 Updated Sequence Diagram* The next step is to implement a set of scenarios that address the major architectural issues. This is done to ensure early feedback and identification of problems. For this problem, the Maintain Curriculum Use Case was implemented since it addressed the major risk of this system--the database risk. Iteration Planning Another activity in the elaboration phase is the creation of the iteration plan. The goal of an iteration is to reduce risk in the system while incrementally building the final product. Use cases and scenarios are examined and prioritized to create the initial project plan. As each iteration is completed, risks are re-evaluated and the project plan is updated as needed. For the Course Registration system the iteration plan is: Iteration 1 Maintain curriculum. Iteration 2 Maintain student info. Maintain professor info. Select courses to teach. Generate catalogue. Iteration 3 Register for courses. Request class roster. The Construction Phase Construction Activities During Construction, all remaining scenarios will be specified and implemented.At this time, many of the secondary scenarios are addressed. Building an Iteration This case study concentrates on the "Add a Course" scenario which is shown in Figure 14. During this phase of development, the classes that participate in the iteration are designed and implemented. Class diagrams are created to show the focus of the iteration. For the Course Registration problem, the following design decisions are made: Controller class--CurriculumManager added. This class knows the business rules associated with the management of a curriculum. Scenario diagrams are updated to show new interactions with the CurriculumManager. Some interactions between objects are deleted due to the addition of the controller. Data types and signatures are provided for all attributes and operations. Association navigation is designed. Associations are changed into dependency relationships where appropriate. An updated Sequence diagram showing the interaction with the added controller class is shown in Figure 15. *Figure 15 Updated Sequence Diagram* Add a Course A package called Iteration 1 is added to the logical view of the model.Class diagrams showing the classes in the iteration are added to the package. A class diagram showing the design decisions made for the "Add a Course"scenario is shown in Figure 16. *Figure 16 Class Diagram "Add a Course"* The code for the iteration is completed and the iteration is tested and documented. The completed iteration is integrated with any previous iterations. The Transition Phase The system was successfully transitioned to the University community intwo releases--beta and the final system. During the beta period, bugs were discovered, reported and fixed by the development staff. After using the beta version of the system, professors added the requirement to view aclass roster on-line. This requirement was successfully implemented and available in the final release of the system. Students and professors were pleased with the time savings provided by the paperless system. Due to the success of the Registration System it was decided that another version of the system should be developed to provide an on-line catalogue of course offerings. Budgets and staff were approved and the process began again.