Software Engineering Tools and Practices (SE 4091)

Chapter 01
Introduction

22 October 2016
Dileep Kumar G. ASTU 1
Outline
• Course Outcomes
• Software Process
• A Software Development Life Cycle
• Software Practices
• Software Tools Used
• UML Review: Class Diagrams
• Attributes
• Operations
• Notations

Dileep Kumar G. ASTU 2

Course Outcomes
• Become familiar with the practices used by Software Engineers for creating
software applications

• Become familiar with the various modern tools used by Software Engineers
for creating applications

Dileep Kumar G. ASTU 3

Software Process
• A software process defines the steps you take to develop (good) software
• A software process typically defines phases (or stages) and steps you take within each
phase to develop (good) software.

• What phases can you think of?

Dileep Kumar G. ASTU 4

A Software Development Life Cycle

Dileep Kumar G. ASTU 5

Software Practices
• Software practices are specific things you do as part of the software
development process
• That is, practices are activities that implement the process

Dileep Kumar G. ASTU 6

Software Tools Used
• Enterprise Architect

• Git/Bitbucket

• JUnit

• Eclipse for Java Developers

• NetBeans

Dileep Kumar G. ASTU 7

UML Review: Class diagrams
• A UML Class Diagram represents classes and their relationships to one another
• UML is not specific to Java, so a Class Diagram really represents the generic concept of a class without
regard to what language implements the actual class
• The name of the class always appears at the top of a Class Diagram rectangle

public class Account

Account
{
}

Dileep Kumar G. ASTU 8

Class diagrams: Attributes
• A Class Diagram can also show class attributes or fields
• Syntax: [visibility] <attr_name> [ : <type> [=default_value] ]

• Note: The static specification may be illustrated with an underscore or with italics

public class Account

Account
{
????? private double balance;
public static double rate = 2.5;
}
What goes here?

Dileep Kumar G. ASTU 9

Class diagrams: Attributes
• A Class Diagram can also show class attributes or fields
• Syntax: [visibility] <attr_name> [ : <type> [=default_value] ]

• Note: The static specification may be illustrated with an underscore or with italics

Account public class Account

{
- balance: double private double balance;
+ rate: double = 2.5 public static double rate = 2.5;
}

Dileep Kumar G. ASTU 10

Class diagrams: Operations
• A Class Diagram can also show class methods or operations
• Syntax: [visibility] <name>([ [in|out] param:type]*] [:<return_type>]

public class Account

Account {
private double balance;
- balance: double public static double rate = 2.5;
+ rate: double = 2.5
public void deposit (double amount) {
balance += amount;
????? }
protected double getBalance() {
return balance;
}
public static void setRate(double intRate ) {
What goes here? rate = intRate;
}
}

Dileep Kumar G. ASTU 11

Class diagrams: Operations
• A Class Diagram can also show class methods or operations
• Syntax: [visibility] <name>([ [in|out] param:type]*] [:<return_type>]

public class Account

