Bahirdar University

Bahirdar Institute of Technology

Faculty of Computing
Department of Software Engineering
Course Title - Object-Oriented Software Engineering
Course Code - SEng2053

Individual Assignment
Name – Ermias Desalegn
ID - 1404196

Submitted to: Habtamu. Y

Submission Date: 12/3/2015 E.C

 Individual assignment

1. Briefly describe the differences, similarities and limitations of each of the following
Object-oriented Methodologies (4 pt)
➢ Object Oriented Analysis by Coad and Yourdon Methodology
➢ Object oriented design by Booch
➢ Object modeling technique by Rumbaugh
➢ Object oriented software engineering by Jacobson

We start by looking at Coad and Yourdon's Object-Oriented Analysis method (OOA)

(1991). In object oriented analysis and design, the identification of objects and classes is a
critical effort, although many solutions overlook this issue. For instance, it is not at all
addressed by the Booch technique or OMT. They suggest that it is a very imaginative
process that might be based on the recognition of nouns and verbs in a loose verbal
description of the problem domain. A different strategy is to utilize an object-oriented design
method, such as OOA, for the initial stages of the design process and another object-oriented
design method for the latter stages.

OOA supports designers in determining the precise requirements of their program rather to
concentrating on the structure or implementation of the product. It aims to clarify how the
current system operates and how the software system ought to interact with it. One of the
claims stated for OOA is that it helps the designer (for object-oriented systems) effectively
package the system's requirements and reduces the likelihood that the software won't meet
the client's expectations.

The Coad-Yourdon technique shines in system analysis. They employ a methodology called
"SOSAS," which stands for the five steps that make up the methodology's analysis
component. The system analysis starts with "subjects," or data flow diagrams for things. The
second stage, titled "Objects," involves identifying the object classes and class hierarchies. In
the third step, referred known as "Structures," they categorize structures into two groups:
composition structures and categorization structures. Classification structures handle the
inheritance relationship between related classes, while composition structures manage any
other links between classes. The examination then moves on to characteristics, and the
ultimate stage is services.

Coad and Yourdon outline four components that make up the design element of their process
after analysis. These are the steps in system design:

• The component defining the problem domain will specify the classes that should be
included in the problem domain.
 • The element involving human contact - These actions specify the kinds of object
interfaces.
 System-wide management classes are identified in the task management component.
• The data management component - The classes required for database access
techniques are identified in this design step.

Sadly, despite the fact that Coad and Yourdon's illustrations are beautiful, they are not
particularly simple to draw. In this lesson, we'll utilize a streamlined version of the "class
diagram" with symbols that are simpler to draw and omit some of the details that Coad and
Yourdon would add in favor of a separate list.

According to Coad and Yourdon, an object is "encapsulation" of attribute values and their
unique services, as well as a "abstraction" of something in the problem domain that reflects a
system's ability to store information about it, interact with it, or both. Another fundamental
idea from Coad and Yourdon We will just state the characteristics of each class rather than
attempting to jam a list of features for each class into a portion of an image (like Coad and
Yourdon do). Instance connections do not necessarily need names, according to Coad and
Yourdon, unless there are several connections between the same set of classes.

• The methodology of Coad and Yourdon has some flaws and issues since it pays little
attention to how objects work and behave. And also it has limitations since the idea
of a "subject" in place of a "sub-system." The Coad/Yourdon technique has another
fault, a lack of a clearly defined methodology, a disproportionate emphasis on the
data display, which is also quite basic, and a lack of real-time support. The approach
is likewise inapplicable to large systems.
• Coad and Yourdon methodology is based on a uniform underlying representation
(classes and objects) which leads to a number of major implications like: no major
difference between analysis and design notations, no transition between analysis and
design, no waterfall model has to be followed; spiral and incremental are also
possible, there are still a lot of different strategies and skills needed for analysts and
designers, there are a uniform representation from OOA to OOD to OOP. For Coad
and Yourdon an object oriented approach consist of classes, objects, inheritance and
communication with messages.

NOTE: Sometimes this methodology is different from other methodologies or covers a

different region. In object-oriented analysis and design, the identification of objects and
classes is a critical effort, although many solutions overlook this issue. For instance, neither
the Booch technique nor OMT fully address it. The find class-and-objects, attribute, services,
and structure layer activities, in that order, perform the identification of classes, attributes,
behavior, and relationships. In their discussion of whole-part and gen-spec structures for the
aggregate and generalization relationships, Coad and Yourdon refer to methods as services.
A message can be sent from one object to another using an instance connection, according to
the technique. The association relationship and this are comparable. Instead than focusing on
the structure or implementation of the product, OOA aids designers in identifying the
specific requirements of their software. It seeks to define the functioning of the current
system as well as how the software system ought to relate to it.

