Lab
Lab
Aim:
To study about the object-oriented concepts.
Description:
Basic OO Concepts
Introduction:
Definitions
Client Code - the code that uses the classes under discussion.
Client should be able to use just the public interface, and not care about
the implementation.
Do the class design work at the level of the public interfaces, not the private
implementations.
I. Don’t get bogged down in implementation details like “I can do with this with
a map container and a deque!”
II. Think only about what the class responsibilities are and what they do in their
public interfaces:
III. Try writing pseudo code just for the interactions between class objects through
their public interfaces.
IV. Keep this up until you can’t stand it any more, then make implementation
choices and write the code.
Continue design thinking until you have thought of at least two reasonable ways to
solve each design problem.
III. All designs are imperfect - they all involve trade-offs. They are good in some
ways, bad in others.
IV. A good design is good in the most important ways, and bad in the less
important ways.
V. But there might be more than one good design - just different in the specific
tradeoffs.
VI. You can’t make an intelligent choice if you have only thought of one design -
there could be another, better, simpler one.
Study of UML Diagrams – Aim and Scope of Diagrams
AIM:
General study of UML
DESCRIPTION:
Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects
design buildings. Builders use the designs to create buildings. The more complicated the
building, the more critical the communication between architect and builder. Blueprints are
the standard graphical language that both architects and builders must learn as part of their
trade.
Writing software is not unlike constructing a building. The more complicated the
underlying system, the more critical the communication among everyone involved in creating
and deploying the software. In the past decade, the UML has emerged as the software
blueprint language for analysts, designers, and programmers alike. It is now part of the
software trade. The UML gives everyone from business analyst to designer to programmer a
common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in
learning UML must be familiar with the underlying tenet of object-oriented problem solving
-- it all begins with the construction of a model. A model is an abstraction of the underlying
problem. The domain is the actual world from which the problem comes. Models consist of
objects that interact by sending each other messages. Think of an object as "alive." Objects
have things they know (attributes) and things they can do (behaviors or operations). The
values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of classes.
UML NOTATION
Unified Modeling Language.
Set of notations and conventions used to describe and model an application.
Universal language for modeling systems.
Standard notation for OO modeling systems.
Does not specify methodology to develop an application.
UML DIAGRAMS
CLASS DIAGRAM
Shows the static structure of the model.
Collection of static modeling elements such as classes and their
relationships connected as a graph.
Provides visual representation of objects, relationships and their structures.
Class:-
A class is a set of objects that share a common structure and common behavior.
<Class Name>
<Attributes>
<Operations>
Interface:-
Specifies the externally-visible operations of a class and/or component.
Association:-
Model properties of associations.
The properties are stored in a class and linked to the association relationship.
Example,
Generalization:-
A generalize relationship is a relationship between a more general class or use case
and a more specific class or use case.
Example,
Vehicle
Relationship:-
Communication – communications with the use case normally.
Uses – Shown by generalization arrow from the use cases.
Extends – Used when one case does more than another that is similar to it.
SEQUENCE DIAGRAM:
Describes the behavior of the system through interaction between the system and the
environment in time sequence.
Two dimensions:
Vertical dimension – represents time.
Horizontal dimension – represents objects.
Life line – Object's existence during the interaction.
Object 1 Object 2
<Event>
COLLABORATION DIAGRAM:
An interaction diagram that shows the order of messages that implement an operation
or a transaction.
Collaboration diagrams show objects, their links, and their messages.
Object 1 Object 2
1. <Event>
Object:-
An object has state, behavior, and identity.
Objects interact through their links to other objects.
Link:-
A link is an instance of an association, analogous to an object.
Message:-
A message is the communication carried between two objects that trigger an event.
STATECHART DIAGRAM
Models the dynamic behavior of individual classes or any other kind of object.
Shows the sequences of states, events, and actions.
State:-
Represents a condition or situation during the life of an object during which it satisfies
some condition or waits for some event.
<State>
Start State:-
Shows the beginning of workflow.
End state::-
Represents the final or terminal state.
ACTIVITY DIAGRAM
Used for modeling the sequence of activities in a process
Special case of a state machine in which most of the states are activities and most of
the transitions are implicitly triggered by completion of the actions in the source
activities.
Activity:-
Represents the performance of task or duty in a workflow.
<Activity>
Swim lanes:-
Represents organizational units or roles within a business model.
IMPLEMENTATION DIAGRAM
Shows the implementation phase of system development.
Two types of implementation diagrams:
Component diagram
Deployment diagram
COMPONENT DIAGRAM
Models the physical components in the design.
A graph of the design’s components connected by dependency relationships.
Includes concept of packages.
Package is used to show how classes are grouped together.
DEPLOYMENT DIAGRAM
Shows the configuration of runtime processing elements and software components.
It is a graph of nodes connected by communication association.
Nodes are the components that are connected to other components through
dependencies.
Used in conjunction with component diagrams to show the distribution of physical
modules.