Evaluation of UML and Tools

We all enjoyed working with these UML diagrams on a real-world project. We struggled a bit at first with our Use Case diagram, but quickly refined it into a well working model. We think our Class Diagram and Domain Class Diagrams turned out very well. We had the most trouble with our Sequence Diagrams and System Sequence Diagrams, but hope with our thorough study of the book, and some very helpful YouTube videos, they turned out well.

61 References

Booch, G. 1994. Object-oriented analysis and design. Redwood City, Calif. [u.a.]: Benjamin/Cummings.

Coad, P. and Yourdon, E. 1991. Object-oriented analysis. Englewood Cliffs, N.J.: Yourdon Press. Dl.acm.org. 1999. Object-Oriented Analysis and Design of a Health Care Management Information

System. [online] Available at: http://dl.acm.org/citation.cfm?id=314752 [Accessed: 10 Jul 2013].

Informationweek. 1997. 10 Top Medical Practice Management Software Systems. [online] Available at: http://www.informationweek.com/healthcare/admin-systems/10-top-medical-practice-

management-softw/232602435?pgno=3 [Accessed: 10 Jul 2013].

Irs.gov. 2003. HCTC Program HIPAA Statement and Disclaimer. [online] Available at:

http://www.irs.gov/Individuals/HCTC-Program-HIPAA-Statement-and-Disclaimer [Accessed: 11 Jul 2013].

Mclaughlin, B., Pollice, G. and West, D. 2006. Head first object-oriented analysis and design. Sebastopol [etc.]: O'Reilly.

Office.microsoft.com. 2007. Schedule a meeting with other people - Outlook - Office.com. [online] Available at: http://office.microsoft.com/en-us/outlook-help/schedule-a-meeting-with-other-people- HP001230384.aspx [Accessed: 11 Jul 2013].

Pender, T. 2003. UML bible. Indianapolis, IN: Wiley. Umsl.edu. 2001. I. [online] Available at:

62 Appendix

1.1 Lessons Learned

Claire King

The most important lesson I learned from the final project was that with each discrete step of modeling process (i.e., Use Case Diagram to the Domain Model and from the Domain Model to the Design Class Diagram), it honed my understanding of the actors, entities and classes required for the development of a system solution. I also discovered that with each diagram developed, my perspective would change and would “iteratively” refine the current model to more accurately fit problem domain. The significance of the Use Case Diagram as a foundational model was not lost on me. In fact, I used a similar format to illustrate Drexel University’s College of Medicine clinical research process for five different Use Cases.

The other important lesson I learned was how the Design Class Diagrams portray

functional interactions between the classes in a very clear and concise manner. I can now see how, if the design class diagram is well made, it can generate code.

Christie McHargue

Lessons learned:

1. So many!! I have a basic understanding of how all of the different iterations of a project can change, and change for the good.

2. Designing a process without delving deeply into it’s process, actors and needs is doomed for failure

3. I learned that actually going through the process of each step brings a team so much closer (and sometimes farther away) to where they need to be.

4. I learned that everyone is at a different level of concept and understanding and while that isn’t always the best, everyone can bring something to the table.

5. I learned how to grow with a team, how to accept and do the best I can do, and to play to each person’s strength.

6. I learned there is always one or two people who know so much more and I am very grateful for this.

7. I learned learning is going to take some time but in the end it is all worth it. 8. I also learned Dr. Mo is a caring and considerate and thoughtful professor who

genuinely cares for her class, just wish it was in person. This has been an incredible amount of work, I just wish I had more time to soak it in.

63

Laila Montanez

I have learned many lessons during the completion of this project, the most important being to continue to put forth an effort because eventually it will all come together. I have learned to read, read, and re-read the material while accepting that I may have to re-do a diagram ten times before it becomes acceptable. Taking the time to create a good use case seems to be the foundation of domain models, design class diagrams, and system

sequence diagrams.

Sarah Neergaard

I think the most important lesson learned here is that the iterative process is not as quick and easy as I had originally thought! We spent a lot of time going over details and then changing things around to meet the requirements. It was great to be part of a design team, and we spent many hours over Skype working out all of our project quirks! I learned a lot more about creating all of these diagrams than I did from just reading the text, and it was especially nice to apply them to a real-world model.

1.2 Division of work among team members

All Members- Problem Statement, Functional Requirements, Data Requirements, Business Rules and Logic, Non-Functional Requirements, Use Case Descriptions, Sequence Diagrams, System Sequence Diagrams, Evaluation

Claire King- TCM Table, Domain Diagram, Design Class Diagram Christie McHargue- ERD, Relational Database Schema

Laila Montanez- Use Case Discussion, Class Model Discussion, Validation and discussion of Sequence Diagram, Validation and Discussion of Design Class Diagram Sarah Neergaard- Use Case Diagram, Use Case Overview, Final Report

1.3 Unsolved Problems

We did not solve the problem of notifications; we missed putting it on the use case diagram. (There was no digital notification of a patient cancelled an appointment). We also missed connecting labs and prescriptions to patient history, did not effectively relate them back. Solved problem in Design Class Diagram.