The second method that we are going to see is Booch’s methodology. The Unified
Modeling approach was inspired by Grady Booch's Object-Oriented Design (OOD). Six
different sorts of diagrams are used in the Booch method: class, object, state change,
interaction, module, and process.

Extremely user-friendly and straightforward database design tool is Edraw. Booch OOD tool
can help you avoid working hundreds of hours. It has unique settings and forms for
producing Booch OOD diagrams. Most people agree that Booch's notation is the most
comprehensive for describing object-oriented systems. Unfortunately, the notation is
extremely complicated, which can cause information to be duplicated or cut up across several
model diagrams. Booch focuses more on the outcomes of system analysis and design than its
process since he sees himself as a developer rather than a methodologist. He has made a
significant contribution to the UML and made his notation a part of the public domain.

The object system design is the main area of strength for Booch's methodology. In addition
to a domain study phase, Grady Booch's methodology also includes a requirements analysis
that is comparable to a conventional requirements analysis. The four components of Booch's
object system design methodology are the physical structure diagram, where the object
methods are detailed, the logical structure design, where the class hierarchies are established.
Booch also analyzes the dynamics of object instances, where he explains how an object may
change state, and defines the dynamics of classes in a way that is quite similar to the
Rumbaugh method.

The Booch approach, along with object-oriented software engineering (OOSE) and the
object-modeling technique, served as a foundation for the creation of the Unified Modeling
Language, generally known as "UML" (OMT). The Booch method's various components
were also used as the basis for some other techniques and procedures.

• The Booch methods are recognized to have a number of drawbacks, including a

complex notation that is challenging to hand-draw. This is as a result of how in-depth
the annotation is. Information may become dispersed throughout several diagrams
because the method uses a variety of distinctive diagrams. Application may be
challenging due to the inadequate explanation of the method's operational processes.
 The fact that the Booch technique defines a large number of symbols to record
practically every design choice is another drawback I've observed. Not all diagrams
and symbols are employed. Concentrate solely on design rather than analysis, is how
we can put it.
• It focuses entirely on design not analysis.

NOTE: The Booch technique also has some distinctive characteristics. A macro
development process and a micro development process are recommended by the Booch
technique. A class diagram, a state transition diagram, an object diagram, a timing diagram, a
module diagram, and a process diagram are also used. Use associations to establish
relationships.

The third object oriented approach we are going to see is the Rumbaugh’s method
called object modeling technique. A technique for creating maintainable object-oriented
systems and supporting object oriented programming is the Rumbaugh methodology,
sometimes referred to as OMT (Object Modeling Method). The idea is to make it simple to
define class properties, methods, inheritance, and association. In the actual world, OMT is
utilized for software modeling and design.

Rumbaugh claims that there are several key justifications for using this modeling strategy.
Making client communication simpler and simulating entities prior to their construction are
two examples. By visualization, it also aids in simplifying difficult situations.

OMT is divided into four stages:

• Analysis
• Implementation
• Object Design
• Systems Design

OMT is also always divided into three distinct portions. They include the:

• dynamic model
• object model
• A function model

The static, structural, and data aspects of a system are described by the object model. The
temporal, behavioral, and control properties of a system are described by the dynamic model.
The transformational and functional elements of a system are described by the functional
model. These three elements are present in every system. Each model includes references to
the other models while describing a particular feature of the system.

There are four stages to the complete OMT software development processes we mentioned
above: analysis, system design, object design, and software implementation. In the analysis
phase, the majority of the modeling is completed. Three fundamental models—the Object
Model, the Dynamic Model, and the Functional Model—are created at this phase. Although
while the Object Model is the most crucial since it explains the fundamental building block
of the system, the objects, all three models taken together describe the entire functioning
system.

An object model explains the objects in a system and how they relate to one another. This
approach ignores the dynamic nature of the things and sees them all as static. Dynamic
Model depicts the dynamic aspects of the system. It depicts the alterations in the statuses of
various objects as a result of potential system events. And the Rumbaugh methodology is the
one that comes closest to the conventional method of system analysis and design, and
beginners will be able to use concepts and symbols they are already familiar with. The
Rumbaugh methodology excels in both object design and object analysis, but its greatest
strength is in the latter.

Some limitation or disadvantage features of Rumbaugh’s methodology are as follows…

