Chapter-1- Introduction to Object-Oriented System

Analysis and Design (OOSAD) and UML

1. 1. Overview of OOSAD
Object oriented approach technically can follow either of the traditional
approaches like waterfall, phased, prototyping, and throwaway prototyping.

However the object oriented approach is mostly related with RAD

methodology. The main difference between the traditional approach (like a
structured design) and an object oriented one is how the system is
decomposed. In the traditional one the system or problem decomposition is
either process centric or data centric. But in case of object oriented
approach, it attempts to balance between processes and data and tries to
decompose the system into objects that encompasses both process and
data.

According to the UML, any modern object oriented approach to develop

information systems should be:

 Use-case driven: means that use-cases are the primary modelling tools
that define the behaviour of the system. A use-case describes how the
user interacts with the system to perform some activity such as
placing an order, registering a student, authenticating a user etc. A
use-case is used to identify requirements of the system and to
communicate them to the programmers.
 Architecture centric: means that the underlying software architecture
of the evolving system specification drives the specification,
construction, and documentation of the system. Modern OOSAD
approaches should provide at least three architectural views of a
system: functional, static, and dynamic. The functional (external)
architecture describes the behaviour/function of the system to the
user. The structural/static view describes the system in terms of
attributes, methods, classes, and relationships. The
behavioural/dynamic view describes the behaviour of the system in
terms of messages passed among objects and state changes in objects.
 Iterative and incremental: modern OOSAD approaches emphasize
iterative and incremental development that undergoes continuous
testing and refinement throughout the lifecycle of the project. This
means that the system analyst defines their understanding of the
 system little by little by building three architectural views. That is, the
system analyst builds first some functional representation of the
system, next he attempt to build the structural representation, next
based on the structural representation, he tries to build the
behavioural representation. The figure below describes this:

While the analyst works with the user to build all the three views, he iterates
in each of the views and also among the views (specially the structural and
behavioural views) so that some missing requirements and
misrepresentation of requirements in the functional view can be uncovered
and be corrected.

1. 2. Structured vs Object-Oriented Paradigm from a System

Analysis and Design (SA&D)

Structured Paradigm
The structured paradigm focuses on processes and data flow within a
system.

It Focus on:

 Emphasis on what the system does (functions/processes)

 System is decomposed into sub-processes
 Data is treated separately from processes
 It uses Top-down approach, Functional decomposition and Process-
oriented design
Common Modeling Tools

 Data Flow Diagrams (DFD)

 Flowcharts
 Structure Charts
 Decision Tables & Trees
 Entity Relationship Diagrams (ERD) (for data modeling)

Advantage

 Easy to understand system logic

 Well-suited for stable and well-defined requirements
 Good for transaction-based systems

Limitations

 Difficult to manage changing requirements

 Data and processes are loosely connected
 Less suitable for large, complex, or evolving systems

Example Systems

 Payroll systems
 Inventory control systems
 Batch processing systems

Object-Oriented Paradigm (SA&D Perspective)

The object-oriented paradigm focuses on real-world entities (objects) and
their interactions.

Analysis Focus

 Emphasis on what the system is (objects/entities)

 Integrates data and behavior
 Models real-world problems naturally
 It uses Bottom-up approach and Object-cantered design
 Supports system evolution and reuse

Common Modeling Tools

 UML (Unified Modeling Language):

 Use Case Diagrams
 Class Diagrams
 Sequence Diagrams
  Activity Diagrams
 State Diagrams

Advantage

 High modularity and reusability

 Better handling of changing requirements
 Easier maintenance and scalability
 Promotes abstraction and encapsulation

Limitations

 Requires more analysis effort initially

 More complex models and documentation
 Steeper learning curve

Example Systems

 Banking systems
 E-commerce systems
 Mobile and web applications

Comparison

Object-
Structured
Oriented
Aspect
Paradigm
Paradigm

Processes Objects
 Main Focus

Functional Object
 Analysis Method decomposition identification

Top-down Bottom-up
 Design Strategy

Separate from Encapsulated

 Data Handling processes with methods

DFD,
UML
 Modeling Tools Flowcharts
Easily
 Requirement Changes Hard to manage
adaptable

Simple, stable Large, complex

 Best For systems systems
 1. 3. Benefits of OOSAD
