Computer Science & Engineering Department

B.Tech 3rd Year (6th Semester)

Software Engineering Lab (KCS-651)

S.No List of the Practicals

Prepare a SRS document in line with the IEEE

1
recommended standards.
2 Draw the Entity relationship diagram of a project.
3 Draw the data flow diagrams at level 0 and level 1.
4 Draw use case diagram in argo UML.
5 Draw activity diagram in argo UML.
6 Draw class diagram in argo UML.
 Software Engineering LAB (KCS-651)

PO1: An ability to use the methodology and modern engineering tools necessary for
engineering practice.

PO2: ability to elicit, analyze and specify software requirements.

PO3: Analyze and translate specifications into a design.

 Experiment Number: 1

Experiment Name: Software Requirement Specification.

Outcome: Can produce the requirements in a SRS document.

Objective: Prepare a SRS document in line with the IEEE recommended standards.

Description:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or
development work. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software
system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any
required constraints by which the system must abide. The SRS also functions as a blueprint for completing a
project with as little cost growth as possible. The SRS is often referred to as the "parent" document because
all subsequent project management documents, such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer
design suggestions, possible solutions to technology or business issues, or any other information other than
what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to
address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.
 It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and statement
of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so
that a design solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial
product development phase in which information is gathered about what requirements are needed--and not.
This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after the requirements have been gathered and
analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

● Functionality. What is the software supposed to do?

●
● External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?
●
● Performance. What is the speed, availability, response time, recovery time of various software
functions, etc.?
●
● Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
●
● Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating
environment(s) etc.
Characterstics of good SRS
An SRS should be

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
● Correct - This is like motherhood and apple pie. Of course you want the specification to be correct.
No one writes a specification that they know is incorrect. We like to say - "Correct and Ever
Correcting." The discipline is keeping the specification up to date when you find things that are not
correct.
● Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only
one interpretation. Again, easier said than done. Spending time on this area prior to releasing the
SRS can be a waste of time. But as you find ambiguities - fix them.
● Complete - A simple judge of this is that is should be all that is needed by the software designers to
create the software.
● Consistent - The SRS should be consistent within itself and consistent to its reference documents. If
you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
● Ranked for Importance - Very often a new system has requirements that are really marketing wish
lists. Some may not be achievable. It is useful provide this information in the SRS.
● Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of
my favorites is - "The system should never crash." Instead, provide a quantitative requirement like:
"Every key stroke should provide a user response within 100 milliseconds."
● Modifiable - Having the same requirement in more than one place may not be wrong - but tends to
make the document not maintainable.
● Traceable - Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher level
document. Why do we need this requirement?
 Experiment Number: 2

Experiment Name: Entity Relationship Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.
Software Requirements: SmartDraw, MS Word.

Outcome: Can produce the requirements in Entity Relationship diagram.

Objective: Prepare a Requirement document in by using Entity Relationship

Diagram.

Description: An Entity Relationship (ER) Diagram is a type of flowchart that

illustrates how “entities” such as people, objects or concepts relate to each other
within a system. ER Diagrams are most often used to design or debug relational
databases in the fields of software engineering, business information systems,
education and research.

Components: An ER diagram is a means of visualizing how the information a system

produces is related. There are five main components of an ERD:

Entities, which are represented by rectangles. An entity is an object or concept

about which you want to store information. A weak entity is an entity that must
defined by a foreign key relationship with another entity as it cannot be
uniquely identified by its own attributes alone.

Actions, which are represented by diamond shapes, show how two entities
share information in the database. In some cases, entities can be self-linked.
For example, employees can supervise other employees.
Attributes, which are represented by ovals. A key attribute is the unique,
distinguishing characteristic of the entity. For example, an employee's social
security number might be the employee's key attribute.

A multivalued attribute can have more than one value. For example, an
employee entity can have multiple skill values.

A derived attribute is based on another attribute. For example, an employee's

monthly salary is based on the employee's annual salary.

Connecting lines, solid lines that connect attributes to show the relationships of
entities in the diagram.
Cardinality specifies how many instances of an entity relate to one instance of
another entity. Ordinality is also closely linked to cardinality. While cardinality
specifies the occurrences of a relationship, ordinality describes the relationship
as either mandatory or optional. In other words, cardinality specifies the
maximum number of relationships and ordinality specifies the absolute
minimum number of relationships.

There are many notation styles that express cardinality.

Tips for Effective ER Diagrams
1. Make sure that each entity only appears once per diagram.
2. Name every entity, relationship, and attribute on your diagram.

3. Examine relationships between entities closely. Are they necessary? Are

there any relationships missing? Eliminate any redundant relationships. Don't
connect relationships to each other.

4. Use colors to highlight important portions of your diagram.

