J.E.D.I
1.8 Exercises
1.8.1 Specifying Boundaries
1. Model the system boundary of the Coach Information System. Use Figure 1.10 as your guide.
2. Model the system boundary of the Squad and Team Maintenance System. Use Figure 1.10 as your guide.
1.8.2 Practicing the Walkthrough
1. Review the system boundary model of the Coach Information System by performing a walkthrough. Prepare an action list.
2. Review the system boundary model of the Squad Team Maintenance System by performing a walkthrough. Prepare an action list.
1.9 Project Assignment
The objective of the project assignment is to reinforce the knowledge and skills gained in Chapter 1. Particularly, they are:
1. Defining the System Boundaries 2. Creating the System Boundary Model
3. Performing Walkthrough WORK PRODUCTS:
1. System Boundary Model 2. Action List
Software Engineering 35
J.E.D.I
2 Object-oriented Software Engineering
Object-oriented Software Engineering is the use of object technologies in building software. Object technology is a set of principles that guide the construction of the
software using object-oriented approach. It encompasses all framework of activities including analysis, design and testing, and the choice of methodologies, programming
languages, tools, databases and applications to engineer a software.
In this chapter, we lay the foundation for understanding object-orientation by presenting an explanation of its fundamental concepts such as objects and classes, abstraction,
encapsulation, modularity and hierarchy. We also present a general object-oriented process model that follows a component-based assembly. We also introduce object-
oriented analysis and design activities, list down some methodologies, and expected work products. Finally, we will discuss the Unified Modeling Language UML and the modeling
activity.
2.1 Review of Object-oriented Concepts
At the very heart of object-orientation, we have the objects. Objects are representations of entities which can be physical such as club membership application
form and athletes, conceptual squad assignment or software linked list. It allows software engineers to represent real world objects in software design. More technically,
it is defined as something that represents a real world object which has a well-defined boundary and identity that encapsulates state and behavior.
Attributes and relationships of an object define its state. It is one of the possible conditions by which an object exists, and it normally changes overtime. In software, the
values stored within the attributes and the links of the object with other objects define this state. Operations, methods and state machines, on the other hand, define its
behavior. It determines how an object acts and reacts to message requests from other objects. It is important that each object should be uniquely identified within the system
even if they have the same values in the attributes and behavior. Figure 2.1 depicts examples of objects with their state and behavior that may exists in the case study, Ang
Bulilit Liga.
Three objects are present- 2 athletes and 1 coach. In this picture, they are illustrated as circles where attributes are found in the inner circle surrounded by methods. Objects
are uniquely identified by their Ids such as in the case of the two athletes, Joel and Arjay. Notice that attributes are enclosed by methods. This suggests that only the object can
change the values of their own attributes. The changes in the values of the attributes can be triggered by a request, called a message, by another object. In the picture, the
coach JP assigns an athlete Joel to a squad by executing his method assignToSquad . This method sends a request message, updateSquadTraining, to the athlete Joel
to update his squad attribute.
A class is a description of a set of objects that share the same attributes, relationships, methods, operations and semantics. It is an abstraction that focuses on the relevant
characteristics of all objects while ignoring other characteristics. Objects are instances of classes. In our example, Joel and Arjay are instances of the class athletes, while JP
is an instance of the class coach.
Software Engineering 36
J.E.D.I
Four basic principles that are generally associated with object-orientation are abstraction, encapsulation, modularity and hierarchy. This concepts are interrelated and supports
one another.
2.1.1 Abstraction
Abstraction is defined as the essential characteristics of an entity that distinguishes it from all other kinds of entities
1
. It is a kind of representation that includes only the things that are important or interesting from a particular point of view. It is domain and
perspective dependent, i.e., what is important in one context may not necessarily be important in another. It allows us to manage the complexity of the system by
concentrating only on those characteristics that are essential or important in the system, and ignoring or de-emphasizing the characteristics that are not. Objects are represented
by those features that are deemed relevant to the current purpose, and hides those features that are not.
Examples of abstraction within the case study are:
1 Object-oriented Analysis and Design using the UML, Students Manual
, Cupertino, CA: Rational software Corporation, 2000, p. 2-15
Software Engineering 37
Figure 2.1 Club Membership Application Object Examples submitApplication
updateSquad AthleteID:3556
Name: Joel Santos Status: NEW
Squad: None submitApplication
updateSquad AthleteID:3557
Name: Arjay Solamo Status: NEW
Squad: None
assignToSquad
updateSport CoachID:9786
Name: JP Petines Sport: Basketball
updateSquadTraining
ATTRIBUTES
MESSAGE METHODS
J.E.D.I
• An applicant submits a club membership application to the club staff. • A club staff schedules an applicant for a mock try-outs.
• A coach assigns an athlete to a squad. • A squad can be a training squad or a competing squad.
• Teams are formed from a squad.
2.1.2 Encapsulation
Encapsulation is also known as information hiding. It localizes features of an entity into a single blackbox abstraction, and hides the implementation of these features behind
an interface. It allows other objects to interact with one another is such a way that they dont need to know how the implementation fulfills the interface. This is achieved
through the objects message interface. This interface is a set of pre-defined operations used so that other objects can communicate with it. It ensures that data
within the attributes of the object are accessible through an objects operation. No other object can directly access these attributes, and change their values.
Consider the interaction among objects in Figure 2.1 where a coach JP assigns an athlete Joel to a squad. updateSquad is the message interface that changes the
value of the squad attribute of the athlete Joel. Notice, that the change will only occur when the coach JP executes assignToSquad which triggers a request to updateSquad
Training of the squad attribute Joels. The coach JP does not need to know how the athlete Joel updates the squad but is assured that the method is executed.
Encapsulation reduces the ripple effect of changes on codes, where a change in one objects implementation will cause another change in another objects implementation
and so on. With encapsulation, one can change the implementation without changing the other objects implementation as long as the interface is unchanged. Thus,
encapsulation offers two kinds of protection to objects: protection against corruption of internal state and protection against code change when another objects implementation
changes.
2.1.3 Modularity
Modularity is the physical and logical decomposition of large and complex things into small and manageable components. These components can be independently developed
as long as their interactions are well-understood. The concepts of packages, subsystems and components in object-orientation support modularity. They will be
explained further in the succeeding sections of this chapter.
Modularity, like abstraction, is another way of managing complexity. Because it breaks something that is large and complex into smaller manageable components, it makes it
easier for a software engineer to manage and develop the software by managing and developing these smaller components. Then, iteratively integrate them.
For example, Ang Bulilit Liga case study can be divided into smaller subsystems as shown in Figure 2.2.
Software Engineering 38
J.E.D.I
2.1.4 Hierarchy
Hierarchy can be any ranking of ordering of abstraction into a tree-like structure. There are different kinds of hierarchy, and they are listed below.
• Aggregation • Class
• Containment • Inheritance
• Partition • Specialization
• Type Figure 2.3 shows an example of the Squad Hierarchy.
Software Engineering 39
Figure 2.2 Ang Bulilit Liga Subsystems
Ang Bulilit Liga Squad and Team System
Club Membership Maintenance
System Coach Information
Maintenance System
Squad and Team Maintenance
System
Figure 2.3 Squad Hierarchy
Squad
Training Squad
Competing Squad
J.E.D.I
Generalization is a form of association wherein one class shares the structure andor behavior of one or more classes. It defines a hierarchy of abstractions in which a
subclass inherits from one or more superclass. It is an is a kind of relationship. In Figure 2.3, the Squad class is the superclass of the Training Squad and Competing Squad
classes.
Inheritance is a mechanism by which more specific elements incorporate the structure and behavior of more general elements. A subclass inherits attributes, operations and
relationships from a superclass. Figure 2.3 is elaborated in Figure 2.4, all attributes and methods of the Squad superclass are inherited by the subclasses Training Squad and
Competing Squad.
Polymorphism is the ability to hide many different implementation behind a single interface. It allows the same message to be handled differently by different objects.
Consider the classes defined in Figure 2.5 which will be used to discuss polymorphism
1
. A superclass Person is modeled with two subclasses Student and Employee.
1 Examples are lifted from the Introduction to Programming Language JEDI Course Materials. Their use has prior approval from the authors.
Software Engineering 40
Figure 2.4 Elaborated Squad Hierarchy
Squad
Name MemberList
listMembers changeCoach
Training Squad Competing Squad
Figure 2.5 Polymorphism Sample
Person
Student Employee
J.E.D.I
In Java, consider the following code to implement the classes. public class Person
{ public String getName{
System.out.println“Person Name:” + name; return name;
} }
public class Student extends Person {
public String getName{ System.out.println“Student Name:” + name;
return name; }
} public class Employee extends Person
{ public String getName{
System.out.println“Employee Name:” + name; return name;
} }
Notice that both Student and Employee have different implementation of the getName method. Consider the following Java Main Method where ref is a reference to a class
Person. The first time that the ref.getName is invoked, it will execute the getName method of Student since ref references a studentObject. The second time that the
ref.getName is invoked, it will execute the getName method of Employee since ref references a employeeObject.
public static main String[] args {
Person ref;
Student studentObject = new Student;
Employee employeeObject = new Employee;
ref = studentObject; Person reference points to a Student object
String temp = ref.getName; getName of Student class is called
System.out.println temp ;
ref = employeeObject; Person reference points to an Employee object
String temp = ref.getName; getName of Employee class is called
System.out.println temp ;
}
Software Engineering 41
J.E.D.I
Aggregation is a special kind of association between objects. It models a whole-part relationship between an aggregate whole and its parts. Figure 2.6 shows an example
of an aggregation. Here, the team is composed of athletes.
Software Engineering 42
Figure 2.6 Team Aggregation
Team Athletes
J.E.D.I
2.2 Object-oriented Process Model
An object-oriented approach in developing software follows the component-based process model. It moves through an evolutionary spiral path. It is highly iterative in nature,
and supports reusability. It focuses on the use of an architecture-centric approach by identifying a software architecture baseline upfront.
Software Architecture defines the overall structure of software. It defines the ways in which that structure provides conceptual integrity of a system. It involves making
decisions on how the software is built, and normally, controls the iterative and incremental development of the system.
To manage the development in an architecture-centric way, a mechanism to organize work products is used. It is called package. A package is a model element that can
contain other model elements. It allows us to modularize the development of the software, and serves as a unit of configuration management.
A subsystem is a combination of a package i.e., it can contain other model elements, and a class i.e., it has behavior. It allows us to define the subsystems of the software.
It is realized by one or more interfaces which define the behavior of the system.
A component is a replaceable and almost independent part of a system that fulfills a clear function in the context of a well-define architecture. It may be a source code,
runtime code or executable code. It is a physical realization of an abstract design. Subsystems can be used to represent components in the design. A model of a
subsystem and component is shown in Figure 2.7.
Software Engineering 43
Figure 2.7 Subsystem and Component Model
subsystem Component Name
Component Interface
J.E.D.I
2.3 Object-oriented Analysis and Design
Kategori