The concepts in OOSAD enable the analyst to break down a complex system
into smaller, more manageable modules, work on the modules individually,
and easily combine the modules back together to form the complete
information system. This modular development makes system development
easier to grasp, easier to share among the development team, and easier to
communicate with the users who are needed to provide the requirements
and confirm how well the system meets the requirements throughout the
SDLC. By modularizing the system development, the project team is actually
creating reusable pieces that can be plugged into other systems or be used
as a starting point to other projects and ultimately this can save time.

1. 4. The Unified Process

The unified process is a specific methodology that maps out when and how
to use the various techniques of UML in OOSAD. The unified process is a
two dimensional systems development process described by a set of phases
and workflows. The phases are inception, elaboration, construction, and
transition. The workflows include business modelling, requirements,
analysis, design, implementation, test, deployment, project management,
configuration and change management, and environment.

The Phases:
The phases of the unified process support an analyst in developing the
information system in iterative and incremental manner. The phases
describe how an information system evolves through time.

Depending on which development phase the system is currently in, the level
of activity will vary on the workflows. For example, the inception phase
primarily involves the business modelling and requirements workflow, while
ignoring the test and deployment workflows. Each phase contains a set of
iterations, and each iteration uses the various workflows to create an
incremental version of the evolving information system. As the system
evolves through the phases, it improves and become more complete. Each
phase has objective, a focus of activity over the workflows, and incremental
deliverables.
 The Inception Phase: This phase is very similar to the planning phase of
traditional SDLC approach. The primary deliverable of this phase
includes:
- vision document that describes the scope of the project,
- primary requirements and constraints of the system
- a setup of initial project plan
- description of feasibility and risk of the project
- description of system development environment etc
 The Elaboration Phase: this is the most relevant phase that primarily
focuses on the analysis and design workflows. It deals with:
- Gathering the requirements
- Building the UML structural and behavioural models of the problem
- Producing an executable of a baseline version of the evolving
information system
 The Construction Phase: This phase focuses on writing code for the
evolving information system. So, it primarily includes the implementation
workflow. However, the requirements and the analysis and design
workflows are also included. It is during this phase that missing
requirements are uncovered. The deliverable of this phase is an
implementation of the system that can be released for the acceptance
testing.
 The Transition Phase: mainly focuses on the testing and deployment
workflows. Acceptance testing, fine-tuning the design and
implementation, and user training are done here. The deliverables can
be:
- The actual executable of the information system
- User manual
- A plan to support the user
- A plan for upgrading the system in the future

The Workflows:
The workflows describe the activities or tasks that the developers perform.
These workflows are grouped into two broad categories: Engineering and
Supporting workflows.
The engineering workflows deal with activities that produce the information
system whereas the supporting workflows deal with managerial aspects like
configuration and change management and project management.

The engineering workflows are concerned with the following activities:

 Business Modelling Workflow: The activities performed here are most

likely similar to the planning phase of the traditional SDLC. However,
requirements gathering, use-cases, and business process modelling
can be done.
 Requirements Workflow: includes eliciting functional and non-
functional requirements. To gather requirements interviews,
observations, document analysis, and questionnaire can be used.
 Analysis Workflow: This addresses on the creation of analysis model
of the process domain. The analyst creates structural and behavioural
diagrams. The main purpose of this workflow is to create a common
understanding between the developer team and the user regarding the
problem.
 Design Workflow: as the analysis workflow focuses on problem
definition and understanding, the design workflow concentrates on
the solution. User interface design, database design, and physical
architecture design are done here.
 Implementation Workflow: it creates an executable solution based on
the design model. New classes can be coded.
 Testing Workflow: this focuses on increasing quality of the evolving
system. Unit testing, integration testing and also alpha testing are
done here.
 Deployment Workflow: is associated with the transition phase. It
includes activities like software packaging, distribution, installation,
and beta testing. End user training can also be delivered.

1. 5. Basics of UML
The Unified Modelling Language (UML) is a language and notation system
used to specify, construct, visualize, and document models of software
systems. UML covers a wide range of applications and is suitable for
technical (concurrent, distributed, time-critical) systems and the so-called
commercial systems.
By design, UML is not a methodology. Although the initiators and authors of
UML recognize the significance of methodologies, they consider them
distinct from language and notation systems. A methodology considers the
specific framework and conditions of an application domain, the
organizational environment, and many other things. UML can be used
within various methodologies and can form the basis for various approaches
because it provides a defined set of modelling constructs together with
uniform notation and semantics.