Entity Relationship Diagram Example
 Experiment Number: 3

Experiment Name: Data Flow Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.

Software Requirements: SmartDraw/MS Word, Windows XP.

Outcome: Can produce the requirements in Data Flow diagram.

Objective: Prepare a Requirement document in by using Data Flow Diagram.

Description: Data flow diagram is graphical representation of flow of data in an

information system. It is capable of depicting incoming data flow, outgoing data flow
and stored data. The DFD does not mention anything about how data flows through
the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts
flow of control in program modules. DFDs depict flow of data in the system at
various levels. DFD does not contain any control or branch elements.

Components:

External Entity an outside system that sends or receives data, communicating with
the system being diagrammed. They are the sources and destinations of information
entering or leaving the system. They might be an outside organization or person, a
computer system or a business system. They are also known as terminators, sources
and sinks or actors. They are typically drawn on the edges of the diagram.
Process any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business
rules. A short label is used to describe the process, such as “Submit payment.”
Data store files or repositories that hold information for later use, such as a database
table or a membership form. Each data store receives a simple label, such as “Orders.”
Data flow the route that data takes between the external entities, processes and data
stores. It portrays the interface between the other components and is shown with
arrows, typically labeled with a short data name, like “Billing details.”

DFD rules

● Each process should have at least one input and an output.

● Each data store should have at least one data flow in and one data flow out.
● Data stored in a system must go through a process.
● All processes in a DFD go to another process or a data store.
DFD Levels:
A data flow diagram can dive into progressively more detail by using levels and
layers, zeroing in on a particular piece. DFD levels are numbered 0, 1 or 2, and
occasionally go to even Level 3 or beyond.
1. DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole
system or process being analyzed or modeled. It’s designed to be an at-a-glance view,
showing the system as a single high-level process, with its relationship to external
entities. It should be easily understood by a wide audience, including stakeholders,
business analysts, data analysts and developers.

2. DFD Level 1 provides a more detailed breakout of pieces of the Context Level
Diagram. You will highlight the main functions carried out by the system, as you
break down the high-level process of the Context Diagram into its subprocesses.

Finance
VerifiCation

Customer Data Stares

Verify Issue
Item
Profess Order
 Experiment Number: 4

Practical Name: Use Case Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.

Software Requirements: Argo UML, Windows XP.

Outcome: Can produce the requirements in Use Case diagram.

Objective: Prepare a Requirement doccument in by using Use Case Diagram.

Description: According to the UML specification a use case diagram is “a diagram

that shows the relationships among actors and use cases within a system.” Use case
diagrams are often used to:

Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model

Communicate the scope of a development project

Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project
stakeholders and not from the (often technical) point of view of developers. There are
guidelines for:

Use Cases

Actors

Relationships

System Boundary Boxes

1. Use Cases
A use case describes a sequence of actions that provide a measurable value to an
actor. A use case is drawn as a horizontal ellipse on a UML use case diagram.
1. Use Case Names Begin With a Strong Verb
2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use
Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

An association between an actor and a use case

An association between two use cases
A generalization between two actors
A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an

optional open-headed arrowhead on one end of the line indicating the direction of the
initial invocation of the relationship. Generalizations are depicted as a close-headed
arrow with the arrow pointing towards the more general modeling element.

1. Indicate An Association Between An Actor And A Use Case If The Actor

Appears Within The Use Case Logic

2. Avoid Arrowheads On Actor-Use Case Relationships

3. Apply <<include>> When You Know Exactly When To Invoke The Use Case

4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use
Case Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the
name suggests it indicates the scope of your system – the use cases inside the
rectangle represent the functionality that you intend to implement.
1. Indicate Release Scope with a System Boundary Box.
2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

we start by identifying as many actors as possible. You should ask how the actors
interact with the system to identify an initial set of use cases. Then, on the diagram,
you connect the actors with the use cases with which they are involved. If actor
supplies information, initiates the use case, or receives any information as a result of
the use case, then there should be an association between them.

Conclusion: The Use case diagram was made successfully by following the steps
described above.
 Experiment Number: 5

Practical Name: Activity Diagram

Experiment Name: Activity Diagram.

Outcome: Can produce the activity diagram for requirements modeling.

Objective: To Draw a sample activity diagram for real project or system.

Description:

Hardware Requirements:

Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored
monitor.
Software Requirements:

Argo UML, Windows XP,

Theory:

Activity diagrams are typically used for business process modeling, for modeling the
logic captured by a single usecase 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 don’t require an activity diagram. In
many ways UML activity diagrams are the object-oriented equivalent of flow charts
and data flow diagrams (DFDs) from structured development.

Let’s start by describing the basic notation :

● Initial node. The filled in circle is the starting point of the diagram. An initial
node isn’t 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,never a practical purpose for the difference
although.
 ● 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.

