Principles of Object-Oriented Systems ( 10 mark)

(or)

Elements of the Object Model: ( 10 mark)

 “most programmers work in one language and use only one programming style. They program in
a paradigm enforced by the language they use. Frequently, they have not been exposed to alternate
ways of thinking about a problem, and hence have difficulty in seeing the advantage of choosing a
style more appropriate to the problem at hand.

 The conceptual framework of object–oriented systems is based upon the object model. There are
two categories of elements in an object-oriented system −

Major Elements − By major, it is meant that if a model does not have any one of these elements, it
ceases to be object oriented. The four major elements are −

 Abstraction

 Encapsulation

 Modularity

 Hierarchy

Minor Elements − By minor, it is meant that these elements are useful, but not indispensable part of the
object model. The three minor elements are −

 Typing

 Concurrency

 Persistence

Abstraction
Abstraction means to focus on the essential features of an element or object in OOP, ignoring its
extraneous or accidental properties. The essential features are relative to the context in which the object is
being used.

Grady Booch has defined abstraction as follows −

“An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of
objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.”

Example − When a class Student is designed, the attributes enrolment number, name, course, and address
are included while characteristics like pulse rate and size of shoe are eliminated, since they are irrelevant
in the perspective of the educational institution.

1
Encapsulation
Encapsulation is the process of binding both attributes and methods together within a class. Through
encapsulation, the internal details of a class can be hidden from outside. The class has methods that
provide user interfaces by which the services provided by the class may be used.

Modularity
Modularity is the process of decomposing a problem (program) into a set of modules so as to reduce the
overall complexity of the problem. Booch has defined modularity as −

“Modularity is the property of a system that has been decomposed into a set of cohesive and loosely
coupled modules.”

Modularity is intrinsically linked with encapsulation. Modularity can be visualized as a way of mapping
encapsulated abstractions into real, physical modules having high cohesion within the modules and their
inter–module interaction or coupling is low.

Hierarchy
In Grady Brooch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through hierarchy, a
system can be made up of interrelated subsystems, which can have their own subsystems and so on until
the smallest level components are reached. It uses the principle of “divide and conquer”. Hierarchy allows
code reusability.

The two types of hierarchies in OOA are −

 “IS–A” hierarchy − It defines the hierarchical relationship in inheritance, whereby from a super-
class, a number of subclasses may be derived which may again have subclasses and so on. For
example, if we derive a class Rose from a class Flower, we can say that a rose “is–a” flower.

 “PART–OF” hierarchy − It defines the hierarchical relationship in aggregation by which a class

may be composed of other classes. For example, a flower is composed of sepals, petals, stamens,
and carpel. It can be said that a petal is a “part–of” flower.

Typing
 According to the theories of abstract data type, a type is a characterization of a set of
elements. In OOP, a class is visualized as a type having properties distinct from any other
types. Typing is the enforcement of the notion that an object is an instance of a single
class or type. It also enforces that objects of different types may not be generally
interchanged; and can be interchanged only in a very restricted manner if absolutely
required to do so.
The two types of typing are −

2
  Strong Typing − Here, the operation on an object is checked at the time of compilation,
as in the programming language Eiffel.
 Weak Typing − Here, messages may be sent to any class. The operation is checked only
at the time of execution, as in the programming language Smalltalk.

Concurrency

Concurrency in operating systems allows performing multiple tasks or processes simultaneously.

When a single process exists in a system, it is said that there is a single thread of control.
However, most systems have multiple threads, some active, some waiting for CPU, some
suspended, and some terminated. Systems with multiple CPUs inherently permit concurrent
threads of control; but systems running on a single CPU use appropriate algorithms to give
equitable CPU time to the threads so as to enable concurrency.
In an object-oriented environment, there are active and inactive objects. The active objects have
independent threads of control that can execute concurrently with threads of other objects. The
active objects synchronize with one another as well as with purely sequential objects.

Persistence

 An object occupies a memory space and exists for a particular period of time. In
traditional programming, the lifespan of an object was typically the lifespan of the
execution of the program that created it. In files or databases, the object lifespan is longer
than the duration of the process creating the object. This property by which an object
continues to exist even after its creator ceases to exist is known as persistence.

Dynamic Modeling 1 mark

The dynamic model represents the time–dependent aspects of a system. It is concerned
with the temporal changes in the states of the objects in a system. The main concepts are
−  State, which is the situation at a particular condition during the lifetime of an object.
 Transition, a change in the state
 Event, an occurrence that triggers transitions
 Action, an uninterrupted and atomic computation that occurs due to some event, and
 Concurrency of transitions.
A state machine models the behavior of an object as it passes through a number of states
in its lifetime due to some events as well as the actions occurring due to the events. A
state machine is graphically represented through a state transition diagram.

Client Server computing (10 marks)

In client server computing, the client requests a resource and the server provides that
resource. A server may serve multiple clients at the same time while a client is in contact
with only one server. Both the client and server usually communicate via a computer
network but sometimes they may reside in the same system.
An illustration of the client server system is given as follows −
Characteristics of Client Server Computing
3
 The salient points for client server computing are as follows:
 The client server computing works with a system of request and response. The client
sends a request to the server and the server responds with the desired information.
 The client and server should follow a common communication protocol so they can
easily interact with each other. All the communication protocols are available at the
application layer.
 A server can only accommodate a limited number of client requests at a time. So it uses a
system based to priority to respond to the requests.
 Denial of Service attacks hindera servers ability to respond to authentic client requests by
inundating it with false requests.
 An example of a client server computing system is a web server. It returns the web pages
to the clients that requested them.
Next generation:
software technology is in the midst of a major computational shift towards distributed
object computing DOC. Distributed computing is poised for a second client-server
revolution, a transition from first generation client-server era to the next generation
client-server era. In this new client-server model, servers are plentiful instead of
scarce(because every client can be a server) and proximity no longer matters. This
immensely expanded client-server model is made possible by the recent exponential
network growth and the progress in network-aware multithreaded desktop operating
systems.