1. 6. Diagrams in the UML

UML provides lots of diagrams among which the most common ones are
illustrated below.

Use-case Diagram:
A use case illustrates a unit of functionality provided by the system. The
main purpose of the use-case diagram is to help development teams
visualize the functional requirements of a system, including the relationship
of "actors" (human beings/ objects who will interact with the system) to
essential processes, as well as the relationships among different use cases.

Use-case diagrams generally show groups of use cases -- either all use cases
for the complete system, or a breakout of a particular group of use cases
with related functionality (e.g., all security administration related use cases).

To show a use case on a use-case diagram, you draw an oval in the middle
of the diagram and put the name of the use case in the centre of, or below,
the oval. To draw an actor (indicating a system user) on a use-case diagram,
you draw a stick person to the left or right of your diagram. Use simple lines
to depict relationships between actors and use cases.

A use-case diagram is typically used to communicate the high-level

functions of the system and the system's scope.

Class Diagram:
UML class diagrams are one of the most important tools for both
requirements analysis and design of object-oriented software systems. These
diagrams show the classes, their attributes and operations as well as the
various types of relationships that exist among the classes.
The class diagram shows how the different entities (people, things, and
data) relate to each other; in other words, it shows the static structures of
the system. A class diagram can be used to display logical classes.

Class diagrams can also be used to show implementation classes, which are
the things that programmers typically deal with. An implementation class
diagram will probably show some of the same classes as the logical class
diagram.

The main symbols shown on class diagrams are:

 Classes: represent the types of data themselves.

 Associations: show how instances of classes reference instances of

other classes.

 Attributes: are simple data found in instances.

 Operations: represent the functions performed by the instances.

 Generalizations: are used to arrange classes into inheritance

hierarchies.

A class is depicted on the class diagram as a rectangle with three

horizontal sections. The upper section shows the class's name; the middle
section contains the class's attributes; and the lower section contains the
class's operations (or "methods").

An example of course class:

course

cr_hr
title
type
get_course()
reg_course()

An association is used to show how instances of two classes will reference

each other. The association is drawn as a line between the classes.

Symbols indicating multiplicity are shown at each end of the association.

The multiplicity indicates how many instances of the class at this end of the
association can be linked to an instance of the class at the other end of the
association.
Following are some examples of associations showing multiplicities.

A multiplicity of 1 indicates that there must be exactly one instance linked

to each object at the other end of the association. For example, above, there
can only be one Company associated with each Employee.

A very common multiplicity is *, which is normally read as ‘many’, and

means any integer greater than or equal to zero. In the above figure, for
example, many employees can be associated with a company; one possibility
being that a company has no employees.

If there can be either zero or one object linked to an object at the other end
of the association, then the multiplicity is said to be ‘optional’, and the
notation 0..1 is used. So, for example, above, it shows that there can be zero
or one office per employee. In other words, it is optional that an employee is
assigned to an office (some may work at home or in a job that does not
require an office).

You can also specify the multiplicity to be an interval, which is shown as

two dots between the lower and upper bound. An interval is also sometimes
called a range.

The 0..1 notation discussed above is a special case of an interval. If an

interval has no upper bound, then you use the asterisk; therefore 0..* and *
mean the same thing, while 1..* means ‘at least one’.

The multiplicity can be a specific positive integer; and you can also specify
several multiplicity values or ranges separated by commas. For example,
above, there can be either zero, or between 3 and 8 persons on a
BoardOfDirectors.

In some circumstances, an attribute that concerns two associated classes

cannot be placed in either of the classes. For example, imagine the
association in which a student can register in any number of course
sections, and a course section can have any number of students. In which
class should the student’s grade be put?

If you put the grade in the Student class, then a student could have only
one grade, not one per course section. If you put the grade in the
CourseSection class, then a course section could have only one grade, not
one per student. The grade is therefore not a property of either class.

The solution to this problem is to create an association class to hold the

grade. The association class is connected to its association by a dashed line,
as in the following figure, or optionally the second one. In this example, the
new class is called Registration.

In general, an association class should be named using a noun that reflects