● Partition. If figure is organized into three partitions, it is also called

swimlanes, indicating who/what is performing the activities (either the
Applicant, Registrar, or System).

● Sub-activity indicator. The rake in the bottom corner of an activity, such as

in the Apply to University activity, indicates that the activity is described by a
more finely detailed activity diagram.

● Flow final. The circle with the X through it. This indicates that the process
stops at this point.

GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM

General Guidelines
Decision Points
Decision Points
Guards
Parallel Activities
Swimlane Guidelines
.Action-Object Guidelines
General Guidelines

figure1. Modeling a business process with a UML Activity Diagram.

 ● Place The Start Point In The Top-Left Corner. A start point is modeled with a
filled in circle, using the same notation that UML State Chart diagrams use.
Every UML Activity Diagram should have a starting point, and placing it in the
top-left corner reflects the way that people in Western cultures begin reading.
Figure1, which models the business process of enrolling in a university, takes
this approach.

● Always Include an Ending Point. An ending point is modeled with a filled in

circle with a border around it, using the same notation that UML State Chart
diagrams use. Figure1 is interesting because it does not include an end point
because it describes a continuous process – sometimes the guidelines don’t
apply.

● Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is

that if an operation is so complex you need to develop a UML Activity diagram
to understand it that you should consider refactoring it.

● Activities

An activity, also known as an activity state, on a UML Activity diagram typically

represents the invocation of an operation, a step in a business process, or an entire
business process.

● Question “Black Hole” Activities. A black hole activity is one that has
transitions into it but none out, typically indicating that you have either missed
one or more transitions.

● Question “Miracle” Activities. A miracle activity is one that has transitions out
of it but none into it, something that should be true only of start points.

● Decision Points
A decision point is modeled as a diamond on a UML Activity diagram.
 ● Decision Points Should Reflect the Previous Activity. In figure1 we see that
there is no label on the decision point, unlike traditional flowcharts which
would include text describing the actual decision being made, we need to
imply that the decision concerns whether the person was enrolled in the
university based on the activity that the decision point follows. The guards,
depicted using the format [description], on the transitions leaving the decision
point also help to describe the decision point.

● Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in
FIGURE1 includes an implied decision point, a check to see that the forms
are filled out properly, which simplified the diagram by avoiding an additional
diamond.

● Guards

A guard is a condition that must be true in order to traverse a transition.

● Each Transition Leaving a Decision Point Must Have a Guard

● Guards Should Not Overlap. For example guards such as x <0, x = 0, and x >
0 are consistent whereas guard such as x <= 0 and x >= 0 are not consistent
because they overlap – it isn’t clear what should happen when x is 0.

● Guards on Decision Points Must Form a Complete Set. For example, guards
such as x < 0 and x >0 are not complete because it isn’t clear what happens
when x is

● Exit Transition Guards and Activity Invariants Must Form a Complete Set. An
activity invariant is a condition that is always true when your system is
processing an activity.

● Apply a [Otherwise] Guard for “Fall Through” Logic.

● Guards Are Optional. It is very common for a transition to not include a guard,
even when an activity includes several exit transitions.

5. Parallel Activities

It is possible to show that activities can occur in parallel, as you see in FIGURE 1
depicted using two parallel bars. The first bar is called a fork, it has one transition
entering it and two or more transitions leaving it. The second bar is a join, with two or
more transitions entering it and only one leaving it.

● A Fork Should Have a Corresponding Join. In general, for every start (fork)
there is an end (join). In UML 2 it is not required to have a join, but it usually
makes sense.

● Forks Have One Entry Transition.

● Joins Have One Exit Transition

● Avoid Superfluous Forks. FIGURE 2 depicts a simplified description of the

software process of enterprise architectural modeling, a part of the Enterprise
Unified Process (EUP). There is significant opportunity for parallelism in this
process, in fact all of these activities could happen in parallel, but forks were
not introduced because they would only have cluttered the diagram.

● Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on an activity

diagram or to group activities in a single thread. FIGURE 2 includes three swimlanes,
one for each actor.
Figure2. A UML activity diagram for the enterprise architectural
modeling (simplified).

Figure 3. Submitting expenses.

 ● Order Swimlanes in a Logical Manner.

● Apply Swim Lanes To Linear Processes. A good rule of thumb is that

swimlanes are best applied to linear processes, unlike the one depicted in
FIGURE 3.
● Have Less Than Five Swimlanes.
● Consider Swimareas For Complex Diagrams.
● Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams.

● Consider Horizontal Swimlanes for Business Processes. In FIGURE 3 you

see that the swimlanes are drawn horizontally, going against common
convention of drawing them vertically.

7 Action-Object Guidelines

