OBJECT ORIENTED ANALYSIS AND DESIGN

ASSIGNMENT - 02
QUESTIONS/ANSWERS

 WHAT IS A PACKAGE?
 WHAT IS SUBSYSTEM? HOW DOES IT RELATE TO COMPONENTS? HOW DOES IT RELATE
TO PACKAGES & CLASSES?
 DESCRIBE THE STRENGTHS OF OBJECT-ORIENTATION?
 WHAT ARE THE STEREOTYPES? WHAT ARE SOME COMMON USES OF STEREOTYPES?

Submitted by:
MUHAMMAD HASEEB ASHRAF
0364-BSCS-2014 (E1)

Submitted to:
SIR ADNAN KHALID

DEPARTMENT OF COMPUTER SCIENCE

GOVERNMENT COLLEGE UNIVERSITY

16th October, 2017.

  What is a Package?

A package is a namespace that organizes a set of related classes and interfaces. It is an organized group
of elements that may contain structural things like classes, components, and other packages in it. In the
UML, packages are used in a manner similar to the way directories and folders in an operating system
group and organize files. It is a grouping and organizing element in which other elements reside, which
must be uniquely named.
A package allows a developer to group classes (and interfaces) together because software can be
composed of hundreds or thousands of individual classes so it makes sense to keep things organized by
placing related classes and interfaces into packages. These classes will all be related in some way – they
might all be to do with a specific application or perform a specific set of tasks.
For example, the Java API is full of packages. One of them is the javax.xml package. It and its sub-
packages contain all the classes in the Java API to do with handling XML.
Packages allow us to partition our system into logical groups and then to relate these logical groups;
otherwise, it could become overwhelming to work with every class and its relationship at once. A
package is shown as a large rectangle with a small rectangle or "tab" attached to its top, left side.

 What is Subsystem? How does it relate to components? How does it relate to packages & classes?

A system is an organized collection of elements that may be recursively decomposed into smaller
subsystems and eventually into non-decomposable primitive elements.  A subsystem groups elements
that together provide services such that other elements may access only those services and none of the
elements themselves. The subsystem model is represented by UML packages. It is shown as a package
marked with the subsystem keyword. The dynamic context describes how the system interacts with its
environment. The static context of the system is designed using a simple block diagram of the whole
system which is expanded into a hierarchy of subsystems.

Subsystems and Components 

Components are implementation things; to represent the component in the design a subsystem can be
used as a proxy for the component.

 Each part of the system should be as independent as possible from other parts of the system.
 Ideally, it should be possible to replace any part of the system with a new part, provided the
new part supports the same interfaces.
 It should be possible to evolve different parts of the system independently from other parts of
the system.
To this end, Design Subsystems provide an ideal way to represent components in the Design Model:
they are design elements which encapsulate the behavior of a number of classes (as components
encapsulate the behavior of a number of class instances), and their behavior is only accessed via the
interfaces they realize (as is the case with components).

Subsystems and Packages

Within the directory structure, the source code is organized into subsystems and packages. A package is
a collection of headers and source files that provide related functionality. A subsystem is a collection of
one or more packages. For example, the Foundation subsystem contains packages such as Layout, MVC,
Events, Properties, Image, and Print. This organization helps to modularize class libraries and maps very
neatly onto UML.Each Stingray Studio product consists of one or more subsystem. For the most part,
subsystems correspond to individual products. However, a product may consist of more than one
subsystem, so it is not strictly a one-to-one relationship. This organization provides more flexibility in the
way that products are packaged, without adding complexity to the configuration of the source code. 

 Describe the strengths of object orientation?

OOP is all about the mindset, and less about programming power or simplicity (in most cases).  The
benefit is that it's one way of breaking complex problems into more manageable ones - and for many
people, it's quick to grasp and provides a consistent method for structuring their code.
Think about how code evolves from simple problems to complex ones under the OOP line of thinking:
For very simple problems, you're essentially writing a script. The next step is to find code that you
(would) repeat in your script.  That code is then generalized into functions. If you look at large
collections of functions, patterns start to emerge.  Many perform work on some type of "thing".  In an
object oriented world, that "thing" becomes an object, and all the functions doing work on it become
methods.  It's a great way to group and think about your functions.  It's a simplistic OOP world at this
point. After that, patterns start emerging between different objects.  You have many objects that have
similar sets methods, though not quite the same.  They're also used in very similar situations.  What they
do have in common are their abstract behaviors.  At this point, you introduce interfaces (or abstract
base classes) and subclassing to help define those behaviors in a consistent manner and ensure that
they can be used interchangeably. Even further!  You start noticing patterns between largely dissimilar
classes.  There may be certain portions of functionality that sets of classes have in common with each
other.  You generalize those into protocols/mixings and use multiple inheritance (or similar
methodologies) to use those generalized collections of methods/behavior in your classes.
Again, the goal is to break apart complex problems into smaller & reusable ones.   OOP is one way to
accomplish that.  However, you should ask yourself whether it makes sense for the problem at hand
(just like any other tool) - don't blindly follow it.
  What are Stereotypes? What are the some common uses of Stereotypes?

Stereotype is a profile class which defines how an existing metaclass may be extended as part of a

profile. It enables the use of a platform or domain specific terminology or notation in place of, or in
addition to, the ones used for the extended metaclass. A stereotype cannot be used by itself, but must
always be used with one of the metaclasses it extends. Stereotype cannot be extended by another
stereotype. A stereotype uses the same notation as a class, with the keyword «stereotype» shown
before or above the name of the stereotype. Stereotype names should not clash with keyword names
for the extended model element.

Stereotype is applied when it is used on use case diagrams, class diagrams, deployment diagrams, etc.
When a stereotype is applied to a model element, an instance of the stereotype is linked to an instance
of the metaclass. The name of the applied stereotype is shown within a pair of guillemets above or
before the name of the model element.
If multiple stereotypes are applied to the same element, the names of the applied stereotypes are
shown as a comma-separated list within a pair of guillemets.
When the extended model element has a keyword, then the stereotype name could be displayed close
to the keyword, within separate guillemets (example: «device» «server»).

When a stereotype includes the definition of an icon, this icon can be graphically attached to the model
elements extended by the stereotype. Every model element that has a graphical presentation can have
an attached icon. When a model element is extended by one single stereotype the icon can be
presented in a reduced shape, inside and on top of the box representing the model element.