In the first generation client-server era, which still is very much in progress, SQL
databases, transaction processing (TP) monitors, and groupware have begun to dispatch
file servers as client-server application models. In the new client-server era, DOC is
expected to dominate other client-server application models.

Distributed object computing promises the most flexible client-server systems, because it
utilizes reusable software components that can roam anywhere on networks, run on
different platforms, communicate with legacy applications by means of object wrappers
and manage themselves and the resources they control. Objects can break monolithic
applications into more manageable components that coexist on the expanded bus.

Distributed objects are reusable software components that can be distributed and accessed
by the user across the network. These objects can be assembled into distributed
applications. DOC introduces a higher level of abstraction into the distributed
applications.

Distributed Objects Computing will be a key part of tomorrow’s information systems.

Distributed object technology has been tied to standards from the early stage. Since 1989,
the Object Management Group(OMG), with over 500 member companies, has been
specifying the architecture for an open software bus on which object components written

4
 by different vendors can operate across networks and operating systems. The OMG and
the object bus are well on their way to becoming the universal client-server middleware.

There are two kinds of object models: dynamic and static ( 5 MARK)
. Dynamic models, such as UML interaction diagrams (sequence diagrams or communication
diagrams), help design the logic, the behavior of the code or the method bodies. They tend to be the
more interesting, difficult, important diagrams to create. Static models, such as UML class diagrams,
help design the definition of packages, class names, attributes, and method signatures (but not
method bodies).
Static and dynamic UML diagrams for object modeling

There's a relationship between static and dynamic modeling and the agile modeling practice of create
models in parallel: Spend a short period of time on interaction diagrams (dynamics), then switch to a
wall of related class diagrams (statics).
Dynamic Object Modeling

5
People new to UML tend to think that the important diagram is the static - view class diagram, but in
fact, most of the challenging, interesting, useful design work happens while drawing the UML
dynamic - view interaction diagrams. It's during dynamic object modeling (such as drawing sequence
diagrams) that "the rubber hits the road" in terms of really thinking through the exact details of what
objects need to exist and how they collaborate via messages and methods. Therefore, this book starts
by introducing dynamic object modeling with interaction diagrams.

Note that it's especially during dynamic modeling that we apply responsibility - driven designand
the GRASP principles. The subsequent chapters focus on these key topics of the book - and key skills
in 00 design.
Static Object Modeling
The most common static object modeling is with UML class diagrams. After first covering dynamic
modeling with interaction diagrams, I introduce the details.

Note, though, that if the developers are applying the agile modeling practice of Create several
models in parallel, they will be drawing both interaction and class diagrams concurrently.
The Importance of Object Design Skill over UML Notation Skill

The following chapters explore detailed object design while applying UML diagrams. It's been said
before, but is important to stress: What's important is knowing how to think and design in objects,
and apply object design best - practice patterns, which is a very different and much more valuable
skill than knowing UML notation.

While drawing a UML object diagram, we need to answer key questions: What are the
responsibilities of the object? Who does it collaborate with? What design patterns should be applied?
Far more important than knowing the difference between UML 1.4 and 2.0 notation! Therefore, the
emphasis of the following chapters is on these principles and patterns in object design.

Object Design Skill vs. UML Notation Skill

Drawing UML is a reflection of making decisions about the design.

6
 The object design skills are what matter, not knowing how to draw UML. Fundamental object design
requires knowledge of:
 principles of responsibility assignment
 design patterns
PROTYPING: 5 AMRK
• A Prototype enables you to fully understand how easy or difficult it will be to implement
some of the features of the system.
• It can also give users a chance to comment on the usability and usefulness of the design.
• Types of Prototype are :
– A horizontal prototype is a simulation of the interface. (i.e UI)
– A vertical prototype is a subset of the system features with complete
functionality.
• An analysis prototype is an aid for exploring the problem domain. Proof of a concept but
its code not used in real implementation.
• A domain prototype is an aid for the incremental development of the ultimate software.
Can be evolved into a deliverable product.
• Finally a threefold review can be done.
O-O SYSTEMS DEVELOPMENT:A USE CASE DRIVEN APPROACH ( 5 mark)
 The O-O software development life cycle (SDLC) consists of three macro processes:
– Object-Oriented Analysis
– Object-Oriented Design
– Object-Oriented Implementation
The use case model can be employed throughout most activities

One can produce designs that are traceable across :

7
 – Requirements

– Analysis

– Design

– Implementation &

– Testing

(Shown by Life Cycle Model of Jacobson, Ericsson and Jacobson in next slide..)

Advantages of OOSD-By use case are:

– All design decisions can be traced back directly to user requirements.

– Usage scenarios can become test scenarios.

– Views problem as a system of cooperating objects.

– Advocates incremental development.

– Helps in identifying objects.

8
 Object Oriented Analysis – Use Case Driven:

• O-O Analysis concerns with determining the system requirements and identifying classes
and their relationships to other classes in the problem domain.

• Use case & Scenarios

• Use case modeling

• Documentation (80:20 Rule can be applied)

• 80:20 Rule: 80% of the work can be done with 20% of the documentation

( 5 mark)

9
10
11
Class Responsibility Collaborator Cards ( 5 marks)
 A CRC card (Beck & Cunningham, 1989; Ambler, 1995) is a standard index card that has
been divided into three sections, as shown below in Figure 1. Class Name
Responsibilities Collaborators Figure 1. CRC card layout.
 A class represents a collection of similar objects. An object is a person, place, thing,
event, concept, screen, or report that is relevant to the system at hand. For example,
Figure 2 shows a shipping/inventory control system with the classes such as Inventory
Item, Order, Order Item, Customer, and Surface Address.
 The name of the class appears across the top of the card. A responsibility is anything that