Account {
private double balance;
- balance: double public static double rate = 2.5;
+ rate: double= 2.5
public void deposit (double amount) {
+ deposit(amount : double) : void balance += amount;
# getBalance() : double }
protected double getBalance() {
+ setRate(intRate: double) : void
return balance;
}
public static void setRate( double intRate ) {
rate = intRate;
}
}

Dileep Kumar G. ASTU 12

Notations – Indicating relations b/w classes
Most classes within an application usually have some type of relationship with one or more
other classes
Relationships can be either
• permanent (that is, static) between classes
• Inheritance
• Dependency

• dynamic between instances of classes (that is, between objects), or between classes
and objects (if a class is non-instantiable, as in a static class)
• Association
• Aggregation

Dileep Kumar G. ASTU 13

Generalization
Generalization is a form of Inheritance that indicates that a class (statically)
inherits behavior defined and implemented in another class

Here, the UML Generalization connector

originates from the LoginScreen class
inheriting the behavior (and attributes) of
the JFrame class. The connector is a solid
line pointing to the class whose behavior is
being inherited with a triangle (not an
arrow!)

Generalization can be illustrated in the alternate

notation shown if the parent class is not present in the
class diagram

Dileep Kumar G. ASTU 14

Realization
Realization is also a form of Inheritance that indicates that a class implements the
behavior defined in an interface

Here, the Realization connector originates from the LoginScreen class

implementing the behavior of the Serializable class. The connector is a
dashed line pointing to the class whose behavior is being implemented
with a triangle (not an arrow!)

Realization can also be illustrated in the alternate

notation shown if the parent class is not present in the
class diagram

15
Dileep Kumar G. ASTU 15
Class diagrams sometimes explicitly illustrate Dependency relationships of
classes on other classes (or packages)

Dependency is indicated by a dashed-line connector, with the line originating from

the dependent class and pointing (with an arrow) at the other class it depends upon.

The arrow may also point at a package (e.g. javax.swing), implying a dependency on
many of the classes within that package.

Dileep Kumar G. ASTU 16

Association
• The Association connector is used to indicate a run-time (dynamic)
interaction between instances of classes
class Class Model

Inv oice Order

The single-line connector doesn’t indicate anything specific – that is, it’s an unspecified
association.

About all we can say is that objects of these classes somehow interact when the application
executes – perhaps an Invoice somehow accesses an Order (or vice versa).

Dileep Kumar G. ASTU 17

• An Association can indicate multiplicity – that is, how many objects of one
class interact with objects of the other
class Class Model

Inv oice Order

1 1

This Association indicates that there is a one-to-one correspondence between Invoice instances
and Order instances; that is, for every Invoice object, there is one corresponding Order object, and
vice versa.

Dileep Kumar G. ASTU 18

Associations can indicate navigability – that is, whether an object
holds a reference to the other

class Class Model This one-way association indicates

that an Invoice object holds a
Inv oice Order reference to a single Order object, but
the Order does not hold a reference to
1 1 an Invoice.

class Class Model This bi-directional association

indicates that Invoice and Order
Inv oice Order objects hold references to each other.

1 1

Dileep Kumar G. ASTU 19

End Roles indicate that an association is maintained via a specific attribute
defined within a class
class Class Model
This one-to-one, one-way association with
Order Account
End Role acct indicates that an Order object
-acct
holds a reference to a single Account object
1 1
via a private Account attribute named acct.

class Class Model Here is a less illustrative way of

showing the same relationship.
Order Account

- acct: Account

Dileep Kumar G. ASTU 20

End Roles can indicate specific bi-directional references
class Class Model This bi-directional association indicates that an Order
object holds a reference to a single Account object via
Order
-ord -acct
Account
a private Account attribute named acct, and that an
1 1 Account object holds a reference to a single Order
object via a private Order attribute named ord.

It is often better to use two uni-directional arrows to

illustrate this relationship.

class Class Model

Here is a less illustrative way of
showing the same relationship.
Order Account

- acct: Account - ord: Order

Dileep Kumar G. ASTU 21

An Association can be labeled to indicate the nature of the
relationship

The absence of multiplicity indicates that this Association exhibits a one-to-one correspondence
between Person instances and House instances – that is, one Person lives in one House.

Dileep Kumar G. ASTU 22

Associations can indicate various degrees of multiplicity

class Class Model This Association indicates that for

every Order object, there is at least
Order Entry one corresponding Entry object.
1 1..*

class Class Model

Here, any number (including zero) of
Order Entry Entry objects correspond to each
Order object
1 *

Dileep Kumar G. ASTU 23

Associations with multiplicity >1 implies that a reference is a
collection of objects
class Class Model
This one-way association indicates that
Order
an Order object holds a reference to a
Entry
-items
collection of zero or more Entry objects
1 *
via a private attribute named items.
The type of collection is not specified.

class Class Model

The same association, where the
Order Entry collection is explicit.
- items: ArrayList<Entry>

Dileep Kumar G. ASTU 24

Containment (or Shared Aggregation) is a form of an association that
indicates a whole-part relationship.
class Inv oiceAggregation

Inv oice Order

Containment indicates that an Invoice is logically comprised of an Order part (one, in this case). It does not make
sense for Invoice object to exist independently of the Order object, because an Invoice always must contain an
Order.

However, the Order can exist without the Invoice. That is, if the Invoice object is deleted, the Order can still exist
(maybe it can be fulfilled free of charge).

With Shared Aggregation, the Order can also be a part of another whole-part relationship.

Dileep Kumar G. ASTU 25

Composition (or Composite Aggregation) is a stronger form of aggregation that
implies a whole-part relationship and lifetime of the parts

class Class Model

Order Entry
+items

1 *

Composition implies that an Order is comprised of Entry parts (an Order logically does not exist
without any Entry objects), and that the Entry objects cannot exist independently of the Order
object; that is, the Order exclusively owns the Entry objects.

The lifetime of the Entry objects is controlled by the Order object. If the Order is deleted, all the
Entries are deleted as well.

Dileep Kumar G. ASTU 26

Repeat: If a Composition is deleted, all of its parts are deleted with it

• A component (part instance) can be included in a maximum of one Composition at

a time.
• A part can be individually removed from a Composition without having to delete
the entire Composition.

Dileep Kumar G. ASTU 27

Inconsistent terminology between strict UML and EA

• UML Containment
• A is composed of B; B can exist
without A
• EA refers to this as Shared
Aggregation

• UML Composition
• A is composed of B; B cannot exist
without A
• EA refers to this as Composite
Aggregation

Dileep Kumar G. ASTU 28

Self-Review Questions
1. Define the following UML terms
a. Class
b. Inheritance
c. Aggregation
d. Association
e. Generalization
2. List out tools being used by software engineers?
3. How do Composite and Contained Aggregation differ?
4. Do one-to-one Associations require multiplicity indicators?
5. If the multiplicity indicator is greater than one, what is implied?

Dileep Kumar G. ASTU 29