Professional Documents
Culture Documents
Object Oriented Software Engineering Manual PDF
Object Oriented Software Engineering Manual PDF
Branch: CE
OOSE
LIST OF EXPERIMENTS
Experiment
no:
Title
1 Study and Design of GUI for Login Using Java Applets
2 Study and Design of GUI for Calculator Using Java Applets
3 Study of Software Development Life Cycle Model
4 Study and Design of Use case Diagram.
5 Study and Design of Activity Diagram
6 Study and Design of Class Diagram
7 Study and Design Sequence Diagram
8 Study and Design Deployment & Component Diagram
9 OOSE Mini Project
Page 1
EXPERIMENT-1
Aim: Study and Design of GUI for Login Using Java Applets
Theory:
Object-oriented programming (OOP) is a programming paradigm that represents concepts as
"objects" that have data fields(attributes that describe the object) and associated procedures
known as methods. Objects, which are instances of classes, are used to interact with one another
to design applications and computer programs.
Features of OOP
OOP stands for Object Oriented Programming and the language that support this Object Oriented
programming features is called Object oriented Programming Language. An example of a
language that support this Object oriented features is C++.
Features of Object oriented Programming
The Objects Oriented programming language supports all the features of normal programming
languages. In addition it supports some important concepts and terminology which has made it
popular among programming methodology.
Inheritance
Polymorphism
Data Hiding
Encapsulation
Overloading
Reusability
Let us see a brief overview of these important features of Object Oriented programming
But before that it is important to know some new terminologies used in Object Oriented
programming namely
Department of Computer Engineering, SIES GST
Page 2
Objects
Classes
Objects:
In other words object is an instance of a class.
Classes:
These contain data and functions bundled together under a unit. In other words class is a
collection of similar objects. When we define a class it just creates template or Skelton. So no
memory is created when class is created. Memory is occupied only by object.
Example:
Class classname
{
Data
Functions
};
main ( )
{
classname objectname1,objectname2,..;
}
In other words classes acts as data types for objects.
Member functions:
The
functions
defined
inside
the
class
as
above
are
called
member
functions.
Page 3
public then it can be accessed anywhere outside the class. Object Oriented programming gives
importance to protecting data which in any system. This is done by declaring data as private and
making it accessible only to the class in which it is defined. This concept is called data hiding.
But one can keep member functions as public.
So above class structure becomes
Example:
Class classname
{
private:
datatype data;
public:
Member functions
};
main ( )
{
classname objectname1,objectname2,..;
}
Encapsulation:
The technical term for combining data and functions together as a bundle is encapsulation.
Inheritance:
Inheritance as the name suggests is the concept of inheriting or deriving properties of an exiting
class to get new class or classes. In other words we may have common features or characteristics
that may be needed by number of classes. So those features can be placed in a common tree class
called base class and the other classes which have these charaterisics can take the tree class and
define only the new things that they have on their own in their classes. These classes are called
derived class. The main advantage of using this concept of inheritance in Object oriented
programming is it helps in reducing the code size since the common characteristic is placed
Department of Computer Engineering, SIES GST
Page 4
separately called as base class and it is just referred in the derived class. This provide the users
the important usage of terminology called as reusability
Reusability:
This usage is achieved by the above explained terminology called as inheritance. Reusability is
nothing but re- usage of structure without changing the existing one but adding new features or
characteristics to it. It is very much needed for any programmers in different situations.
Reusability gives the following advantages to users
It helps in reducing the code size since classes can be just derived from existing one and one
need to add only the new features and it helps users to save their time.
For instance if there is a class defined to draw different graphical figures say there is a user who
want to draw graphical figure and also add the features of adding color to the graphical figure. In
this scenario instead of defining a class to draw a graphical figure and coloring it what the user
can do is make use of the existing class for drawing graphical figure by deriving the class and
add new feature to the derived class namely add the feature of adding colors to the graphical
figure.
Polymorphism and Overloading:
Poly refers many. So Polymorphism as the name suggests is a certain item appearing in different
forms or ways. That is making a function or operator to act in different forms depending on the
place they are present is called Polymorphism. Overloading is a kind of polymorphism. In other
words say for instance we know that +, - operate on integer data type and is used to perform
arithmetic additions and subtractions. But operator overloading is one in which we define new
operations to these operators and make them operate on different data types in other words
overloading the existing functionality with new one. This is a very important feature of object
oriented programming methodology which extended the handling of data type and operations.
Page 5
Conclusion:
Object-Oriented Programming has the following advantages over conventional approaches:
OOP provides a clear modular structure for programs which makes it good for defining
abstract data types where implementation details are hidden and the unit has a clearly
defined interface.
OOP makes it easy to maintain and modify existing code as new objects can be created
with small differences to existing ones.
OOP provides a good framework for code libraries where supplied software components
can be easily adapted and modified by the programmer. This is particularly useful for
developing graphical user interfaces.
Page 6
EXPERIMENT-3
Aim: Study of Software Development Life-Cycle Model
Theory: A Software Development Life Cycle Model is a set of activities together with an
ordering relationship between activities which if performed in a manner that satisfies the
ordering relationship that will produce desired product. Software Development Life Cycle Model
is an abstract representation of a development process.
In a software development effort the goal is to produce high quality software. The development
process is, therefore, the sequence of activities that will produce such software. A software
development life cycle model is broken down into distinct activities. A software development
life cycle model specifies how these activities are organized in the entire software development
effort.
Page 7
With the waterfall model, the activities performed in a software development project are
requirements analysis, project planning, system design, detailed design, coding and unit testing,
system integration and testing. Linear ordering of activities has some important consequences.
First, to clearly identify the end of a phase and beginning of the others. Some certification
mechanism has to be employed at the end of each phase. This is usually done by some
verification and validation. Validation means confirming the output of a phase is consistent with
its input (which is the output of the previous phase) and that the output of the phase is consistent
with overall requirements of the system.
The consequences of the need of certification are that each phase must have some defined output
that can be evaluated and certified. Therefore, when the activities of a phase are completed, there
should be an output product of that phase and the goal of a phase is to produce this product. The
outputs of the earlier phases are often called intermediate products or design document. For the
coding phase, the output is the code. From this point of view, the output of a software project is
to justify the final program along with the use of documentation with the requirements
document, design document, project plan, test plan and test results.
Another implication of the linear ordering of phases is that after each phase is completed and its
outputs are certified, these outputs become the inputs to the next phase and should not be
changed or modified. However, changing requirements cannot be avoided and must be faced.
Since changes performed in the output of one phase affect the later phases, that might have been
performed. These changes have to make in a controlled manner after evaluating the effect of
each change on the project. This brings us to the need for configuration control or configuration
management.
Page 8
The certified output of a phase that is released for the best phase is called baseline. The
configuration management ensures that any changes to a baseline are made after careful review,
keeping in mind the interests of all parties that are affected by it. There are two basic
assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall
model.
For a successful project resulting in a successful product, all phases listed in the waterfall model
must be performed anyway.
Any different ordering of the phases will result in a less successful software product.
Project Output in a Waterfall Model
As we have seen, the output of a project employing the waterfall model is not just the final
program along with documentation to use it. There are a number of intermediate outputs, which
must be produced in order to produce a successful product.
The set of documents that forms the minimum that should be produced in each project are:
Requirement document
Project plan
Final code
Review reports
Page 9
prototype obviously undergoes design, coding and testing. But each of these phases is not done
very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the
system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system.
Prototyping is an attractive idea for complicated and large systems for which there is no manual
process or existing system to help determining the requirements. In such situations letting the
client "plan" with the prototype provides invaluable and intangible inputs which helps in
determining the requirements for the system. It is also an effective method to demonstrate the
feasibility of a certain approach. This might be needed for novel systems where it is not clear that
constraints can be met or that algorithms can be developed to implement the requirements. The
process model of the prototyping approach is shown in the figure below.
The basic reason for little common use of prototyping is the cost involved in this built-it-twice
approach. However, some argue that prototyping need not be very costly and can actually reduce
the overall development cost. The prototype are usually not complete systems and many of the
details are not built in the prototype. The goal is to provide a system with overall functionality.
In addition, the cost of testing and writing detailed documents are reduced. These factors helps to
reduce the cost of developing the prototype. On the other hand, the experience of developing the
prototype will very useful for developers when developing the final system. This experience
helps to reduce the cost of development of the final system and results in a more reliable and
better designed system.
1. Advantages of Prototyping
2. Users are actively involved in the development
Department of Computer Engineering, SIES GST
Page 10
3. It provides a better system to users, as users have natural tendency to change their mind
in specifying requirements and this method of developing systems supports this user
tendency.
4. Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
5. Errors can be detected much earlier as the system is mode side by side.
6. Quicker user feedback is available leading to better solutions.
Disadvantages
1. Leads to implementing and then repairing way of building systems.
2. Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
Page 11
Each step consists of removing the next step from the list. Designing the implementation for the
selected task, coding and testing the implementation, and performing an analysis of the partial
system obtained after this step and updating the list as a result of the analysis. These three phases
are called the design phase, implementation phase and analysis phase. The process is iterated
until the project control list is empty, at the time the final implementation of the system will be
available. The process involved in iterative enhancement model is shown in the figure below.
The project control list guides the iteration steps and keeps track of all tasks that must be done.
The tasks in the list can be include redesign of defective components found during analysis. Each
entry in that list is a task that should be performed in one step of the iterative enhancement
process, and should be simple enough to be completely understood. Selecting tasks in this
manner will minimize the chances of errors and reduce the redesign work.
Page 12
The next step is determined by remaining risks. For example, its performance or user-interface
risks are considered more important than the program development risks. The next step may be
evolutionary development that involves developing a more detailed prototype for resolving the
risks. On the other hand, if the program development risks dominate and previous prototypes
have resolved all the user-interface and performance risks; the next step will follow the basic
waterfall approach.
The risk driven nature of the spiral model allows it to accommodate any mixture of specificationoriented, prototype-oriented, simulation-oriented or some other approach. An important feature
of the model is that each cycle of the spiral is completed by a review, which covers all the
products developed during that cycle, including plans for the next cycle. The spiral model works
for developed as well as enhancement projects.
Spiral Model Description
The development spiral consists of four quadrants as shown in the figure above
Department of Computer Engineering, SIES GST
Page 13
procure/ modify
3.
schedule, support, and risk. Once the system or products objectives, alternatives, and
constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks)
is performed.
Page 14
This may involve prototyping, simulation, benchmarking, reference checking, administering user
questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.
The outcome of the evaluation determines the next course of action. If critical operational and/or
technical issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal)
risks remain, more detailed prototyping may need to be added before progressing to the next
quadrant. Dr. Boehm notes that if the alternative chosen is operationally useful and robust
enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps
would be the evolving series of evolutionary prototypes going toward the right (hand side of the
graphic) . . . the option of writing specifications would be addressed but not exercised. This
brings us to Quadrant 3.
Page 15
EXPERIMENT-4
Aim: Study and Design of Use case Diagram.
Theory:
In software and systems engineering, a use case is a list of steps, typically defining interactions
between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a
human or an external system.
In systems engineering, use cases are used at a higher level than within software engineering,
often representing missions or stakeholder goals.
Use case diagrams depict:
Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
Actors. An actor is a person, organization, or external system that plays a role in one or
more interactions with your system. Actors are drawn as stick figures.
Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with an
interaction described by a use case. Associations are modeled as lines connecting use
cases and actors to one another, with an optional arrowhead on one end of the line. The
arrowhead is often used to indicating the direction of the initial invocation of the
relationship or to indicate the primary actor within the use case. The arrowheads are
typically confused with data flow and as a result I avoid their use.
System boundary boxes (optional). You can draw a rectangle around the use cases,
called the system boundary box, to indicate the scope of your system. Anything within
the box represents functionality that is in scope and anything outside the box is not.
System boundary boxes are rarely used, although on occasion I have used them to
identify which use cases will be delivered in each major release of a system.
Packages (optional). Packages are UML constructs that enable you to organize model
elements (such as use cases) into groups. Packages are depicted as file folders and can be
used on any of the UML diagrams, including both use case diagrams and class diagrams.
Page 16
I use packages only when my diagrams become unwieldy, which generally implies they
cannot be printed on a single page, to organize a large diagram into smaller ones.
Actor
You can picture an actor as a user of the IT system, for example Mr. Steel or Mrs. Smith from
check-in. Because individual persons are irrelevant for the model, they are abstracted. So the
actors are called check-in employee or passenger:
Actors represent roles that users take on when they use the IT system, e.g., the role of a check-in
employee. One person can act in more than one role toward the IT system. It is important for the
IT system in which role a person is acting. Therefore, it is necessary to log on to many IT
systems in a certain role, for instance, as a normal user or as an administrator. In each case
access to the appropriate functionalities (use cases) is granted.
Actors themselves are not part of the IT system. However, as employees they can be part of the
business system.
Use Case
Use cases describe the interactions that take place between actors and IT systems during the
execution of business processes:
A use case represents a part of the functionality of the IT system and enables the user (modeled
as an actor) to access this functionality.
Department of Computer Engineering, SIES GST
Page 17
Anything that users would like to do with the IT system has to be made available as a use case
(or part of a use case). Functionalities that exist in the IT system, but that are not accessed by
means of use cases, are not available to users.
Even though the idea behind use cases is to describe interactions, flows of batch processing,
which generally do not include interactions, can also be described as use cases. The actor of such
a batch use case is then the one who initiates batch processing. For instance, generating check-in
statistics would be a batch use case.
Association
An association is a connection between an actor and a use case. An association indicates that an
actor can carry out a use case. Several actors at one use case mean that each actor can carry out
the use case on his or her own and not that the actors carry out the use case together:
According to UML, association only means that an actor is involved in a use case. We use
associations in a restricted manner.
Include Relationships
An include relationship is a relationship between two use cases:
It indicates that the use case to which the arrow points is included in the use case on the other
side of the arrow. This makes it possible to reuse a use case in another use case. Figure 4.9 shows
an example of this relationship. In the flow of the use case, express check-in is a point at which
the use case generating boarding pass is included. This means that at this point the entire process
generating boarding pass is carried out. Include relationships can be viewed as a type of call to
a subprogram:
Department of Computer Engineering, SIES GST
Page 18
Page 19
cases check-in (2) and express check-in (3) are everything that a check-in employee can do with
the IT system.
The actor passenger (5) has an association to the use case express check-in (3), which means that
people who interact with the IT system as passengers can carry out the use case express checkin (3) directly with the IT system. The actor check-in employee (1) also has an association to the
use case express check-in (3), which means that both passengers and check-in employees can
carry out this use case. It does not mean that these two work together during express check-in.
Of course, during the use case check-in (2) too, a passenger checks himself or herself in and not
an employee, but actor of the IT system is always the one who directly interacts with the IT
system. For the use case express check-in (3) this can be either the passenger, who, with his or
her plane ticket, can obtain a boarding pass at a machine, or a check-in employee who can do this
in place of the passenger. However, for the business system the passenger is always the actor,
because he or she is located outside the business. The employee, on the other hand, is not an
actor from the perspective of the business system, because he or she works inside the
business system.
Page 20
EXPERIMENT-5
Aim: Study and Design of Activity Diagram
Theory:
Activity diagrams are typically used for business process modeling, for modeling the logic
captured by a single case or usage scenario, or for modeling the detailed logic of a business rule.
Although UML activity diagrams could potentially model the internal logic of a complex
operation it would be far better to simply rewrite the operation so that it is simple enough that
you dont require an activity diagram. In many ways UML activity diagrams are the objectoriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.
Notations:
Initial node. The filled in circle is the starting point of the diagram. An initial node isnt
required although it does make it significantly easier to read the diagram.
Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
Activity. The rounded rectangles represent activities that occur. An activity may be
physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.
Flow/edge. The arrows on the diagram. Although there is a subtle difference between
flows and edges I have never seen a practical purpose for the difference although I have
no doubt one exists. Ill use the term flow.
Page 21
Fork. A black bar with one flow going into it and several leaving it. This denotes the
beginning of parallel activity.
Join. A black bar with several flows entering it and one leaving it. All flows going into
the join must reach it before processing may continue. This denotes the end of parallel
processing.
Condition. Text such as [Incorrect Form] on a flow, defining a guard which must
evaluate to true in order to traverse the node.
Decision. A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is
obvious.
Merge. A diamond with several flows entering and one leaving. The implication is that
one or more incoming flows must reach this point until processing continues, based on
any guards on the outgoing flow.
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behavior of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes can be described as:
Page 22
Activities
Association
Conditions
Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:
Confirm order
Page 23
Dispatch order
After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.
Page 24
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:
Conclusion:
Page 25
EXPERIMENT-6
Aim: Study and Design of Class Diagram
Theory:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the system's classes,
their attributes, operations (or methods), and the relationships among the classes.
Class Diagram Symbols and Notations:
Classes represent an abstraction of entities with common characteristics. Associations represent
the relationships between classes.
Illustrate classes with rectangles divided into compartments. Place the name of the class in the
first partition (centered, bolded, and capitalized), list the attributes in the second partition, and
write operations into the third.
Active Class
Active classes initiate and control the flow of activity, while passive classes store data and serve
other classes. Illustrate active classes with a thicker border.
Visibility
Use visibility markers to signify who can access the information contained within a class. Private
visibility hides information from anything outside the class partition. Public visibility allows all
Page 26
other classes to view the marked information. Protected visibility allows child classes to access
information they inherited from a parent class.
Associations
Associations represent static relationships between classes. Place association names above, on, or
below the association line. Use a filled arrow to indicate the direction of the relationship. Place
roles near the end of an association. Roles represent the way the two classes see each other.
Note: It's
uncommon
to
name
both
the
association
and
the
class
roles.
Multiplicity (Cardinality)
Place multiplicity notations near the ends of an association. These symbols indicate the number
of instances of one class linked to one instance of the other class. For example, one company will
have one or more employees, but each employee works for one company only.
Page 27
Constraint
Place constraints inside curly braces {}.
Simple Constraint
Page 28
Generalization
Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship
between two classes where one class is a specialized version of another. For example, Honda is a
type of car. So the class Honda would have a generalization relationship with the class car.
In real life coding examples, the difference between inheritance and aggregation can be
confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the
PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to
access both the PUBLIC and PROTECTED functions of the super class.
Conclusion:
Page 29
EXPERIMENT-7
Aim: Study and Design of Sequence Diagram
Theory:
UML sequence diagrams are used to show how objects interact in a given situation. An
important characteristic of a sequence diagram is that time passes from top to bottom: the
interaction starts near the top of the diagram and ends at the bottom (i.e. Lower equals Later).
A popular use for them is to document the dynamics in an object-oriented system.
For each key collaboration, diagrams are created that show how objects interact in various
representative scenarios for that collaboration.
Sequence diagrams are typically used to model:
1. Usage scenarios. A usage scenario is a description of a potential way your system is used.
The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may
also be one entire pass through a use case, such as the logic described by the basic course
of action or a portion of the basic course of action, plus one or more alternate scenarios.
The logic of a usage scenario may also be a pass through the logic contained in several use
cases. For example, a student enrolls in the university, and then immediately enrolls in
three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a complex
operation, function, or procedure. One way to think of sequence diagrams, particularly
highly detailed diagrams, is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that can be
invoked by a wide variety of clients. This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or CORBAcompliant object request brokers (ORBs).
Page 30
Object
Unit
Separator
Represents
an
interface
or
boundary
between
Asynchronous
An
asynchronous
message
between
header
Message
elements
Block
Call Message
Page 31
Create Message
Else Block
Flow Note
Documentation
note
that
is
automatically
Message
Page Break
Scenario Case
Scenario End
End of a scenario
Page 32
State
Steady State
Timer Start
Timer Stop
Timer
Expiration
element
An example of high level sequence diagram for Online Bookshop. Online customer can search
book catalog, view description of a selected book, add book to shopping cart, do checkout.
Page 33
Page 34
EXPERIMENT-8
Aim: Study and Design of Deployment and Component Diagram
Theory:
Deployment diagrams
Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed.
So deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.
Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how
they are deployed in hardware.
UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
special diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on hardware topology of a system. Deployment diagrams are used by the
system engineers.
The purpose of deployment diagrams can be described as:
Page 35
Performance
Scalability
Maintainability
Portability
Nodes
The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here we have shown nodes as:
Monitor
Modem
Caching server
Server
Page 36
Page 37
Now a day's software applications are very complex in nature. Software applications can be
stand alone, web based, distributed, mainframe based and many more. So it is very important to
design the hardware components efficiently.
So the usage of deployment diagrams can be described as follows:
Component Diagram
Component diagrams are different in terms of nature and behavior. Component diagrams are
used to model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the elements like
executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.
Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from all
other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities.
So from that point component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files etc.
Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.
Department of Computer Engineering, SIES GST
Page 38
A single component diagram cannot represent the entire system but a collection of diagrams are
used to represent the whole.
So the purpose of the component diagram can be summarized as:
Now after identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Page 39
The following is a component diagram for order management system. Here the artifacts are files.
So the diagram shows the files in the application and their relationships. In actual the component
diagram also contains dlls, libraries, folders etc.
In the following diagram four files are identified and their relationships are produced.
Component diagram cannot be matched directly with other UML diagrams discussed so far.
Because it is drawn for completely different purpose.
So the following component diagram has been drawn considering all the points mentioned
above:
Page 40
These diagrams show the physical components of a system. To clarify it, we can say that
component diagrams describe the organization of the components in a system.
Organization can be further described as the location of the components in a system. These
components are organized in a special way to meet the system requirements.
As we have already discussed those components are libraries, files, executables etc. Now before
implementing the application these components are to be organized. This component
organization is also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. So the
implementation team of an application should have a proper knowledge of the component
details.
Now the usage of component diagrams can be described as:
Conclusion:
Page 41