a class knows or does. For example, customers have names, customer numbers, and
phone numbers. These are the things that a customer knows. Customers also order
products, cancel orders, and make payments.
 These are the things that a customer does. The things that a class knows and does
constitute its responsibilities. Responsibilities are shown on the left hand column of a
CRC card. Sometimes a class will have a responsibility to fulfill, but will not have
enough information to do it. When this happens it has to collaborate with other classes to
get the job done. For example, an Order object has the responsibility to calculate it’s
total. Although it knows about the Order Item objects that are a part of the order, it
doesn’t know how many items were ordered (Order Item knows this) nor does it know
the price of the item (Inventory Item knows this).
 To calculate the order total, the Order object collaborates with each Order Item object to
calculate its own total, and then adds up all the totals to calculate the overall total. For
each Order Item to calculate its individual total, it has to collaborate with Inventory Item
to determine the cost of the ordered item, multiplying it by the number ordered (which it
does know). The collaborators of a class are shown in the right-hand column of a CRC
card.
Finding Classes
 · Look for anything that interacts with the system, or is part of the system
 · Ask yourself “Is there a customer?”
 · Follow the money
 · Look for reports generated by the system
 · Look for any screens used in the system
 · Immediately prototype interface and report classes
 · Look for the three to five main classes right away
 · Create a new card for a class immediately
 · Use one or two words to describe the class
 · Class names are singular
12
 Finding Responsibilities
 · Ask yourself what the class knows
 · Ask yourself what the class does
 · If you’ve identified a responsibility, ask yourself what class it "belongs" to
 · Sometimes get responsibilities that we won’t implement, and that’s OK
 · Classes will collaborate to fulfill many of their responsibilities
Defining Collaborators
 · Collaboration occurs when a class needs information that it doesn’t have
 · Collaboration occurs when a class needs to modify information that it doesn’t have
 · There will always be at least one initiator of any given collaboration
 · Sometimes the collaborator does the bulk of the work
 · Don’t pass the buck
 · New responsibilities may be created to fulfill the collaboration

Effective documentation: ( 5 mark)

1. Have clear objectives and specification of what you want the project to deliver

 A customer should play a major part in developing a User Requirement Specification

(URS). This will clearly outline the needs of the project and their expectations. This is
vital to getting the project off on the right foot and can help avoid misunderstandings
between customer and contractor later down the line.
 From the URS the contractor can then develop the Functional Design Specification
(FDS). This document is a statement of exactly what the contractor is going to do. Once
agreed it becomes the cornerstone for the entire project.

2. Documentation check

Initial drafts of documentation almost inevitably contain inaccuracies and omissions. Take time
and care to get the documents correct to save significant cost and delays later on.

However, with early drafts of documents, it’s easy to get sidetracked into issues around grammar
and spelling while the priority should be to ensure the content is correct. Of course, all final
documents should have the I’s dotted and the T’s crossed but this can be dealt with as a final
step.

3. Make sure you are working to current standards and legislation

Standards Change. Sometimes, a reference to outdated information can result in new

documentation that is unnecessary, inappropriate – or even both!

Remember, it’s important that documentation meets the requirements of current rules but treat it
as a baseline. Ultimately, if you want your documentation to be worth more than the paper it’s
13
written on, it needs to be as effective as possible, covering every aspect of your particular
project.

4. Developing effective documentation is an evolutionary process

It’s common for requirements to evolve as a project progresses. A clear and comprehensive FDS
is important as it provides a framework for the developments that inevitably happen. A good
FDS that anticipates change can help the project adapt and integrate amendments rather than
stalling the process, or throwing it into chaos.

It’s good to talk. Consulting with third-party contractors from an early stage of a project can
bring insight which proves extremely valuable in avoiding future problems both large and small.

5. The documentation process is collaborative.

 Customer input is vital. Every project is a collaboration between the customer, who
knows what they are trying to achieve, and the contractor/contractors who have the
knowledge and experience to design and deliver a workable solution.
 Ultimately, if you want the best project, ensure you have good documentation. It’s the
foundation for delivering efficient and effective products and systems.

Booch Methodology ( 5 mark)

Booth's methodology focuses on object-oriented analysis and design and consists of five
activities: conceptualization, analysis, design, evolution, and maintainance. The method is
cyclical and accounts for incremental improvements that are made in the evolution of a product.

Note: Clouds are used to define classes.

Macro process:

 Conceptualization: Establish requirements taking into account the perspective of the

customer

 Analysis: Develop a model by defining object classes, their attributes, methods, and

inheritance. Include associations, the dynamic part of a model.

 Design: Develop a structure/architecture where logical and physical details are discussed

 Evolution: As it relates to the implementation

 Maintenance: Maintenance following the delivery of the product

14
Micro process

 Identify classes and objects

 Identify semantics as it relates to programming

 Identify interactions/relationships

 Note abstraction as it relates to interfaces and their implementation

The macro process is the general cycle that follows in Booch's method, the micro process
emerges during the development or implementation of new features (classes, behaviors, etc.)

Note: The methodology details six different models/diagrams: class diagrams, state
transition diagrams, object diagrams, process diagrams, module diagrams, and interaction
diagrams. Class and module diagrams are static while state transition diagrams are
dynamic.

Example

Below is a diagram illustrating a booch diagram as it relates to the types of bank accounts. We
have a superclass Bank Account and we've listed its attributes below. As you can see, our classes
Saving Account and Checking’s Account inherit the superclass.

15
Difference between RDBMS and OODBMS (5 mark)

RDBMS: 
RDBMS stands for Relational Database Management System. It is a database management
system based on the relational model i.e. the data and relationships are represented by a
collection of inter-related tables. It is a DBMS that enables the user to create, update, administer
and interact with a relational database. RDBMS is the basis for SQL, and for all modern database
systems like MS SQL Server, IBM DB2, Oracle, MySQL, and Microsoft Access. 