• The perspectives are not clearly integrated.

• Little attention to subsystems.
• No enforcement of encapsulation in the sense of data hiding
• Cannot fully express the requirements
• OMT’s primary weakness is its lack of an explicit mechanism to capture timing
constraints and real-time issues. There is also a high risk that information can be
fragmented across various diagrams and models.

This method’s unique properties: Uni-directed and uses associations for relation. Use data
flow diagrams, state transmission diagram, class/object diagram.

Our last object oriented methodology that we are going to discuss here is object
oriented software engineering (objectory) by Jacobson. The Jacobson approach is a process
for organizing, designing, and putting into practice object-oriented software. It is often
referred to as Object-Oriented Software Engineering (OOSE) or even Objectory. A collection
of requirements, an analysis, a design, an implementation, and a testing model make up the
method's five components. In a novel way, the OOSE technique incorporates use cases into
its design. Later, we will go into greater detail on these use cases and the five components.

The techniques developed by Jacobson et al. span every stage of the life cycle and emphasize
both forward and backward traceability between the various phases (for instance, Object-
Oriented Business Engineering (OOBE), Object-Oriented Software Engineering (OOSE),
and Objectory). This traceability allows for the reuse of analysis and design work, which
may contribute more to the decrease in development time than code reuse. Their techniques
are based on the use-case idea, which emerged with Objectory (Object Factory for Software
Development).

Use cases are hypothetical situations used to comprehend system needs. An interaction
between users and the system is a use case. The use case model encapsulates the user's
objective and the system's duty to its users. The use case description must contain:

• The interaction between the use case and its actors including when the interaction
occurs and what is exchanged.
• How and When the use case will need data stored in the system or will store data in
the system.
• The flow of events exception.
• How and when to handle concepts of problems.
• How and when the use case begins and ends.

Limitations of Jacobson’s method:

• It do not treat OOP to the same level as other methods.

• The biggest drawback is that, because it covers the entire software life-cycle, it is
difficult to implement in a business. The technique has been found to have certain
weaknesses, including a lack of some modeling components. Another flaw is the
unclear description of the change from analysis objects to design blocks (and the
classes of the blocks), which makes it challenging to maintain traceability.
• The fact that Objectory's method "automatically" converts the situations into objects
is one of the key issues with it. We will allocate one control object to each specific
use case, which is how the control objects are often discovered. A client interface
defined in objects not related to the client's problem domain is provided by this type
of control object. This is not in accordance with object-oriented
• A mode of thinking, this method seems to produce more classes than necessary, the
primary function of which is to coordinate other objects. This goes against the notion
that an object should act in accordance with its inherent nature. A control object File
 Manager will manage the copying of a file when using the Objectory method rather
than an instance of the class File with a copy operation, which is a better object-
oriented solution.

NOTE: Its distinctive quality, which distinguishes it from alternative approaches, is a

frequent finding is that the methodologies provide little guidance on where to begin the
modeling process. Only the objectory approach makes it apparent that scenario identification
(use cases) comes first in the modeling process before class identification, which is the
customary first step.

The Objectory technique is unique from the other three ways in that it approaches software
development more comprehensively (i.e., considers the entire software life-cycle).
Requirement analysis, design, implementation, and testing are the four stages that make up
the methodologies. The two procedures that are most pertinent in this situation are
requirement analysis and design. The actions of requirement analysis are List the possible
actors (an actor is the one will use the system), Determine the relationships and objects in the
domain (a domain object is an object in the problem domain), A use-case is a flow of system
events (similar to a scenario), including the interaction with the surroundings (the actors),
thus find use-cases based on the requirements specification and the needs of the actors.
Provide specifics on the use-cases. Identify the design object from the requirements analysis
model and Adapt the design model to the implementation environment make up the two
primary components of design work. In the first activity, design objects are identified from
use-case descriptions, and their features, relationships, and behaviors are described. Here, the
behavior of the use-cases is distributed to the objects.

In contrast to the other ways, objectory addresses a variety of software development-related

concerns, including as management problems and testing. Data-base and real-time
specializations of the approach are covered in separate sections. The approach places a
significant emphasis on traceability and a product-focused approach to software
development.