the meaning of the association.
Sometimes, it is possible for an association to connect a class to itself, and
in this case the association is called reflexive association. For example, a
course can have another course as a prerequisite.

An association can be of type aggregation. Aggregations are special

associations that represent ‘part–whole’ relationships. The ‘whole’ side of the
relationship is often called the assembly or the aggregate.

Aggregations are specified using a diamond symbol, which is placed next to

the aggregate. This symbol is a shorthand notation that saves you from
having to write an association name such as isPartOf or its inverse hasParts.
Many aggregations are one-to-many, but this is not a requirement.

Following are three examples.

The third aggregation is a strong aggregation which is called composition.

When to use an aggregation instead of an ordinary association has always

been a source of confusion. As a general rule, you can mark an association
as an aggregation if the following are true:

 You can state that the parts ‘are part of ’ the aggregate, or the
aggregate ‘is composed of ’ the parts.
  When something owns or controls the aggregate, then they also own
or control the parts.

A composition is a strong kind of aggregation in which if the aggregate is

destroyed, then the parts are destroyed as well. A composition is shown
using a solid (filled-in) diamond, as opposed to an open one. The parts of a
composition can never have a life of their own; they exist only to serve the
aggregate. For example, as shown in the above figure, the rooms of a
building cannot exist without the building. In ordinary aggregations, on the
other hand, the parts can exist on their own. For example, the engine can be
taken out of one vehicle and placed in another, or a region can secede from
one country and become independent.

General Steps to Draw Class-Diagrams:

I) Identify a first set of candidate classes.

II) Starting with the most important classes, add any associations and
attributes that clearly will be needed.

III) Work out the clearest generalizations.

IV) List the main responsibilities of each class. These are simple
statements of functions to be performed by each class.

V) Based on responsibilities, decide on specific operations that are

needed.

VI) Iterate over the entire process, examining the model to see if you
need to add or delete classes, associations, attributes,
generalizations, responsibilities or operations. In particular, you will
want to ensure that all associations, attributes and operations are
needed to fulfil some responsibility, and that there is sufficient
information to fulfil every responsibility.

VII) Repeat the previous step as needed until the model is satisfactory.

Object Diagram:
Class diagrams tell us what classes will exist in a given system, but they are
quite abstract. Sometimes it can be hard to visualize the relationships
among the objects that will exist at run-time.

An object diagram shows an example configuration of objects and links that

may exist at a particular point during execution of a program. Objects are
shown as rectangles, just like classes; the difference is that the name of the
class is underlined and preceded by a colon, :Student, for example. You can
also give a name to each instance before the colon, as in Abebe:Student, or
even omit the class name entirely if it is clear from the context, such as
Abebe:. A link between two objects is shown as a simple line. You can
imagine that each of the two objects contains a pointer to the other object
joined by the link.

It is important to understand the relationship between a class diagram and

an object diagram. A class is an abstract representation of all the instances
of that class that can ever exist. Similarly, an association represents all the
links between two classes that can ever exist. It should be clear from this
that while we put multiplicity symbols on associations, we never put them
on links.

We say that a given object diagram is generated by a class diagram. This

means that it contains instances and links of the classes and associations
present in the class diagram. It also means that the numbers of links among
instances are consistent with the multiplicity of that class diagram. A class
diagram can generate an infinite number of object diagrams.

Interfaces:
An interface is similar to a class, except it lacks instance variables and
implemented methods. It normally contains only abstract methods although
it may also contain class variables. We can say that an interface describes a
portion of the visible behaviour of a set of objects.

In UML, there are two ways to specify interfaces as described below:

In some programming languages, interfaces are simply created using
super classes containing only abstract methods.

Interaction Diagrams:
Interaction diagrams are used to model the dynamic aspects of a software
system – they help to visualize how the system runs. They show how a set of
actors and objects communicate with each other to perform the steps of a
use case, or of some other piece of functionality. The set of steps, taken
together, is called an interaction.

Interaction diagrams can show several different types of communication.

These include:

 messages exchanged over a network,

 simple procedure calls, and
 commands issued by an actor through the user interface

Collectively, these are referred to as messages.

The following elements can be found in an interaction diagram:

 Instances of classes or actors: Instances of classes (i.e. objects) are