OODBMS: 
OODBMS stands for Object-Oriented Database Management System. It is a DBMS where data
is represented in the form of objects, as used in object-oriented programming. OODB
implements object-oriented concepts such as classes of objects, object identity, polymorphism,
encapsulation, and inheritance. An object-oriented database stores complex data as compared to
relational database. Some examples of OODBMS are Versant Object Database, Objectivity/DB,
ObjectStore, Caché and ZODB. 

Difference Between RDBMS and OODBMS:  

BASIS RDBMS OODBMS

Stands for Relational Database Stands for Object Oriented Database

Long Form Management System. Management System.

Stores data in Entities, defined

Way of as tables hold specific
storing data information. Stores data as Objects.

Data Handles comparatively simpler Handles larger and complex data than
Complexity data. RDBMS.

Entity type refers to the Class describes a group of objects that

collection of entity that share a have common relationships, behaviors,
Grouping common definition. and also have similar properties.

16
 BASIS RDBMS OODBMS

Data
Handling RDBMS stores only data. Stores data as well as methods to use it.

Main Data Independence from

Objective application program. Data Encapsulation.

An object identifier (OID) is an

A Primary key distinctively unambiguous, long-term name for any
Key identifies an object in a table.. type of object or entity.

Rumbaughet . al.’s Object Modeling Technique (OMT) ( 5 amrk):

 OMT describes a method for the analysis, design, and implementation of a system using
an object-oriented technique.
 Class, attributes, methods, inheritance, and association also can be expressed easily The
dynamic behavior of objects within a system can be described using OMT

Dynamic model

 Process description and consumer-producer relationships can expressed using

OMT’s Functional model

 OMT consists of four phases, which can be performed iteratively:

1. Analysis. The results are objects and dynamic and functional models.

2. System design. The result is a structure of the basic architecture of the system.

3. Object design. This phase produces a design document, consisting of detailed

objects and dynamic and functional models.

4. Implementation. This activity produces reusable, extendible, and robust code.

17
OMT separates modeling into three different parts:

1. An object model, presented by the object model and the data dictionary.

2. A dynamic model, presented by the state diagrams and event flow diagrams.

3. A functional model, presented by data flow and constraints.

OMT Object Model

The object model describes the structure of objects in a system:

 Their identity , relationships to other objects, attributes, and operations
 The object model is represented graphically with an object diagram

The object diagram contains classes interconnected by association lines

Example of an object model (DIAGRAM) See in google

 The above example provides OMT object model of a bank system. The boxes represent
classes and the filled triangle represents specialization.  Association between Account
and Transaction is one-to-many. Since one account can have many transactions, the filled
circle represents many (zero or more).
 The relationship between Client and Account classes is one-to-one. A client can have
only one account and account can belong to only one person (in this model joint
accounts are not considered )
The OMT Dynamic Model:
(DIAGRAM) See in Google
• OMT provides a detailed and comprehensive dynamic model
• The OMT state transition diagram is a network of states and events.
 each state receives one or more events, at which it makes the transition to the next
state.
 The next state depends on the current state as well as the events.
 State transition diagrams for the bank application user interface.
 Round boxes represents states
 Arrows represents transitions

The OMT Functional Model

• The OMT data flow diagram (DFD) shows the flow of data between different processing in a
business.

• Data Flow Diagrams use four primary symbols:

◦ The process is any function being performed

18
◦ The data flow shows the direction of data element movement

◦ The data store is a location where data are stored.

◦ An external entity is a source or destination of a data element.

QUALITY ASSURANCE TESTS: -( 5 MARKS)

• Debugging is a process of finding out where something went wrong and correcting the code to
eliminate the errors or bugs that cause unexpected results.

 A software debugging system can provide tools for finding errors in programs and
correcting them.

• Kinds of errors: In general, software has three types of errors such as below

1) Language (syntax) errors are result of incorrectly constructed code, such as an incorrectly
typed keyword or punctuations. They are easiest error to be detected on simple running system

2) Run–time errors are detected on running, when a statement attempts an operation that is
impossible to carry out. Eg.: if program tries to access a non-exist file or object, it occurs

3) Logic errors occur when expected output is not formed. They can detected only by testing the
code and analyzing the results performed by intended codes

• The elimination of syntactical bug is the process of debugging, whereas detection and
elimination of logical bug is the process of testing. Quality assurance testing can be divided into
two major categories: error–based testing and scenario–based testing

• Error–based testing techniques search a given class’s method for particular clues of interests,
then describe how these clues should be tested. E.g: Boundary condition testing

• Scenario–based testing also called usage–based testing, concentrates on capturing use–cases.

Then it traces user’s task, performing them with their variants as tests. It can identify interaction
bugs. These are more complex tests tend to exercise multiple subsystems in a single test covering
higher visibility system interaction bugs

• S/w testing is one element of a broader topic that is often referred to as verification and
validation (V&V). Verification refers to set of activities that ensure that software correctly
implements a specific function. Validation refers to different set of activities that ensure that s/w
that hs been built is traceable to customer requirements

Guidelines for developing Quality Assurance Test Cases:

19
  Freedman & Thomas have developed guidelines that have been adapted for the Unified
Approach
 Describe which feature or service (external of internal), test attempts to cover
 If test case is based on use case it must refer to use–case name and write test plan for that
piece
 Specify what to test on which method along with test feature and expected action
 Test normal use of the object’s methods
 Test abnormal but reasonable use of the object’s methods
 Test abnormal and unreasonable use of object’s methods
 Test boundary conditions of number of parameters or input set of objects
 Test object’s interactions & message sent among them with assist of sequence diagram
 On doing revision, document the cases so they become the starting basis for follow–up
test
 Attempt to reach agreement on answers of what–if questions and repeat process until
stabilized
 The internal quality of s/w such as its reusability and extendibility should be assessed as
well

