UML Case Study

1. UML Case Study Stephanie Fultz

2. Overall Modeling • Modeling is a way of thinking about the problems using models organized around the real world ideas. • A modeling method comprises a language and also a procedure for using the language to construct models. • Modeling is the only way to visualize your design and check it against requirements before your crew starts to code. 

3. Overall Tips Using UML • Know and Understand what you want to model and why it is worth modeling • Never Assume Prior Knowledge • Find the most appropriate UML technique that exists • Ensure users and customers do not associate the UML model with the tool that is creating it • Allow time for people to learn • Make Standards on how to apply the specific model • Create processes • Introduce technique to all stakeholders • Apply in daily work • Get Feedback • Be Flexible

4. Advantages • Provides communication • Intra-project communication, e.g. getting things across between team project members • Inter-project / post-project communication, things to be understood at later date • Most of the time people who are initially making the software are not the ones maintaining it or servicing it • You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML • UML is effective for modeling large, complex software Systems • It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects • Use case modeling specifies the functional requirements of system in an object-oriented manner

5. Disadvantages • People have to be familiar with UML • Managers as well as programmers • Not everyone sees the advantage of using it • Development tools adopted don’t not support UML • UML tools can be expensive • The code generated by UML modeling tools was not production-ready • UML was too complex to learn and to use

6. Cloud Company • Leader in industrial weather monitoring systems (WMS) • Flagship product keeps track of temperature, humidity, barometric pressure, wind speed and direction • Real-time and historic • Customers: Aviation, maritime, agriculture, broadcast industry

7. Problem • Cloud is known for high reliable products that are somewhat expensive • Cut off customers that do not need the high end equipment • Competitor “Microburst” has announced a product line for the low end that can be upgraded in stages if needed • Product boasts it can be connected with high end equipment

8. Strategy • Microburst is not offering the product for at least six months • Cloud plans to work to build a low-end upgradable unit in the next six months to prevent Microburst from stealing the market

9. Dilemma • Requires significant engineering • Engineers will not commit to six month timeline • Believe it will be closer to 12 months • Cloud believes that twelve months will be too late

10. Plan • Cloud announced it’s new productand began taking orders • Nimbus LC 1.0 • Plan to ship in six months • Initially will repackage the old expensive high end system • Will loose money initially • Meanwhile engineers will develop the true low cost version and systems will be switched out during upgrade • Nimbus LC 2.0

11. Main System Requirements • New software has to be compatible with both the current hardware and new hardware • Processors will be different • New Hardware not even developed • Source code will need to be similar • Very quick timeline

12. User Requirements • This system shall provide automatic monitoring of various weather conditions. Specifically, it must measure: • Wind speed and direction • Temperature • Barometric pressure • Relative Humidity • Wind chill • Dew point temperature

13. User Requirements Cont. • 24-HourHistory – The user may direct the system to display the 24 hour history of any of the following measurements: • Temperature, Barometric Pressure, Relative Humidity • User Set Up - The system shall allow the station to be configured during installation. • Setting the current time, date, and time zone • Setting the units that will be displayed (English or metric)

14. Actors User. This actor views the real-time weather information that the station is measuring. It also interacts with the system to display the historical data associated with the individual sensors • Administrator. The role played by this actor is one of administering the system. This administration includes controlling the security aspects of the system, calibrating the individual sensors, setting the time/date, setting units of measure, and resetting the • station when required

15. Use Cases Use Case #1: Monitor Weather Data. The system will display the current temperature, barometric pressure, relative humidity, wind speed, wind direction, wind chill temperature, dew point, and barometric pressure trend. Monitor Weather Date • Use Case #2: View Temperature History. The system will display the history of the temperature readings. View Temp History • User Case #3: View Barometric Pressure History. The system will display the history of the barometric pressure readings. View Bar History

16. Initial Scheduler and Display Arch.

17. Initial Scheduler and Display Diagram

18. Observer UI Arch

19. UI Sequence Diagram

20. Barometric Pressure Observers Arch

21. Conclusion • The use of UML helped lay the foundation for the planning Phase • Communication was key to beginning to create the new tool • Several tools were used to understand the problem • Class Diagrams • Sequence Diagrams • Code

22. “A Fool With A Tool Is Still A Fool”

23. Refrences • Chen, Minder. The Methodology-Fit of UML: An Empirical Study of UML Adaptation • Cloud Case study ~ http://www.objectmentor.com/resources/articles/Walking_through_A_UML_Design.pdf • Jonkhart, Fred. IT architect at Fortis. Amsterdam, Netherlands • http://www.omg.org/gettingstarted/what_is_uml.htm • http://www.inconcept.com/JCM/April1998/halpin.html

24. Questions?