shown as boxes with the class and object identifier underlined. Actors
are shown using the same stick-person symbol as in use case
diagrams.
 Messages: These are shown as arrows from actor to object, or from
object to object. One of the main objectives of drawing interaction
diagrams is to better understand the sequence of messages.
Since you need to know the actors and objects involved in an
interaction, you should normally develop a class diagram and a use
case model before starting to create an interaction diagram.
Two kinds of diagrams are used to show interactions: sequence diagrams
and communication diagrams. Both contain similar information about an
interaction, although sequence diagrams have notations that make them
somewhat more powerful. Sequence diagrams explicitly show the sequence
of events on a time line, whereas communication diagrams are more
compact.

Sequence Diagram:
Sequence diagrams show a detailed flow for a specific use case or even
just part of a specific use case. They are almost self explanatory; they
show the calls between the different objects in their sequence and can
show, at a detailed level, different calls to different objects.

A sequence diagram has two dimensions:

 The vertical dimension shows the sequence of messages/calls in the

time order that they occur;
 The horizontal dimension shows the object instances to which the
messages are sent. The objects are arranged from left to right across
the diagram – an actor that initiates the interaction is often shown on
the left.

The top of the diagram is the starting point, and time progresses downwards
towards the bottom of the diagram. A vertical dashed line, called a lifeline, is
attached to each object or actor. The lifeline becomes a box, called an
activation box, during the period of time that the object is performing
computations. The object is said to have live activation during these times.

A message is represented as an arrow between activation boxes of the

sender and receiver. You give each message a label; it can optionally have an
argument list and a response.

Following is an example of sequence diagram for a customer that access

ATM.
State-chart Diagram:
The state-chart diagram models the different states that a class can be in
and how that class transitions from state to state. It can be argued that
every class has a state, but that every class shouldn't have a state-chart
diagram. Only classes with three or more potential states during system
activity -- should be modelled.

The notation set of the state-chart diagram has five basic elements:

 the initial starting point, which is drawn using a solid circle;

  a transition between states, which is drawn using a line with an open
arrowhead;

 a state, which is drawn using a rectangle with rounded corners;

 a decision point, which is drawn as an open circle; and

 One or more termination points, which are drawn using a circle with a
solid circle inside it.

To draw a state-chart diagram, begin with a starting point and a

transition line pointing to the initial state of the class. Draw the states
themselves anywhere on the diagram, and then simply connect them
using the state transition lines. Following is an example state chart diagram.
Activity Diagram:
Activity diagrams show the procedural flow of control between two or
more class objects while processing an activity. Activity diagrams can be
used to model higher-level business process at the business unit level, or
to model low-level internal class actions.

Activity diagrams are best used to model higher-level processes, such as

how the company is currently doing business, or how it would like to do
business. This is because activity diagrams are "less technical" in
appearance, compared to sequence diagrams, and business-minded people
tend to understand them more quickly.

Component Diagram:
A component diagram provides a physical view of the system. The main
purpose is to show the dependencies that the software has on the other
software components in the system. But also the components can be non-
software component such as a database or user interface; or a hardware
component such as a circuit, microchip or device; or a business unit such
as supplier, payroll or shipping.

The diagram can be shown at a very high level, with just the large-grain
components, or it can be shown at the component package level.

A component is a logical unit block of the system, a slightly higher

abstraction than classes. It is represented as a rectangle with a smaller
rectangle in the upper right corner with tabs or the word written above the
name of the component to help distinguish it from a class.

A component diagram may have an interface. An interface (small circle or

semi-circle on a stick) describes a group of operations used (required) or
created (provided) by components. A full circle represents an interface
created or provided by the component. A semi-circle represents a required
interface. This shows that one component is providing the service that the
other is requiring.

Following is an example of component diagram.

Deployment Diagram:
The deployment diagram shows how a system will be physically deployed
in the hardware environment. Its purpose is to show where the different
components of the system will physically run and how they will
communicate with each other. Since the diagram models the physical
runtime, a system's production staff will make considerable use of this
diagram.

The notation in a deployment diagram includes the notation elements used

in a component diagram, with a couple of additions, including the concept
of a node. A node represents either a physical machine or a virtual machine
node (e.g., a mainframe node). To model a node, simply draw a three-
dimensional cube with the name of the node at the top of the cube.

Use the naming convention used in sequence diagrams: