Communicating design ideas in Software development

It is all about making the other person understand what I think

Defining a Use case

A use case, then, is a set of scenarios tied together by a common user goal.

A scenario is a sequence of steps describing an interaction between a user and a system.

A simple format for capturing a use case involves describing its primary scenario as a sequence of numbered steps and the alternatives as variations on that sequence

Actor

An actor is a role that a user plays with respect to the system. Actors carry out use cases. A single actor may perform many use cases; conversely, a use case may have several actors performing it. Actors don’t need to be human, even though actors are represented as stick figures within a use case diagram.

Class Diagram

A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them.
There are two principal kinds of static relationships:
● associations
● subtypes
Class diagrams also show the attributes and operations of a class and the constraints that apply to the way objects are connected.

Perspectives in Class Diagram

Conceptual
If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study.

Specification
Now we are looking at software, but we are looking at the interfaces of the software, not the implementation.

Implementation
In this view, we really do have classes and we are laying the implementation bare.

Associations among classes

Associations represent relationships between instances of classes

From the conceptual perspective, associations represent conceptual relationships between classes. The diagram indicates that an Order has to come from a single Customer and that a Customer may make several Orders over time. Association ends are often called roles.

Within the specification perspective, associations represent responsibilities. The figure implies that there are one or more methods associated with Customer that will tell me what orders a given Customer has made.

If this were an implementation model, we would now imply that there are pointers in both directions between the related classes.

Associations with Navigability

In a specification model, this would indicate that an Order has a responsibility to tell you which Customer it is for, but a Customer has no corresponding ability to tell you which Orders it has.

In an implementation diagram, this would indicate that Order contains a pointer to Customer, but Customer would not have a pointer to Order.