OMT and use scenario for modeling of user behavior while objectory or Jacobson uses use
case. Each method also uses different type for object collaboration: OMT-event trace, OOD-
timing diagram, Jacobson-interaction diagram, and message (connection) is used in OOA. In
Uni-directional relationship: OMT-directed association, OOD-uses, Jacobson-acquaintance.
Bi-directional: OMT-undirected association, OOD- association and OOA-instance
connection. And they have different strength OMT has a strength in analysis OOD focus on
design Jacobson has strength in requirement, but OOA is simple. And also the 3
methodologies OMT, OOD and Jacobson use state model. And use subsystem as system
partition. But the OOA uses subjects.

Similarity of object oriented methodologies: Any useful system is complex enough so that
it is not comprehensible in a single model. People need to deal with a small piece at a time
due to human cognitive limits and practical considerations. SBM therefore deal with small
models called scenarios, which collectively make up the overall solution-based model. The
concept of scenarios is well-known in object-oriented methods (example Booch, Jacobson
and Rumbaugh). Each scenario has a single topic, generally consists of less than a half-dozen
elements and a subset of their relationships independent of the overall model and other
scenarios. Ideally, a scenario should be a gestalt, a whole that is taken by the viewer as being
more than just the sum of its parts. A melody is an example of a gestalt. The musical notes
do not mean anything, but when played one after another, they form a melody. The concept
is similar to the ones used in OMT and Objectory (use cases). Each object oriented
methodologies give or accept

And another similarity: Encapsulation, polymorphism, and inheritance are the three features
that constitute object-oriented languages, which are the foundation of object-oriented
approach. We can also see the following table which shows some similarity between the first
3 methodologies that I have mentioned above.

The diagram which all methods used:

Component Booch OMT Coad/Yourdon

Identification of Class and Objects
Class diagram Class diagram
classes diagram layer 1
Identification of Class and Objects
Class diagram Class diagram
attributes diagram layer 4
Class diagram State
Identification of Class and Objects
Class diagram diagram Data flow
operations diagram layer 5
diagram
Inheritance and
Class and Objects
aggregation Class diagram Class diagram
diagram layer 2
relationship
Specification of
dynamic behavior
Timing diagram Event trace diagram ---
(example: message
passing)
Large-scale (Module diagram) --- ---
modelling
partitioning
Object state
States and State transition
State diagram diagram Service
transitions diagram
chart
Detailed logic for State diagram Data
Operations template Service chart
operations flow diagram
End-to-end
processing Timing Diagram Data flow diagram ---
sequences
Table1 direct source: https://www.diva-portal.org/smash/get/diva2:833707/FULLTEX01.pdf

2) Clearly explain the key OO concepts (pillars of OOP) using examples from real-
world situations and show simple Java code to demonstrate each concept. (3pt)

Object oriented programming has 4 pillars such as: abstraction, encapsulation, inheritance
and polymorphism. We are going to see them one by one.

The first pillar; Abstraction is the process of shielding the user from implementation
specifics and only exposing the functionality. We deal with ideas, not occurrences, in
abstraction. As a result, the user will only be aware of "what it does," not "how it does." It
hides all unwanted data so that users can work only with the required data. It removes all
non-essential things and shows only important things to users.

About this OOPS pillar, it's important to keep in mind the following:

 If a class has one or more abstract methods, the class should be abstract.
 Constructors, concrete methods, static methods, and final methods can all be found in
abstract classes.
 The new operator cannot be used to instantiate an abstract class directly.
 If the parent class's abstract methods are not to be overridden by the child class, the
child class should be declared with the abstract keyword.

There are two types of abstraction in OOP:

1. Data Abstraction
2. Process Abstraction
Data abstraction:
A method for generating complex data types and exposing only the operations required to
interface with them while concealing the implementation specifics from outside activities is
called data abstraction. The advantage of this strategy is the opportunity to make
improvements to the implementation over time, such as resolving any performance problems.
As there is no difference in the abstract behavior, such modifications are not meant to have
any effect on client code.
Process abstraction: We are not required to disclose all of an object's capabilities. By
concealing the internal implementation of the several functions involved in a user operation,
process abstraction is achieved. A piece of software is essentially a collection of
programming language-written statements. Most often, comparable and repeated statements
can be found in multiple places. Process abstraction is the method of locating all such
statements and exposing them as a single unit of work. This feature is typically used when
creating a function to carry out any operation.

 Examples from everyday life help us understand this notion very clearly. The driver
of a car is familiar with it. He is knowledgeable about the various automotive parts
and how to operate them. For instance, a car owner is aware that depressing the brake
pedal reduces speed and pressing the accelerator pedal increases it. You don't need to
understand how these components work; you just need to know how to use them in
order to carry out these straightforward operations.
 We have another straightforward example in our hands. You simply write the text and
send the message when you need to send an SMS from your mobile device. But you
are unaware of how the message delivery was handled inside.

abstract class Shape{

abstract void draw();
}
// implementation is provided by others i.e. unknown by end user.
class Rectangle extends Shape{
void draw(){System.out.println("drawing rectangle");}
}
class Circle1 extends Shape{
void draw(){System.out.println("drawing circle");}
}
// method is called by programmer or user
 class TestAbstraction1{
public static void main(String args[]){
Shape s=new Circle1();
s.draw();
}
}
Output: drawing circle

The second pillar is encapsulation. By providing rigid exterior interfaces,

encapsulation is an approach for reducing interdependencies among independently built
modules. A module's external interface acts as a contract between the module and its users,
and hence between the module's designer and other designers. The module can be re-
implemented without affecting any clients if clients solely rely on the external interface,
provided that the new implementation provides the same external interface or one that is
upward compatible. The results of compatible changes might therefore be limited.
If customers are only permitted to access a module through the defined external interface as
described by the programming language definition, the module is said to be encapsulated.
Hence, encapsulation provides designers with the reassurance that compatible changes can be
made securely, facilitating the evolution and maintenance of programs. These advantages are
particularly significant for large systems with persistent data. If the field is declared private
in the class then it cannot be accessed by anyone from outside the class and hides field within
the class. Therefore, it is also called data hiding.
The most fundamental principle of OOP is that every object contains some data and code.
Other client objects can make requests to the object, but they are not given access to the
specifics of its data or code. By making methods that make up the object's implementation
private while making public messages for clients, the object is solely in charge of
maintaining its own state. The client relies on the (ideally) straightforward public interface; it
is unaware of or unaffected by the implementation's finer points. Encapsulation lets us reuse
functionality without jeopardizing security. It’s a powerful, time-saving OOP concept in
Java. For example, we may create a piece of code that calls specific data from a database. It
may be useful to reuse that code with other databases or processes. Encapsulation lets us do
that while keeping our original data private. It also lets us alter our original code without
breaking it for others who have adopted it in the meantime.
Examples in real time:
  One of the most concrete examples of encapsulation is a school backpack. Our books,
pencils, and other materials can be kept in the school bag.
 In the banking system, the balance variable is designated as private to protect your
account and prevent others from seeing your account balance. Only private members
of that class's methods may be accessed by the person who needs to view his account
balance, and these methods will require authentication using the account holder's
name, user ID, and password. Thus, we can achieve security by making use of the
idea of data concealing.
 Another clear example encapsulation in the real world is the capsule, which encloses
all of its medicinal components. In Java, encapsulation units (classes, interfaces,
enums, etc.) do the same thing by enclosing all of their data and functionality.

class Area {

// fields to calculate area

int length;

int breadth;

// constructor to initialize values

Area(int length, int breadth) {

this.length = length;

this.breadth = breadth;

} // method to calculate area

public void getArea() {

int area = length * breadth;

System.out.println("Area: " + area); } }

class Main {

public static void main(String[] args) {

// create object of Area

// pass value of length and breadth

Area rectangle = new Area(5, 6);

 rectangle.getArea();} }

In the above example, we have created a class named Area. The main purpose of this class is
to calculate the area. To calculate an area, we need two variables: length and breadth and a
method: getArea() Hence, we bundled these fields and methods inside a single class. Here,
the fields and methods can be accessed from other classes as well. Hence, this is not data
hiding. This is only encapsulation. We are just keeping similar codes together.
The third one is inheritance. One of the most crucial elements of Object Oriented
Programming is inheritance (OOP). The fact that inheritance allows for code reuse is the key
to understanding it. We can just inherit the properties of one class into the other rather of
repeatedly writing the same code. Inheritance is a technique to describe real-world
relationships while OOP is all about real-world objects. Here's an illustration: a car, a bus,
and a bicycle are all included in the larger category of "vehicle." That indicates that they
have inherited the characteristics of the class of vehicles, i.e., they are all utilized for
transportation. Another intriguing thing about inheritance is that it is transitive in nature.

The process through which one class acquires the attributes and methods of another class is
known as inheritance. The Parent class is the one from which the inherited properties and
methods are derived. The Child class is the one that receives the parent class's properties as
inheritance. The intriguing part is that a child class can have its own properties and methods
in addition to the ones it inherits.