Testing Strategies: - ( 10 MARKS)

• The objective of s/w testing is to uncover errors. The various testing strategies constitutes –

◦ Unit Testing – Black Box testing, White black testing

◦ Integration Testing – Top–down testing, Bottom–up testing, Regression testing

◦ Validation Testing – Alpha test, Beta test and

◦ System Testing – Recovery testing, Security testing, Stress testing, Performance testing o
TomGilb argues following issues for successful s/w testing strategy is to be implemented:

1) Specify product requirements in a quantifiable manner long before testing commences

2) State testing objectives explicitly

3) Understand the users of s/w and develop a profile for each user category

4) Develop a testing plan that emphasizes “rapid cycle testing”

5) Build “robust” s/w that is designed to test itself

6) Use effective formal technical reviews as a filter prior to testing

7) Conduct formal technical reviews to assess the test strategy and test cases themselves

8) Develop a continuous improvement approach for testing process

20
• tests concentrate on functional verification of a module and

• Modules into a program structure. Validation testing demonstrates traceability to s/w

requirements and system testing validates s/w once it has been incorporated into a larger system

1) Unit test focuses verification effort on smallest unit of s/w design the module. It constitutes
two inner types of testing – White box testing and Black box testing

 Black box testing: The concept of black box is used to represent a system that’s inside
working are
 not available for inspection. In black box testing, we try various inputs and examine
resulting output though which we learn what the box does nor how conversion takes
place
 White box testing: White box testing assumes that specific logic important and must be
tested to guarantee system’s proper functioning. One form of white box testing called
path testing, makes certain that each path in a object’s method is executed at least once
during testing & is of types

1) Statement testing coverage: Its aim is to test every statement in object’s method at least once

2) Branch testing coverage: Idea is to perform enough tests ensuring all branches are perfect

 Integration Testing: It is a systematic technique for constructing the program structure

while conducting tests to uncover errors associated with interfacing. The object is to take
unit tested modules and build a program structure that has been dictated by design. It has
again 3 testing patterns: Top–down testing, Bottom – up testing and regression testing

• Top–down testing: It assumes that main logic or object interactions and system messages of
application need more testing than an individual object’s method or supporting logic. This
strategy can detect serious flaws early in implementation

• Bottom–Up testing: It starts with details of system and proceeds to higher levels by a
progressive aggregation of details until they collectively fit requirements for system

i.e., start with methods and classes then to level up. It makes sense as it checks behavior of piece
of code before it is used

• Regression testing: It is activity that helps ensure that changes (due to testing or other reasons)
do not introduce unintended behavior or additional errors. The regression test suite contain three
different classes of test cases:

◦ A representative sample of tests that will exercise all s/w functions

◦ Additional tests that focus on s/w functions that are likely to be affected by change

21
◦ Tests that focus on s/w components that have been changed

• Validation Testing: After integration testing, s/w is completely assembled as a package:

interfacing errors have been uncovered and corrected and final series of s/w tests – validating
testing – begins. It is nothing but continuous execution on s/w by number of times & users. It is
again implemented either by one of two methods: Alpha testing or Beta testing

• Alpha test is conducted in controlled environment at developer’s site by a customer.

The s/w is used in setting with developer “looking over shoulder” of user, recording errors &
usage problems

• Beta test is conducted at one or more customer sites by end user(s) of the s/w. Its live
application of s/w where customer records all problems that are encountered during beta testing
and reports

• System Testing: It is a series of different tests whose primary purpose is to fully exercise the
computer – based system. Although each test has a different purpose, all work to verify that all
system elements have been properly integrated and perform allocated functions. The different
tests in series are Recovery, security, stress and performance testing

• Recovery testing is a system test that forces s/w to fail in a variety of ways and verifies that
recovery is properly performed. If recovery is automatic, re – initialization, checkpoint
mechanisms, data recovery and restart are each evaluated for correctness

• Security testing attempts to verify that protection mechanisms built into a system will in fact
protect it from improper penetration. During this test, tester plays the role(s) of individual who
desires to penetrate system. The role of system designer is to make penetration cost greater than
value of information that will be obtained

• Stress testing executes a system in a manner that demands resources in abnormal quantity,
frequency or volume. A variation of stress testing is a technique called sensitivity testing. In
some situations, a very small range of data contained within the bunds of valid data for a
programs may cause extreme and even erroneous processing or profound performance
degradation

• Performance testing is designed to test run –time performance of s/w within context of an
integrated system. It occurs throughout all steps in testing process. Performance tests are often
coupled with stress testing and often require both h/w and s/w instrumentation.

An automated teller machine (ATM) ( 10 marks)

 the automatic banking machine (ABM) is a banking subsystem (subject) that provides bank
customers with access to financial transactions in a public space without the need for a cashier,
clerk, or bank teller.

22
Customer (actor) uses bank ATM to Check Balances of his/her bank accounts, Deposit Funds, Withdraw
Cash and/or Transfer Funds (use cases). ATM Technician provides Maintenance and Repairs. All these
use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.

An example of use case diagram for Bank ATM subsystem - top level use cases.
On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and entering a
personal identification number (PIN). Customer Authentication use case is required for every ATM
transaction so we show it as include relationship. Including this use case as well as
transaction generalizations make the ATM Transaction an abstract use case.

23
Bank ATM Transactions and Customer Authentication Use Cases Example.
Customer may need some help from the ATM. ATM Transaction use case is extended via extension
point called menu by the ATM Help use case whenever ATM Transaction is at the location specified by
the menu and the bank customer requests help, e.g. by selecting Help menu item.

Bank ATM Maintenance, Repair, Diagnostics Use Cases Example.

ATM Technician maintains or repairs Bank ATM. Maintenance use case includes Replenishing ATM
with cash, ink or printer paper, Upgrades of hardware, firmware or software, and remote or on-
site Diagnostics. Diagnostics is also included in (shared with) Repair use case.

