Project Three: Model a Phone Parser Code Library
In Project Three we're going to make a little bit of a change, and design something low-level. Instead of designing high-level user interactions, we're going to design a code library by reverse engineering a Ruby gem that I've built.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

This will give you a blueprint of how to design your own gems and code libraries in the future.

The first type of diagram we're going to implement is a structural diagram: a package diagram, specifically.

Package Diagram Requirements

  • Phone parser
  • Country codes

These are going to list out some of the different getters, setters, and methods that are needed in order to allow these to work properly.

A package diagram is very different than a class diagram. It's even more abstract and high-level. It gives more of a sense of how the code is organized and less on how to build it. It's great for when you're planning a system out, building documentation, or showing how your system operates at a very abstract level.

The second type of diagram will be a behavioral diagram. For that, we're going to build a sequence diagram, which focuses on the messages that are sent between systems, or sent internally. This one is a small code library so it's going to focus on the messages sent inside of the code library itself.

Sequence Diagram Requirements

  • Participants: Parser, Digit length validator, and Country code validator
  • Start point: receives data
  • Endpoint: returns parsed phone number
  • Key messages: Parsing and Validations

This entire code library is focused on validating these phone numbers, parsing them, and then returning cleaned up versions. In the notes for this guide, there is a link to the Ruby gem itself. It comes with examples of how you can run it so that you can test it out and look through it to see all of the other examples and the different features that it contains.

Resources