Advantages of Inheritance: Code reuse is made easier through inheritance. The parent
class's code may be used by the child class without having to modify it. While the primary
code does not need to be written again, inheritance can save time and effort. A simple and
understandable model structure is provided by inheritance. Less money is spent on
development and upkeep when there is an inheritance. Through inheritance, we will be able
to override base class methods so that the derived class can design a useful implementation
of the base class method. Less money is spent on development and upkeep when there is an
inheritance. With inheritance, the base class can choose to keep some data private so that the
derived class cannot change it.
Different types of Inheritance in Java:

Java supports the following kinds of interfaces:

a. Single Inheritance
b. Multilevel Inheritance
c. Hierarchical Inheritance
d. Multiple Inheritance(Only through Interfaces)
e. Hybrid Inheritance
real time examples:
 Vehicles have two subclasses: Cars and Pulled Vehicles.
 The base class or superclass of drawn vehicles and automobiles is referred to as a
vehicle.
 The subclasses or derived classes of automobiles are car and bus.
 The foundation class or superclass of the car and bus is the automobile
 We can also see our self. First God created Adam then Hewan was created from
Adam inherited features of Adam she also has her own property. Then they live
together and a new child was born from them by inheriting some properties from
them. This is a clear inheritance example in real world.
class Animal{
void eat(){System.out.println("eating...");}
}
class Dog extends Animal{
void bark(){System.out.println("barking...");}
}
class TestInheritance{
public static void main(String args[]){
Dog d=new Dog();
d.bark();
d.eat();
}}
Output: barking…
eating…
In the example given above, Dog class inherits the Animal class, so there is
the single inheritance.
The last pillar is polymorphism. One of the fundamental ideas of object-oriented
programming (OOP), polymorphism addresses circumstances where something happens in a
variety of ways. It refers to the idea in computer science that you can access objects of many
types through the same interface. Each type may offer a unique, autonomous implementation
of this interface.
Java supports 2 types of polymorphism:

 static or compile-time
 dynamic

Static: Like many other OOP languages, Java enables the implementation of several
methods with the same name in the same class. Java, however, has a separate set of
parameters known as method overloading, which is a static variation on polymorphism. Each
of these overloaded methods often offers a unique yet remarkably comparable functionality.
Each method has a unique signature because of the various sets of parameters. By binding
the method call to that signature, the compiler is able to determine which method to call.
Static polymorphism or static binding are two names for this strategy.

Dynamic polymorphism: This type of polymorphism prevents the compiler from knowing
which method was actually called. This runtime action is required of the JVM. A subclass
can override a method of its superclass inside an inheritance tree, allowing the creator of the
subclass to modify or entirely alter the behavior of that method. Moreover, it results in a type
of polymorphism. The names and parameters of both methods are shared by the super- and
subclasses. Yet, they offer various functionalities.
Real time examples of polymorphism:
 Water is a liquid, as we all know, but it turns into a solid when it freezes and into a
gas when heated to its boiling point.

 A boy starts his love by saying the word “friendship” but the girl ends that love with
the same word “friendship”. The girl says that we will be always good friends.

 Human behavior is the best illustration of polymorphism. Several behaviors might

exist in one individual. For instance, a person may take on the roles of an employee in
an office, a client in a mall, a train or bus passenger, a student in a classroom, and a
son at home.

 To turn the computer ON and OFF, we all press the same button.

class Language {
public void displayInfo() {
System.out.println("Common English Language");
}
}
class Java extends Language {
@Override
public void displayInfo() {
System.out.println("Java Programming Language");
}
}

class Main {
public static void main(String[] args) {
 // creating an object Java class
Java j1 = new Java();
j1.displayInfo();

// create an object Language class

Language l1 = new Language();
l1.displayInfo();
}
}
In the above example, we have created a superclass named Language and a subclass named
java. Here, the method displayInfo() is present in both language and java. The use of
displayInfo() is to print the information. However, it is printing different information in
language and java.

3) Describe the following terms in OOSE perspective? (3pt)

A. System, Subsystem, component, Package, libraries, Modules, frameworks and class

System: A set of elements organized to achieve certain objectives form a system. Systems are
often divided into subsystems and described by a set of models. A system is roughly described
as a coordinated group of components that work together to achieve a specific goal. The goal
of the systems engineering process is to produce a system as the end result. The fundamental
components of a system are called elements, which can also refer to persons, facilities,
policies, documents, databases, and software in addition to hardware and software. A system
is made up of different pieces combined. A system can be broken down into a hierarchy of
sets of components, including parts, subcomponents, components, and subcomponents.

The body, chassis, engine, drivetrain, suspension, electrical power system, etc. are all
subsystems of a vehicle, which is another well-known example of a system. A refrigerator is
not a particularly complex system, but the Space Shuttle is regarded as one of the most
complex systems ever created.

Subsystem: A subsystem can act as a system on its own, but it typically can't do so by itself;
instead, it needs to be connected with other subsystems to form a system. The system must
therefore be composed of interfaced or connected subsystems. A specific subsystem may be
referred to as either a "subsystem" or a "system" in the literature; this is frequently just a
nomenclature decision made by the project manager or the systems engineer.

Component: A component is a distinguishable element of a bigger building or program. A

component often performs one specific function or a set of related functions. A component is
a reusable program building block in object-oriented programming and distributed object
technology that may be joined with other components on the same computer or other
machines in a distributed network to create an application. A container serves as the context
in which a component operates.

A component is a structurally distinct element in any system. It performs a certain function

and could call for input or give off output. Classes are frequently used in software to
represent a component.
The Component lies between the Module and the Object in terms of granularity. A
component serves the purpose of assembling a group of universally useful items to create a

unit with a defined function. As its name suggests, the Component is not "self-contained"
like the Module is; rather, it is a part of a larger functional whole.

The Component lies between the Module and the Object in terms of granularity. A
component serves the purpose of assembling a group of universally useful items to create a
unit with a defined function. As its name suggests, the Component is not "self-contained"
like the Module is; rather, it is a part of a larger functional whole.

Package: A package is a portion of code that has been separated from the rest so that it can
be readily distributed among others once someone creates their own libraries and
frameworks, this namespace is used to aggregate related system objects.
A group of related classes and interfaces is referred to as a package. In this regard, packages
resemble libraries in that they manage and arrange collections of classes. Nevertheless,
packages offer more than just organization at the source-code level. Also, they expand the
scope of their classes and all of the variables and methods contained within them.

Although it may appear absurd, a package's typical function is to compile a set of modules
that share a common functional goal. facilitating the inclusion of all relevant modules at
once. A package is an organized group of elements. A package may contain structural things like
classes, components, and other packages in it

Libraries: A library is essentially a group of useful programs or lines of code that have been
built specifically for you and may be incorporated into your programs. A library is a specific
type of program module that contains (or, more precisely, owns) a collection of (sub)
modules to be utilized in a restricted (i.e., not permitted to be directly modified in later use)
manner. A library is often made to be deployed and reused in non-volatile storage. A library
is typically offered as one or more on-disk files in some reliable permanent formats. These
libraries go by many names, including archives, dynamic objects, packages, etc. In addition
to filenames and other file-based features, libraries can also be identified with the help of
external application databases. For instance, CLI uses GAC to provide library assemblies.

A library is a collection of code fragments (which could take the form of variables, functions,
classes, interfaces, etc.) created by programmers to make software development easier for
other programmers who find it useful. In plainer terms, a library is nothing more than a
straightforward computer program that is created to be used in or imported into another
computer program in order to facilitate the implementation of particular tasks or a group of
related tasks without having to engage in inner technical abstraction of how the tasks will be
carried out. Libraries are collections of classes that are grouped together to serve a common
purpose and are simple to use in any project. At its heart, a library is simply a collection of
packages. Its goal is to provide a collection of functionalities that are ready to use so that
users can focus on other packages. In order to add functionality to your code, you must
include a library. It also doesn't impose any certain coding style on you.

Modules: It is similar to how large applications are frequently constructed in a number of

sections that are more closely connected to one another than to the outside world. It makes
sense to offer these components more access to one another than the outside world already
does. Also, these components may be reused across the system without concern for data
synchronization. The Java term for this component is module. WAR, jar, etc. are referred to
as modules in Java. A component with different levels of granularity, a module is the result
of modular design.

A module is an entity that can be expressed by the coding language that introduces
programmability to the solution (usually, a programming language or a hardware description
language). Although some other languages do not have a distinct feature called a module,
users can describe specific software components as modules. For instance, although the C
programming language lacks modules, users can designate a function, a source file, a
translation unit (a source file plus the headers it contains), or even a collection of files as a
module on demand. In this situation, a module may contain many types of code, including
source code, binary code derived from source code or provided elsewhere with linkage
compatibility assurances, or even a combination of the three.

