UML Basics - Requirement to Design

Visualization is the key to understand all sorts of problems.

A major purpose of modeling is to prepare generic descriptions that describe many specific particular items. This is often known as the type-instance dichotomy.

Unified Modeling Language  is comprised of two major components:

Notation (two major subdivisions)

Model Static elements of a design (E.g. classes, attributes, and relationships)

Model Dynamic elements of a design (E.g. objects, messages, and finite state machines).

Meta-model

Standard data representation is called the meta-model. 

Most of the modeling concepts in UML have dual character i.e. Modeled by two paired modeling elements, Generic descriptor & Individual items descriptor. Examples of such pairs in UML include: Class-Object, Association-Link, Parameter-Value, Operation-Call, and so on.

Notation Name

Notation  Description

Types

Association

Line drawn between the participating classes. Roles at the end of  association represents the multiplicity

Ability of an instance to send a message to another instance. Aggregation denotes whole/part relationships whereas associations do not.

UML relationships are presumed to be bidirectional unless the arrowhead is  present to restrict them.

Uni-Directional (Single side arrow)

Bi-Directional (No arrow /Double side arrow)

Show all arrows. The absence of an arrow indicates navigation is Bi-Directional.

Suppress all arrows. No inference can be drawn about navigation supported.

Qualifier box on an end of an association pinto a qualifier on the corresponding “association” role.  Each attribute entry string inside the qualifier box maps into an attribute of the qualifier. Multiplicity is not shown for links because they are instances.

Other association adornments (aggregation, composition, navigation) may be shown on the link roles.

Notation  Name

Notation  Description

Example

Aggregation (Has a )

The weak form of aggregation is denoted with an open diamond.

• Aggregate class (the class with the white diamond touching it) the “whole”,
• the other class in the relationship is “part” of that whole.

Window class contains many Shape instances. The role at the Shape end of the aggregation is marked with a “*” indicates that the Window contains many Shape instances. Notice also that the role name that Window knows its Shape instances by. i.e. it is the name of the instance variable within Window that holds all the Shapes.

Notation  Name

Notation  Description

Example

Composition (Has a)

Black diamond represents composition (Whole) and arrowhead represents  part. Part can’t exist independently. Has by-value relationship.

Exactly like Aggregation except that the lifetime of the 'part' is controlled by the 'whole'. This control may be direct or transitive. That is, the 'whole' may take direct responsibility for creating or destroying the 'part', or it may accept an already created part, and later pass it on to some other whole that assumes responsibility for it.

Composition  indicates that the lifetime of Point is dependent upon Circle

Notation  Name

Notation  Description

Dependency (‘using’ relationship)

Sometimes the relationship between a two classes is very weak. Instead of member variables they might be implemented as member function arguments. #include of C,C++ can be represented by dependency. Function of the Shape class takes an argument of type DrawingContext

trace – Trace:

A connection that represent the same concept  at different levels of meaning

refine – Refinement:    Mapping  (not necessarily complete) between two elements  with  description attached to the dependency in a note. Various kinds can be indicated by stereotyping.

uses – Usage:

A situation in which one element requires the presence of another element for its correct implementation or functioning. May be stereotyped further to indicate the exact nature of the dependency, such as calling an operation of another class, granting permission for access, instantiating an object of another class, etc.

bind – Binding:

A binding of template parameters to actual values to create a non parameterized element.

Notation  Name

Notation  Description

Example

Constraints ,Discrimination

Generalization and Specification (“is a” )

Inheritance is a line with a closed arrowhead pointing from the subclass (Specification) to the superclass (Generalization). Different classes share the same attributes and/or the same methods due to similarities. Instead of implementing these responsibilities twice, they are implemented once using Inheritance mechanism

When A inherits from B, we say A is the subclass of B and B is the superclass of A. “pure inheritance” means A inherits all the attributes and methods of B.

Person is root class and  abstract so objects can’t be created

 Members in the Person class are reused by Student and Professor.

Overlapping      : A descendent may be descended from more than one of the subclasses.

Disjoint   : A descendent may not be descended from more than one of the subclasses.

Complete: All subclasses have been specified (whether or not shown). No additional subclasses are expected.

incomplete:  Some subclasses have been specified but the list is known to be incomplete. There are additional subclasses that are not yet in the model. It is a statement about the model itself. Note that this is not the same as the

ellipsis, which states that additional subclasses exist in the model but are not shown on the current diagram.

 Notation  Name

Notation  Description

Example

Constraint

A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true (otherwise the system described by the model is invalid, with consequences that are outside the scope of UML).

Single graphical symbol : constraint string may be placed near the symbol, preferably near the name of the symbol

Two graphical symbols :  Dashed arrow from between two elements is labeled by the constraint string (in braces).

More graphical symbols : constraint string is placed in a note symbol and attached  to each of the symbols by a dashed line

Comment

A comment is a text string (including references to human-readable documents) attached directly to a model element

 Notation  Name

Notation  Description

Example

Stereotype

A stereotype is  a modeling time  new class of modeling element. It  represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent. Generally a stereotype represents a (self-referential) usage distinction.

A stereotyped element may have additional constraints on it from the base class. It is expected that code generators and other tools will treat stereotyped elements specially. When a stereotype is used above the name of a class it indicates that this class is a special kind of class that conforms to a rather rigid specification. Stereotypes represent one of the built-in extensibility mechanisms of UML.

Guillemet  (pronounced Gee-may)-  double angle-bracket    : <<>>

Interface

“Lollypop” notation can be used to represent an interface. Interface class representation can  be notified by GeeMay. Relationship can be represented in two ways.

A provided interface is shown as a "ball on a stick" attached to the edge of a classifier element. A required interface is shown as a "cup on a stick" attached to the edge of a classifier element.

Operation

Operation names typically begin with a lowercase letter.Operation names in plain face. An abstract operation may be shown in italics.

Visibility

+ public visibility

# protected visibility

- private visibility

~ Package Level visibility

Multiplicity

Absence of a multiplicity indicator an attribute holds exactly 1 value. Multiplicity may be indicated  by placing a multiplicity indicator in brackets after the attribute name   e.g :-  colors [3]: Color

points [2..*]: Point

name [0..1]: String

+size: Area = (100,100)

#visibility: Boolean = invisible

User Story

Use Case

Scenario

• Written from the context of the user as a simple statement about their feature need.
• Sets the stage by stating the need. User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized.
• User Story is the preface to the use case.
• The User Stories will then morph themselves into the business requirements and use cases.  Format  is "As a -role-, want -goal/desire- so that  - this the -benefit-"

• Highly structured and tells a story
• Coherent unit of functionality provided by a system or class.
• Simply a reason to use a system.
• Procedure by which an actor may use the system.
• Effective way to do knowledge transfer from the domain expert to the software developer

• Formal description of the flow of events that occur during the execution of a use case instance.
• It defines the specific sequence of events between the system and the external actors.