Prototype Model (5 mark)

24
The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance as
compared to actual software. In many instances, the client only has a general view of what is
expected from the software product. In such a scenario where there is an absence of detailed
information regarding the input to the system, the processing needs, and the output requirement,
the prototyping model may be employed.

Steps of Prototype Model

1. Requirement Gathering and Analyst

25
 2. Quick Decision

3. Build a Prototype

4. Assessment or User Evaluation

5. Prototype Refinement

6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted

3. Regular visible process aids management

4. Support early product marketing

5. Reduce Maintenance cost.

6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration

o Costs customer money

o Needs committed customer

o Difficult to finish if customer withdraw

o May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.

5. Prototyping tools are expensive.

6. Special tools & techniques are required to build a prototype.

7. It is a time-consuming process.

26
 Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement model. The same phases are
defined for the waterfall model occurs here in a cyclical fashion. This model differs from the
iterative enhancement model in the sense that this does not require a useful product at the end of
each cycle. In evolutionary development, requirements are implemented by category rather than
by priority.

For example, in a simple database application, one cycle might implement the graphical user
Interface (GUI), another file manipulation, another queries and another updates. All four cycles
must complete before there is a working product available. GUI allows the users to interact with
the system, file manipulation allow the data to be saved and retrieved, queries allow user to get
out of the system, and updates allows users to put data into the system.

What is a use case diagram (5 mark)

In the Unified Modeling Language (UML), a use case diagram can summarize the details of your
system's users (also known as actors) and their interactions with the system. To build one, you'll
use a set of specialized symbols and connectors. An effective use case diagram can help your
team discuss and represent:

 Scenarios in which your system or application interacts with people, organizations, or external
systems

 Goals that your system or application helps those entities (known as actors) achieve

 The scope of your system

When to apply use case diagrams

A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order
in which steps are performed. Instead, a proper use case diagram depicts a high-level overview
of the relationship between use cases, actors, and systems. Experts recommend that use case
diagrams be used to supplement a more descriptive textual use case.

UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented
with a labeled oval shape. Stick figures represent actors in the process, and the actor's
participation in the system is modeled with a line between the actor and use case. To depict the
system boundary, draw a box around the use case itself.

UML use case diagrams are ideal for:

27
 Representing the goals of system-user interactions

 Defining and organizing functional requirements in a system

 Specifying the context and requirements of a system

 Modeling the basic flow of events in a use cas

Diagramming is quick and easy with Lucid chart. Start a free trial today to start creating and
collaborating.

Use case diagram components

To answer the question, "What is a use case diagram?" you need to first understand its building
blocks. Common components include:

28
 Actors: The users that interact with a system. An actor can be a person, an organization, or an
outside system that interacts with your application or system. They must be external objects
that produce or consume data.

 System: A specific sequence of actions and interactions between actors and the system. A
system may also be referred to as a scenario.

 Goals: The end result of most use cases. A successful diagram should describe the activities
and variants used to reach the goal.

Use case diagram symbols and notation

The notation for a use case diagram is pretty straightforward and doesn't
involve as many types of symbols as other UML diagrams. You can use this
guide to learn how to draw a use case diagram if you need a refresher. Here
are all the shapes you will be able to find in Lucidchart:
29
 Use cases: Horizontally shaped ovals that represent the different uses that a
user might have.
 Actors: Stick figures that represent the people actually employing the use
cases.
 Associations: A line between actors and use cases. In complex diagrams, it
is important to know which actors are associated with which use cases.
 System boundary boxes: A box that sets a system scope to use cases. All
use cases outside the box would be considered outside the scope of that
system. For example, Psycho Killer is outside the scope of occupations in
the chainsaw example found below.
 Packages: A UML shape that allows you to put different elements into
groups. Just as with component diagrams, these groupings are represented
as file folders.
Patterns templates ( 5 marks)

◦ Name:-

 A meaningful name allows us to use a single word or short phrase to refer to the pattern
and the knowledge and structure it describes.
 Some pattern forms also provide a classification of the pattern in addition to its name.

◦ Problem:-

 A statement of the problem that describes its intent: the goals and objectives it wants to
reach within the given context and forces.
 The forces oppose these objectives as well as each other.

◦ Context:-

 The preconditions under which the problem and its solution seem to recur and for which
the solution is desirable.
 It can be thought of as the initial configuration of the system before the pattern is applied
to it.

◦ Forces:-

 A description of the relevant forces and constraints and how they interact or with one
another and with the goals that the user wish to achieve.

30
  A concrete scenario that serves as the motivation for the pattern frequently is employed.

◦ Solution:-

 Static relationships and dynamic rules describing how to realize the desired outcome.
 It describes how to construct the necessary products.
 It encompasses the pictures, diagrams and prose that identify the pattern structure, and
their participants and collaborations to show how the problem is solved.

◦ Examples:-

 One or more sample applications of the pattern that illustrate a specific initial context;
how the pattern is applied to and transforms that context.

◦ Resulting context:-

 The state or configuration of the system after the pattern has been applied, including the
consequences of applying the pattern and other problems and patterns that may arise
from the new context.
◦ Rationale:-
 Steps or rules in the pattern and also of the pattern as a whole in terms of how and why it
resolves it forces in a particular way to be in alignment with desired goals.

• Related patterns:-

◦ The static and dynamic relationships between this pattern and others within the same pattern
language or system.

◦ Related pattern often share common forces.

◦ They also frequently have an initial or resulting context that is compatible with the resulting or
initial context of another pattern.

• Known uses:-

◦ The known occurrences of the pattern and its application within existing systems.

This helps to validate a pattern by verifying that it indeed is a proven solution to the recurring
problem.

FRAMEWORKS:

 Frameworks are a way of delivering application development patterns to support best

practice sharing during application development .

31
  A frame work is a way of presenting a generic solution to a problem that can be applied