The only true restriction on a "module," if any, is that it should reflect the outcome of a
modular design. To clearly define the boundary, components inside a module should have
some commonalities. The standard practice is for a module to export some sort of user
interface and import dependencies from other program modules if necessary. A module may
be a sub-module of another module. Tools for code management may make use of module-
related principles. As an illustration, the sub-module idea in Git effectively refers to a
versioned subdirectory of code in the repository. It is only a small portion of a library
because it also includes numerous developer-friendly tools. Classes, scripts, and tools are
added to a project easily as modules or plugins to add Instant functionality. It is the smallest
software component. A set of prepared procedures or functions is known as a module.
A module is a container for a group of parts that work together to fulfill the criteria for the
module. While not actually functional on its own, a module should be self-contained,
comprehensive, and able to cooperate with any conforming implementation.

Frameworks: library set is referred to as a framework. This time, however, the framework
offers more than simply functionalities; it also offers an architecture for the development
effort. With reference to the concept of a library, we could define a framework as a tool that
offers a developer the essential libraries in a controlled development environment, enabling
the developer to address a wide range of domain-specific challenges.

A framework includes a number of pre-designed functionalities. A framework may be made

available as one or more libraries. A framework emphasizes a mostly finished, frozen but
adaptable and extensible solution of some common work, which allows the user of the
framework to concentrate on the domain-specific and project-specific problems rather than
writing glue code to connect various libraries and make them function smoothly. This is how
a framework differs from other types of modules in a program.
One or more libraries may be used to launch a framework. The key distinction between a
framework and other types of modules in a program is that the former places an emphasis on
a mostly finished, frozen but adaptable and extensible solution of some common work,
allowing the framework's user to concentrate on project- and domain-specific issues rather
than writing glue code to connect various libraries and make them function smoothly.

Class: A class is the blueprint for creating objects in class-based object-oriented

programming. It is a typical Java file with a.java extension that includes all the objects,
methods, and other components required to create an application are also implemented or
extended other objects or methods from other files. A class is a template for the variables and
methods in a specific type of object. As a result, an object is a particular instance of a class;
instead of variables, it holds real values. A class is a description of one or more objects with
a common set of features and instructions on how to generate new objects that fit into the
class.

Syntax of Class in Java:

class <class_name>{
 field;
method;
}
B) Briefly describe the difference between package and component.

A logical partition of the solution space is called a package. A component is an artifact that
can be deployed if: One package may span several components, multiple packages may be
contained in a single component, and of course there is the simple one package to one
component, 1 to 1, scenario. A component, on the other hand, is a tangible output that can be
used by a node. It can be deployed physically (typically, a host).

Packages are used to group items. A system's components are replaceable parts. Components
and packages are typically identified in the design model and the analysis model,
respectively. Component diagrams are used in component-based programming. A package is
typically a configuration management artifact. It just serves to compile "model elements" and
does not necessary have any semantic meaning. A package might be used, for instance, to
assemble all the model parts for a specific software release.

An interchangeable module that is implemented as software and interface-protected is

referred to as an application component. It also functions as the logical core of the
application. Contrarily, a component can be of any size, from Java beans to subsystems, even
if a subsystem is a very large-scale module. Components may thus appear in a Component
Diagram, a Class Diagram (which represents classes), or a Package Diagram (which
represents subsystems) (components like COM widgets or JBs).

In the UML, groups of classes are deployed as components, while packages are a more
thorough way to group model elements. Packages can group any model elements, including
use cases, although in reality they usually group classes, which is why components and
packages are frequently confused.

A component diagram displays an encapsulated class' internal structure, including its

interfaces, ports, and hierarchical connections. It addresses the static implementation and
design of the system. The package diagram displays the division of the model into
organizational units and how those units are interdependent.
Simply put: Grouping stuff into packages. The components of a system are exchangeable
pieces. Typically, components are recognized in the design model and packages in the
analysis model. Component-based development employs component diagrams.
Reference:
https://www.geeksforgeeks.org/

https://logicmojo.com/

https://web.stanford.edu/class/archive/cs/cs108/cs108.1092/handouts/09OOPEncapsulation.pdf

http://www.btechsmartclass.com/

https://stackify.com/

https://www.d.umn.edu/

https://www.edrawsoft.com/

https://en.wikipedia.org/

http://www.dba-oracle.com/

https://www.conceptdraw.com/

https://www.diva-portal.org/smash/get/diva2:833703/FULLTEXT01.pdf

https://softwareengineering.stackexchange.com/

https://www.westga.edu/~bquest/1997/object.html

https://learn.saylor.org/mod/book/tool/print/index.php?id=26802

https://wikidiff.com/component/package

https://wikidiff.com/component/package

https://the-definition.com/term/oop-class

https://medium.com/quick-code/what-are-libraries-frameworks-and-packages-b614b5f3e67f