NaviGap UML diagrams

In this part, we will talk about our development model views described in Unified Modelling Language. UML is a language which we will apply to describe use cases meaning the interactions of an actor (user) and a system to achieve certain goals. This is an in-between process: after we gathered all requirements and shaped our agenda and before we actually started coding.

Our app users

In previous posts, we identified our user personas. Now we can proceed and implement those personas into our interaction use cases. It helps us to identify the functionalities we want to offer to them. We don’t have to cover now the scenario of a registered or authenticated user, but we will treat as a seperate diagram.

Our app functionalities

Now we identify general functional blocks we offer for the actors (personas) aligned with activities they perform.

The First Persona is identified as a novice who comes for social value and expert advice. is clearly interested in

The Second Persona is an expert who was a novice at the beginning, but after a certain amount of contribution (posts, advice, photos etc.) became an expert (high degree of centrality) and can provide help/advice/guidance to novices.

Finally, the Third Persona is a commercial partner type of user who is interested in business add-on value.

Three iterations are needed to reach the outlined use case scope.

Figure 1. Use Case Diagram: NaviGap interaction

At this point, we can augment the Persona 1 case by expanding each functionality. For example, ‘Seek travel inspiration’ functionality:

Figure 2. Use Case Diagram: Augmented functionality

Through each augmentation iteration, we ask ourselves: is it enough? have we listed all possible functionalities that we can release? Step by step we will augment our UML layout and add blocks to each functionality. After each functionality has a detailed list of sub-functionalities we can look at it critically and think of additional features that will give us a competitive edge.

Our app communication diagram

As an example of UML communication diagram, we show the scenario when a user wants to login into their account. That provides a model-view-controller perspective of interaction.

 

Figure 3. Communication Diagram: Login

Our app state diagram

State diagrams can be seen as the essence of object-oriented programming (OOP). Those diagrams are good when we want to describe the behavior of a single object. In general, those diagrams define various states of an object during its life cycle.

A state diagram represents the actual changes in state, not the particular processes/commands creating those changes.

Figure 4. State Diagram: Novice User object

 

Why we need all those diagrams?

We assume that our team should have a clear understanding how the users interact with the App, what functionalities we are planning to offer to them and in what way they can access them. Overall, each diagram builds up a clear understanding of what is expected from the app, what role the users and other actors play in it, and helps to shape the outline of the UI design.

 

Leave a Reply

Your email address will not be published. Required fields are marked *