Madhu Kumar: 2013

Wednesday, 13 November 2013

Friday, 8 November 2013

Interaction Diagrams

Interaction Diagrams:

Terms and Concepts:

An interaction is a behavior that comprises a set of messages exchanged among a set of Objects within a context to accomplish a purpose.

A message is a specification of a communication between objects that conveys information with the expectation that activity will ensue.

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.

A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

Interaction diagrams commonly contain

· Objects

· Links

· Messages

Interaction diagrams are used in two ways:

· Modeling a Flow of Control

· Modeling Flows of Control by Time Ordering

To model a flow of control,

· Set the context for the interaction, whether it is the system as a whole, a class, or an individual operation.

· Set the stage for the interaction by identifying which objects play a role; set their initial properties, including their attribute values, state, and role.

· If your model emphasizes the structural organization of these objects, identify the links that connect them, relevant to the paths of communication that take place in this interaction. Specify the nature of the links using the UML's standard stereotypes and constraints, as necessary.

· In time order, specify the messages that pass from object to object. As necessary, distinguish the different kinds of messages; include parameters and return values to convey the necessary detail of this interaction.

Also to convey the necessary detail of this interaction, adorn each object at every moment in time with its state and role.

Class Diagrams

Class Diagrams:

Terms and Concepts:

A class is a description of a set of objects that share the same attributes, operations, relationships and semantics. Graphically, a class is rendered as a rectangle.

Class diagram commonly contains the following things.

· Classes,

· Interfaces,

· Collaboration,

· Dependency, Generalization and Association, Relationships.

Class diagrams may also contain packages or subsystems both of which are used to group elements of your model into layer chunks.

Class diagrams are used in one of 3 ways.

· Modeling the Vocabulary of a System.

· Modeling the Distribution of Responsibilities in a System.

· Modeling Non-software Things.

Common Modeling Techniques

You'll use classes most commonly to model abstractions that are drawn from the problem, you are trying to solve or from the technology you are using to implement a solution to that problem. Each of these abstractions is a part of the vocabulary of your system, meaning that, together, they represent the things that are important to users and to implementers.

Modeling Non-software Things

To model the vocabulary of a system,

· Identify those things that users or implementers use to describe the problem or solution.

· Use CRC cards and use case-based analysis to help find these abstractions.

· For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes.

· Provide the attributes and operations that are needed to carry out these responsibilities for each class.

Modeling the Distribution of Responsibilities in a System

To model the distribution of responsibilities in a system,

· Identify a set of classes that work together closely to carry out some behavior.

· Identify a set of responsibilities for each of these classes.Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.

· Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little.

Modeling Non-software Things

To model non-software things,

· Model the thing you are abstracting as a class.

· If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue.

· If the thing you are modeling is some kind of hardware that itself contains

software, consider modeling it as a kind of node, as well, so that you can further expand on its structure.

Introduction to UML

Introduction to UML:

“UML (Unified Modeling Language) is a language used for visualizing, specifying, constructing and documenting the artifacts of a software intensive system.”

Building Blocks of UML:

v Things

v Relationships

v Diagrams

Things in UML:

Ø Structural things

· Classes

· Interfaces

· Collaborations

· Use Cases

· Active Classes

· Components

· Node

Ø Behavioral things

· Interactions

· State machines

Ø Grouping things

· Packages

Ø Annotational things

· Notes

Relationships in UML:

ü Dependency

ü Association

ü Generalization

ü Realization

Diagrams in UML :

ü Class Diagram

ü Object Diagram

ü Use case Diagram

ü Sequence Diagram

ü Collaboration Diagram

ü State chart Diagram

ü Activity Diagram

ü Component Diagram

ü Deployment Diagram

Use Case Diagrams:

A use case diagram is a diagram that shows a set of use cases and actors and their relationships.

A use case diagram commonly contain

· Use cases

· Actors

· Dependency

· Generalization and Association Relationships.

Use case diagrams may also contain packages, which are used to group elements of your model into larger chants.

Use case diagram is used in one of two ways

1) To model the context of a system.

2) To model the requirements of a system.

Modeling Techniques:

1. Identity the actors that surround the system by considering which groups require help from the system to perform their tasks, which groups are needed to execute the systems functions; which groups interact with external hardware or other software systems; and which groups perform secondary functions for administration & maintenance.

2.Organize actors that are similar to one another in a generalization/specification hierarchy.

3. Where it aids understandability, provide a stereotype for each such actor.

4. Populate a use case diagram with these actors and specify the paths of communications from each actor to the system’s use cases.