to all levels in a development. Several design patterns in fact a framework can be viewed
as the implementation of a system of design patterns.

The major differences between design patterns and frameworks as follows

• Design patterns are more abstract than frameworks.

• Design patterns are smaller architectural elements than frameworks.

• Design patterns are less specialized than frameworks.

Association ( 5 mark)
 Association is a group of links having common structure and common behavior.
Association depicts the relationship between objects of one or more classes. A link can be
defined as an instance of an association.

Degree of an Association

Degree of an association denotes the number of classes involved in a connection. Degree may be
unary, binary, or ternary.

 A unary relationship connects objects of the same class.

 A binary relationship connects objects of two classes.

 A ternary relationship connects objects of three or more classes.

Cardinality Ratios of Associations

32
Cardinality of a binary association denotes the number of instances participating in an
association. There are three types of cardinality ratios, namely −

 One–to–One − A single object of class A is associated with a single object of class B.

 One–to–Many − A single object of class A is associated with many objects of class B.

 Many–to–Many − An object of class A may be associated with many objects of class B

and conversely an object of class B may be associated with many objects of class A.

Aggregation or Composition

Aggregation or composition is a relationship among classes by which a class can be made up of

any combination of objects of other classes. It allows objects to be placed directly within the
body of other classes. Aggregation is referred as a “part–of” or “has–a” relationship, with the
ability to navigate from the whole to its parts. An aggregate object is an object that is composed
of one or more other objects.

Example

In the relationship, “a car has–a motor”, car is the whole object or the aggregate, and the motor is
a “part–of” the car. Aggregation may denote −

 Physical containment − Example, a computer is composed of monitor, CPU, mouse,

keyboard, and so on.

 Conceptual containment − Example, shareholder has–a share.

Benefits of Object Model

Now that we have gone through the core concepts pertaining to object orientation, it would be
worthwhile to note the advantages that this model has to offer.

The benefits of using the object model are −

 It helps in faster development of software.

 It is easy to maintain. Suppose a module develops an error, then a programmer can fix
that particular module, while the other parts of the software are still up and running.

 It supports relatively hassle-free upgrades.

 It enables reuse of objects, designs, and functions.

 It reduces development risks, particularly in integration of complex systems.

33
DESIGN PATTERN ( 5 MARK):
Design patterns represent the best practices used by experienced object-oriented
software developers. Design patterns are solutions to general problems that software
developers faced during software development. These solutions were obtained by trial
and error by numerous software developers over quite a substantial period of time.

What is Gang of Four (GOF)?

In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides
published a book titled Design Patterns - Elements of Reusable Object-Oriented
Software which initiated the concept of Design Pattern in Software development.
These authors are collectively known as Gang of Four (GOF). According to these
authors design patterns are primarily based on the following principles of object
orientated design.
 Program to an interface not an implementation
 Favor object composition over inheritance

Usage of Design Pattern

Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular scenario.
For example, a singleton design pattern signifies use of single object so all developers
familiar with single design pattern will make use of single object and they can tell each
other that program is following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best
solutions to certain problems faced during software development. Learning these
patterns helps un-experienced developers to learn software design in an easy and
faster way.

Types of Design Pattern

As per the design pattern reference book Design Patterns - Elements of Reusable
Object-Oriented Software , there are 23 design patterns. These patterns can be
classified in three categories: Creational, Structural and behavioral patterns. We'll also
discuss another category of design patterns: J2EE design patterns.

S.N. Pattern & Description

34
 Creational Patterns
These design patterns provides way to create objects while hiding the creation logic,
1
rather than instantiating objects directly using new operator. This gives program more
flexibility in deciding which objects need to be created for a given use case.

Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is
2
used to compose interfaces and define ways to compose objects to obtain new
functionalities.

Behavioral Patterns
3
These design patterns are specifically concerned with communication between objects.

J2EE Patterns
4 These design patterns are specifically concerned with the presentation tier. These
patterns are identified by Sun Java Center.

Factory Pattern
Factory pattern is one of the most used design patterns in Java. This type of design
pattern comes under creational pattern as this pattern provides one of the best ways to
create an object.
In Factory pattern, we create object without exposing the creation logic to the client and
refer to newly created object using a common interface.

Implementation
We're going to create a Shape interface and concrete classes implementing
the Shape interface. A factory class Shape Factory is defined as a next step.
Factory PatternDemo, our demo class will use Shape Factory to get a Shape object. It
will pass information (CIRCLE / RECTANGLE / SQUARE) to Shape Factory to get the
type of object it needs.

35
Step 1
Create an interface.
Shape.java
public interface Shape {
void draw();
}

Step 2
Create concrete classes implementing the same interface.
Rectangle.java
public class Rectangle implements Shape {

@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}
UML state chart diagram: ( 10 mark)
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a
system.

A State chart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events.

36
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines the states, it is used to model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are changed
by events. Statechart diagrams are useful to model the reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. The
most important purpose of Statechart diagram is to model lifetime of an object from creation to
termination.

Statechart diagrams are also used for forward and reverse engineering of a system. However, the
main purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams −

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.

 To describe different states of an object during its life time.

 Define a state machine to model the states of an object.

How to Draw a Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. Emphasis is
placed on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately.

Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.

Before drawing a Statechart diagram we should clarify the following points −

 Identify the important objects to be analyzed.

 Identify the states.

 Identify the events.

Following is an example of a Statechart diagram where the state of Order object is analyzed

37
  The first state is an idle state from where the process starts. The next states are arrived for
events like send request, confirm request, and dispatch order. These events are
responsible for the state changes of order object.
 During the life cycle of an object (here order object) it goes through the following states
and there may be some abnormal exits. This abnormal exit may occur due to some
problem in the system. When the entire life cycle is complete, it is considered as a
complete transaction as shown in the following figure. The initial and final state of an
object is also shown in the following figure.