Activities act on objects, In the strict object-oriented sense of the term an action
object is a system object, a software construct. In the looser, and much more useful
for business application modeling, sense of the term an action object is any sort of
item. For example in FIGURE 3 the ExpenseForm action object is likely a paper
form.

● Place Shared Action Objects on Swimlane Separators

● When An Object Appears Several Time Apply State Names
● State Names Should Reflect the Lifecycle Stage of an Action Object
● Show Only Critical Inputs and Outputs
● Depict Action Objects As Smaller Than Activities

Conclusion: The activity diagram was made successfully by following the steps
described above.
 Experiment Number: 6

Experiment Name: Class Diagram

Experiment Name: Class diagram

Outcome: Class diagram helps to understand the static structure of a system. It
shows relationships between classes, objects, attributes, and operations.

Objective: Identify the classes. Classify them as weak and strong classes and draw
the class diagram.

Description:

A class diagram models the static structure of a system. It shows relationships

between classes, objects, attributes, and operations.

Basic Class Diagram Symbols and Notations

Classes

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 (left-aligned, not bolded, and lowercase), and
write operations into the third.

Active Classes

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, denoted with a - sign, hides information from
anything outside the class partition. Public visibility, denoted with a + sign,
allows all other classes to view the marked information. Protected visibility,
denoted with a # sign, 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.

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 just one company.
Constraint

Place constraints inside curly braces {}.

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership

between Class A, the whole, and Class B, its part. Illustrate composition with
a filled diamond. Use a hollow diamond to represent a simple aggregation
relationship, in which the "whole" class plays a more important role than the
"part" class, but the two classes are not dependent on each other. The
diamond ends in both composition and aggregation relationships point toward
the "whole" class (i.e., the aggregation).
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 superclass.

UML Class Diagram: Association, Aggregation and Composition

The UML Class diagram is used to visually describe the problem domain in terms of
types of objects (classes) related to each other in different ways.

There are 3 primary inter-object relationships: Association, Aggregation, and

Composition. Using the right relationship line is important for placing implicit
restrictions on the visibility and propagation of changes to the related classes, a
matter which plays an important role in understanding and reducing system
complexity.

i) Association

The most abstract way to describe static relationship between classes is using the
Association link, which simply states that there is some kind of a link or a
dependency between two classes or more.

Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes
parameter of ClassB instance, or returns instance of ClassB.

Strong Association

Class A may also be linked to Class B in order to show that it holds a reference
to ClassB instance.
ii) Aggregation (Shared Association) (Weak Class)

In cases where there’s a part-of relationship between Class A (whole) and ClassB
(part), we can be more specific and use the aggregation link instead of the
association link, highlighting that the same ClassB instance can also be aggregated
by other classes in the application (therefore aggregation is also known as shared
association). Class B is weak Class.

It’s important to note that the aggregation link doesn’t state in any way that Class A
owns ClassB nor that there’s a parent-child relationship (when parent deleted all its
child’s are being deleted as a result) between the two. Actually, quite the opposite!
The aggregation link is usually used to stress the point that Class A instance is not
the exclusive container of ClassB instance, as in fact the same ClassB instance has
another container/s.

Aggregation v.s. Association

The association link can replace the aggregation link in every situation, while
aggregation cannot replace association in situations where there’s only a ‘weak link’
between the classes, i.e. Class A has method/s that contain parameter of ClassB,
but Class A doesn’t hold reference to ClassB instance.

Martin Fowler suggest that the aggregation link should not be used at all because it
has no added value and it disturb consistency, Quoting Jim Rumbaugh "Think of it as
a modeling placebo".

iii) Composition (Not-Shared Association) (Strong Class)

We should be more specific and use the composition link in cases where in addition
to the part-of relationship between ClassA and ClassB - there’s a strong lifecycle
dependency between the two, meaning that when ClassA is deleted then ClassB is
also deleted as a result. Class Person is strong class.

The composition link shows that a class (container, whole) has exclusive ownership
over other class/s (parts), meaning that the container object and its parts constitute a
parent-child/s relationship.

Unlike association and aggregation, when using the composition relationship, the
composed class cannot appear as a return type or parameter type of the composite
class. Thus, changes to the composed class cannot propagate to the rest of the
system. Consequently, usage of composition limits complexity growth as the system
grows.

Clarification: It is possible for a class to be composed by more than one class. For
example, ClassA may be composed by ClassB and ClassC. However, unlike
aggregation, instances of ClassB and ClassC will never share the same ClassA
instance. That would violate the propagation of changes principle. ClassB instance
will have its own instance of ClassA, and ClassC instance will have its own instance
of ClassA.

Conclusion: The Class diagram was made successfully by following the steps
described above.

Output: Class diagram