Where to Use Statechart Diagrams?

 From the above discussion, we can define the practical applications of a Statechart
diagram. Statechart diagrams are used to model the dynamic aspect of a system like other
four diagrams discussed in this tutorial. However, it has some distinguishing
characteristics for modeling the dynamic nature.
 Statechart diagram defines the states of a component and these state changes are dynamic
in nature. Its specific purpose is to define the state changes triggered by events. Events
are internal or external factors influencing the system.
 Statechart diagrams are used to model the states and also the events operating on the
system. When implementing a system, it is very important to clarify different states of an
object during its life time and Statechart diagrams are used for this purpose. When these
states and events are identified, they are used to model it and these models are used
during the implementation of the system.

38
If we look into the practical implementation of Statechart diagram, then it is mainly used to
analyze the object states influenced by events. This analysis is helpful to understand the system
behavior during its execution.

The main usage can be described as −

 To model the object states of a system.

 To model the reactive system. Reactive system consists of reactive objects.

 To identify the events responsible for state changes.

 Forward and reverse engineering.

LAYERED APPROACH TO SOFTWARE DEVELOPMENT ( 10 mark)

 Software development strategies vary from business-to-business. Certain factors—like

Stakeholders, end-users, and organizational structure—determine the best approach.

The Solution Group practices a layered software architecture. This means TSG software is built
with distinct layers that each have their own purpose. These layers build on each other to create
the end-product—from foundational data through the final customer-facing layer.

Layered software development has major advantages that matches TSG’s organizational
structure. The approach also lends itself to customizing software based on customer needs. At the
Solutions Group, we practice a four-tier system, which is a common approach to the layered
architecture model. Here are the two different layers we use to build and deploy our software:

Database Layer

39
This is the foundational layer. The database layer includes back-end data that dictates how the
software behaves. The database layer stays untouched and is managed through the layer that sits
on top of it—the data access layer.

Data Access Layer

This layer sits above the database layer and allows for accessing the database layer. Any
alterations or modifications to how a software accesses the data is done through the data access
layer.

Business Layer

This is a layer dedicated to business-specific logs. For example, when developing an application
for a customer who has a lot of software customizations—or business rules—we get data from
the database, apply business rules, and either save it or provide to the presentation layer.

Presentation Layer

This is the layer visible to the customer. While other layers may not be accessible to the
customer or require certain visual standards, it’s important that the presentation layer
accomplishes both functional and visual business goals.

Analogy

Here’s an analogy of how the four layers work. Let’s say you have a question for a local
business, and you’re filling out a Contact Me form on the business’ website. The form has
different drop down options and choices for the business to determine the best way to help you.
The form would be the presentation layer. After you click submit, the person who receives your
inquiry and applies logic to how it should be handled would be considered the business layer.

The business also keeps the raw data of which choices their customers select on the form. The
business uses software to navigate that raw data and compile a report that is easy to read. The
software that creates this report is the data access layer. The raw data is exported and saved on a
hard drive. This raw data can be considered the database layer.

Major Benefits

 Layers of isolation: A recent study published in the O’Reilly Library defines the layers of
isolation approach in detail: “The layers of isolation concept means that changes made in
one layer of the architecture generally don’t impact or affect components in other layers:
the change is isolated to the components within that layer, and possibly another
associated layer (such as a persistence layer containing SQL).” This means the layers
have their own independence and contain their own components.

40
 Acceptance testing. The layered structure makes it easier to perform user acceptance
testing prior to deploying enhancements or bug fixes.

 Ease of development: The layers of isolation approach allows for a smooth, agile
approach to new development.

UML DYNAMIC MODELING (BEHAVIOR DIAGRAMS) ( 10 mark)

 Booch explains that describing a systematic event in a static medium such as on asheet
of paper is difficult, but the problem confronts almost every discipline.
 The Dynamic semantics of a problem with the following diagrams:
Behavior diagrams (Dynamic)
 Interaction Diagrams:
 Sequence diagrams
 Collaboration diagrams
 State Chart diagrams
 Activity diagrams
 Each class may have an associated activity diagram that indicates the behavior of the
class's instance (its object). In conjunction with the use-case model, we may provide a
scripts or an interaction diagram to show the time or event ordering of messages as they
are evaluated.
UML INTERACTION DIAGRAMS
 Interaction diagrams are diagrams that describe how groups of objects collaborate to get
the job done. Interaction diagrams capture the behavior of a single use case, showing the
pattern of interaction among objects. The diagram shows a number of example objects
and the messages passed between those objects within the use case. There are two kinds
of interaction models: sequence diagrams and collaboration diagrams.
UML Sequence Diagram:
 Sequence diagrams are an easy and intuitive way of describing the behavior of a system
by viewing the interaction between the system and its environment. A sequence diagram
shows an interaction arranged in a time sequence.
 It shows the objects participating in the interaction by their lifelines and the messages
they exchange, arranged in a time sequence.
 A sequence diagram has two dimensions: the vertical dimension represents time, the
horizontal dimension represents different objects. The vertical line is called the object's
lifeline. The lifeline represents the object's existence during the interaction. This form
was first popularized by Jacobson.
 An object is shown as a box at the top of a dashed vertical line (see Fig 27). A role is a
slot for an object within a collaboration that describes the type ofobject that may play the
role and its relationships to other roles. a sequence diagram does not show the

41
 relationships among the roles or the association among the objects. An object role is
shown as a vertical dashed line, the lifeline.

 Each message is represented by an arrow between the lifelines of two objects. The order
in which these messages occur is shown top to bottom on the page. Each message is
labeled with the message name.
 The label also can include the argument and some control information and show self-
delegation, a message that an object sends to itself, by sending the message arrow back
to the same lifeline.
 The horizontal ordering of the lifelines is arbitrary. Often, call arrows are arranged to
proceed in one direction across the page, but this is not always possible and the order
conveys no information.

42