Unit-1

What is object-oriented development and theme?

In the object-oriented approach, the focus is on capturing the structure and behavior of
information systems into small modules that combines both data and process. The main aim
of Object Oriented Design (OOD) is to improve the quality and productivity of system analysis
and design by making it more usable.

Object-oriented design includes two main stages, namely, system design and object design.

Advantages of object oriented software development

Some of the advantages of object oriented software development are:

 Less maintenance cost mostly because it is modular.

 Better code reusability due to features such as inheritance and hence faster development.

 Improved code reliability and flexibility

 Easy to understand due to realworld modelling.

 Better abstraction at object level.

 Reduced complexity during the transitions from one development phase to another.

Object-Oriented Design

In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities).
The state is distributed among the objects, and each object handles its state data.

1. Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.

1
 3. Messages: Objects communicate by message passing. Messages consist of the integrity of
the target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information
of an object together but also restricts access to the data and methods from the outside
world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions
from their immediate superclasses.This property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific
ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different types.
Depending upon how the service is invoked, the respective portion of the code gets
executed.

What is UML Relationship?

Relationships in UML are used to represent a connection between structural, behavioral, or
grouping things. It is also called a link that describes how two or more things can relate to each
other during the execution of a system. Type of UML Relationship are Association, Dependency
, Generalization , and Realization.
Types of UML Class Diagram Relationships

2
Association
It is a set of links that connects elements of the UML model. It also defines how many objects are
taking part in that relation.

Dependency
In a dependency relationship, as the name suggests, two or more elements are dependent on each
other. In this kind of a relationship, if we make a change to a particular element, then it is likely
possible that all the other elements will also get affected by the change.

Generalization
It is also called a parent-child relationship. In generalization, one element is a specialization of
another general component. It may be substituted for it. It is mostly used to represent inheritance.

Realization
In a realization relationship of UML, one entity denotes some responsibility which is not
implemented by itself and the other entity that implements them. This relationship is mostly found
in the case of interfaces.

The relationship type between object types in the object model can be either Association (parent-
child) or Reference (non-parent-child).

3
The Association relationship type is the most common relationship. It defines parent and child
relationships between object types in the object hierarchy.

The Reference relationship type is used for non-parent-child relationships. This relationship type
is not traversed when navigating the hierarchy. It is used to avoid loops or cyclic relationships in
the object model.

Association in object oriented programming

Association is a semantically weak relationship (a semantic dependency) between otherwise
unrelated objects. An association is a “using” relationship between two or more objects in which
the objects have their own lifetime and there is no owner.

In UML an association relationship is represented by a single arrow. An association relationship

can be represented as one-to-one, one-to-many, or many-to-many (also known as cardinality).
Essentially, an association relationship between two or more objects denotes a path of
communication (also called a link) between them so that one object can send a message to another.

Aggregation

Aggregation is a specialization of composition. When an outer object aggregates an interface of

an inner object, it doesn’t reimplement the interface – it merely passes the inner object’s interface
pointer directly to the client.

The goal of aggregation is to convince the client that an interface implemented by the inner object
is actually implemented by the outer object – the client should be unaware that there is more than
one object in use.

Containment means the containing object does not directly expose the contained object. It exposes
its own interface and may call on the contained object on behalf of the client. So there is no way
for the client to mess with the contained object. The containing object owns the contained object
and likely created it. Like a diner with a counter where the owner creates whatever you order for
you and offers you the result.

With aggregation the aggregating object is exposing the interface of the aggregated object directly.
When the client calls on the aggregated object, the aggregating object does not act as an
intermediary, the client is directly manipulating the aggregated object, And the aggregated object
may exists without the aggregating object,

persistence.

4
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. object persistence refers to an object that is not deleted until a need emerges
to remove it from the memory. Some database models provide mechanisms for storing persistent
data in the form of objects

Persistence denotes a process or an object that continues to exist even after its parent process or
object ceases, or the system that runs it is turned off. There are two types of persistence: object
persistence and process persistence.

Meta class:-

a metaclass is a class whose instances are classes. Just as an ordinary class defines the behavior of
certain objects, a metaclass defines the behavior of certain classes and their instances. Not all
object-oriented programming languages support metaclasses.

Object Oriented Systems Development Life Cycle

The Object-Oriented approach of Building Systems takes the objects as the basis. For this, first
the system to be developed is observed and analyzed and the requirements are defined as in any
other method of system development. Once this is often done, the objects in the required system
are identified. For example, in the case of a Banking System, a customer is an object, a
chequebook is an object, and even an account is an object. Object-oriented model employs an
object-oriented strategy. The primary objectives are:
1. Object-oriented analysis,
2. Object-oriented design,
3. Object-oriented programming

There are a variety of object-oriented methodologies such as:

 Object Identification: System objects and their characteristics and events.
 Object Organization: Shows how objects are related via “part-of” relationships.
 Object Interfaces: Shows how objects interact with other objects.

Advantages of Object-Oriented Life Cycle Model:

 Design is no longer carried out independently of the later implementation because during the
design phase we must consider which components are available for the solution of the
problem.
 Design and implementation become more closely associated.
 Duration of the implementation phase is reduced.

5
 A new job title emerges, the class librarian, who is responsible for ensuring the efficient
usability of the class library.

software development process

is a way to improve design and product management by breaking software development
work into smaller steps or sub-processes that can be done in parallel or in-order.

The software development process consists of four major steps. Each of these steps is detailed
below.

 Step 1: Planning
 Step 2: Implementing
 Step 3: Testing
 Step 4: Deployment and Maintenance

The Software Development Plan (SDP) describes a developer’s plans for conducting
a software development effort. The SDP provides the acquirer insight and a tool for
monitoring the processes to be followed for software development.
Types of Software Development Approaches :-

There are three main types of software development approaches. These are:

 Waterfall Approach
 Incremental Approach
 Spiral Approach
 Agile and Scrum

Use Case Driven

A use case is a sequence of actions, performed by one or more actors (people or non-human
entities outside of the system) and by the system itself, that produces one or more results of value
to one or more of the actors

The Use-case model is defined as a model which is used to show how users interact with the system
in order to solve a problem. As such, the use case model defines the user's objective, the
interactions between the system and the user, and the system's behavior required to meet these
objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.

6
Components of Basic Model

There are various components of the basic model:

1. Actor
2. Use Case
3. Associations

Actor

Usually, actors are people involved with the system defined on the basis of their roles. An actor
can be anything such as human or another external system.

Use Case

The use case defines how actors use a system to accomplish a specific objective. The use cases are
generally introduced by the user to meet the objectives of the activities and variants involved in
the achievement of the goal.

Associations

Associations are another component of the basic model. It is used to define the associations among
actors and use cases they contribute in. This association is called communicates-association.

We have to follow the following rules while drawing use-case for any framework:

o The use case name and actor name should be meaningful and related to the system.
o The actor's interaction with the use case should be well-described and in a comprehensible
manner.
o Use annotations wherever they are essential.
o If the actor or use case has many relationships, then display only important interactions.

Generally, the use-cases diagram is used for:

o Examining the system's requirements.

o Capturing the system's Functionalities.
o We use use-case diagram in order to modeling the general idea behind the system.
o System's Forward and reverse engineering using several test cases.
o Complex visual designing of software

7
here are various tips for drawing a use-case diagram:

o It must be complete.
o It must be simple.
o The use-case diagram must show each and every interaction with the use case.
o It is must that the use-case should be generalized if it is large.
o At least one system module must be defined in the use case diagram.
o When there are number of actors or use-cases in the use-case diagram, only the significant
use-cases must be represented.
o The use-case diagrams must be clear and easy so that anyone can understand them easily.

UNIT-2

Object-oriented methodology
is a way of viewing software components and their relationships. Object-oriented
methodology relies on three characteristics that define object-oriented languages: encapsulation,
polymorphism, and inheritance.

What is Object Oriented Methodology?

The object-oriented methodology defines a method to develop an application, software or
system. The process starts with an analysis where the developer understands the user requirement.

8
After analysis, in the designing stage, the creation of an application model takes place where more
details are added to the model.

The last stage is implementation, where the programmer translates the model into a system using
programming language, database, or hardware. This process is seamless, which means that no
information is lost when the developers switch from one stage to another.

System Conception
System conception starts with the individual who identifies the business requirement and also has
a knowledge of blooming technology. He comes up with an idea for an application and discusses
it with the developer.

Analysis
The requirement statements are sometimes incomplete and vague, or sometimes they are not even
correct. The software analyst tries to figure out the big picture of the complete application

System Design
In the system design phase, the developer uses the modelling language to express different parts
that would build the system. Each part of the system is modelled separately.

Class Design
The class designer elaborates on the analysis model and adds detail to the analysis model, whereas
the system design explains the plan of action.

Implementation
The implementation phase puts all the classes and relationships between the classes into the
programming language, relate it with a database and assigns it to hardware.

9
 Wrap Up
With all these stages, the object-oriented methodology proposes the life cycle development of a
system. The developers can use these stages of object-oriented methodology to develop each part
of the system.

Benefits of Object Oriented Methodologies

1. It represents the problem domain, because it is easier to produce and understand designs.

2. It allows changes more easily.

3. It provides nice structures for thinking, abstracting and leads to modular design.

4. Simplicity:

Reusability:
Increased Quality:
 This feature increases in quality is largely a by-product of this program reuse.
7. Maintainable:
 The OOP method makes code more maintainable.
 The objects can be maintained separately, making locating and fixing problems easier.
8. Scalable: Modularity:

9. Modifiability:

10. Client/Server Architecture:

Rumbaugh Methodology,

OMT was developed as an approach to software development. The purposes of modeling

according to Rumbaugh (1991) are:

* testing physical entities before building them (simulation),

* communication with customers,

* visualization (alternative presentation of information), and

* reduction of complexity.

10
 The object-modeling technique (OMT) is an object modeling language for software
modeling and designing.

OMT has proposed three main types of models:

* Object model : The object model represents the static and most stable phenomena in the
modeled domain. Main concepts are classes and associations, with attributes and operations.
Aggregation and generalization (with multiple inheritance) are predefined relationships.

* Dynamic model : The dynamic model represents a state/transition view on the model. Main
concepts are states, transitions between states, and events to trigger transitions. Actions can be
modeled as occurring within states. Generalization and aggregation (concur-rency) are predefined
relationships.

* Functional model : The functional model handles the process perspective of the model,
corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow,
and actors.

Example:-
Below is a simple example of a bank account. We've described the relationship and process of
simple transactions between customers and bank accounts. We've also listed the instances and
methods (only in the BankAccount class). And we have optional multiplicity of association
between our transaction and bank account.

Booch Methodology
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.

11
 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
 Maintainance: Maintainance following the delivery of the product
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.)

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 BankAccount and we've listed its attributes below. As you can see, our classes
SavingsAccount and CheckingsAccount inherit the superclass.

12
Jacobson Methodology (OOSE)
The Jacobson methodology, also known as Object-Oriented Software Engineering (OOSE) or even
Objectory, is a method used to plan, design, and implement object-oriented software. The method
is broken down into five parts: a set of requirements, an analysis, a design, an implementation, and
a testing model. Uniquely, the methodology or OOSE utilizes use cases in its design.

Models:
Requirements: Create problem domain object diagram (as they satisfy requirements) and
specifies use case diagrams
Analysis: Analysis diagrams (these are similar to the ones we covered in the other methods)
Design: State transition diagrams and interaction diagrams (these are similar to the ones we
covered in the other methods)
Implementation: Implementation of the model
Testing Model: Testing of the model

Example
Below is an example of a diagram illustrating a simplified ordering kiosk system. The direction of
the arrow indicates what each use cases uses. The ordering kiosk relies on the customer for the
order; similarly the receipt relies on the ordering kiosk for the order, who in turn the chef relies
on. Our circles represent actors while our horizontal ovals represent the use cases.

Pattern & framework

A design pattern is a concept, or a receipt for how to get a specific problem done.

A Framework is code ready for use, usually packaged in a way that makes creating an application
much easier.

13
Even though they are two very different things, one can argue they both solve a software
architecture problem
 a design pattern solves many software architecture issues (about creation, behavior,
concurrency, ...) with different pre-defined design. (design being an implementation of an
architecture topic)
 a framework is based on the Hollywood Principle ("Don't call us, we call you"), where you
implement some high level requirements as specified, and leave the framework do the rest of
the work, calling your implementations.
A key difference is the scope cohesion:

 design pattern have a tight scope:

 class design patterns (involves classes)
 business design patterns (involves business workflows)
 application design patterns (involves applications)
 framework has a large scope:
For instance, .NET is a framework composed of:
 a language (C#)
 a runtime environment (CLR)
 a collection of libraries
A framework is a set of related classes to perform a certain task. Those classes may or
may not implement a certain design pattern.

Difference

Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but
only examples of patterns can be embodied in code. A strength of frameworks is that they can be
written down in programming languages and not only studied but executed and reused directly.

Design patterns are smaller architectural elements than frameworks. A typical framework
contains several design patterns, but the reverse is never true.
Design patterns are less specialized than frameworks. Frameworks always have a particular
application domain.
A design pattern is a well-established design for tackling a problem. A framework is an actual
package of code you use to make building applications easier.

5
Pattern support reuse of software architecture and design -
Framework supports reuse of detail design and code

14
 design pattern is a standard solution to a well known (design) problem. For example the Factory
pattern, and the Abstract Factory pattern offer a blueprint for implementing designs to overcome
common problems with instantiating objects.

A framework on the other hand contains infrastructure which you can use and extend to develop
your own solution. For example a model 2 "web application framework" will contain the
infrastructure for building web based applications.

Pattern: Set of guild-lines, architecturing the application.

Framework: To follow particular pattern, set of pre-build classes and libraries to create
architecture pattern.

unified approach
Unified Process model is an iterative software development procedure that works by dividing
the product development process into four distinct phases:
 Inception
 Elaboration
 Construction
 Transition
The purpose of breaking it down this way is to help companies better organize development
by identifying each phase to increase the efficiency of executing tasks.

The unified approach to software development revolves around (but is not limited to) to the
following processes and concepts. The processes are:
1. Use-case driven development
2. Object-oriented analysis
3. Object-oriented design
4. Incremental development and prototyping
5. Continuous testing
The UA allows iterative development by allowing you to go back and forth between the
design and the modeling or analysis phases. It makes backtracking very easy and
departs from the linear waterfall process, which allows no form of back tracking.

UML
short for Unified Modeling Language, is a standardized modeling language consisting of an
integrated set of diagrams, developed to help system and software developers for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well as for
business modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex systems.

15
The UML is a very important part of developing object oriented software and the software
development process. The UML uses mostly graphical notations to express the design of
software projects. Using the UML helps project teams communicate, explore potential designs,
and validate the architectural design of the software.

The goal of UML is to provide a standard notation that can be used by all object-oriented
methods and to select and integrate the best elements of precursor notations. UML has been
designed for a broad range of applications.

ADVANTAGES:-
1. Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks, patterns
and components.
7. Integrate best practices.

Types of UML diagrams

UML uses elements and associates them in different ways to form diagrams that represent static,
or structural aspects of a system, and behavioral diagrams, which capture the dynamic aspects of
a system.

16
 Structural UML diagrams

 Class Diagram The most commonly used UML diagram, and the principal foundation of any
object-oriented solution. Classes within a system, attributes and operations and the relationship
between each class. Classes are grouped together to create class diagrams when diagramming
large systems.

 Component Diagram Displays the structural relationship of software system elements, most
often employed when working with complex systems with multiple components. Components
communicate using interfaces.

 Composite Structure Diagram Composite structure diagrams are used to show the internal
structure of a class.

 Deployment Diagram Illustrates system hardware and its software. Useful when a software
solution is deployed across multiple machines with unique configurations.

 Object Diagram Shows the relationship between objects using real world examples and
illustrates how a system will look at any given time. Because data is available within objects,
they can be used to clarify relationships between objects.

 Package Diagram There are two special types of dependencies defined between packages:
package import and package merge. Packages can represent the different levels of a system to
reveal the architecture. Package dependencies can be marked to show the communication
mechanism between levels.

Behavioral UML diagrams

 Activity Diagrams Graphically represented business or operational workflows to show the

activity of any part or component in the system. Activity diagrams are used as an alternative to
State Machine diagrams.

 Communication Diagram Similar to sequence diagrams, but the focus is on messages passed
between objects. The same information can be represented using a sequence diagram and
different objects.

 Interaction Overview Diagram There are seven types of interaction diagrams, and this diagram
shows the sequence in which they act.

 Sequence Diagram Shows how objects interact with each other and the order of occurrence.
They represent interactions for a particular scenario.

17
 State Diagram Similar to activity diagrams, they describe the behavior of objects that behave in
varying ways in their current state.

 Timing Diagram Like Sequence Diagrams, the behavior of objects in a given time frame are
represented. If there is a single object, the diagram is simple. With more than one object,
interactions of objects are shown during that particular time frame.

 Use Case Diagram Represents a particular functionality of a system, created to illustrate how
functionalities relate and their internal/external controllers (actors).

Characteristics of UML

The UML has the following features:

o It is a generalized modeling language.

o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.

UNIT-3

OOAD - Object Oriented Analysis

In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.
The three analysis techniques that are used in conjunction with each other for object-oriented
analysis are object modelling, dynamic modelling, and functional modelling.
Object Modelling
Object modelling develops the static structure of the software system in terms of objects. It
identifies the objects, the classes into which the objects can be grouped into and the relationships
between the objects
he process of object modelling can be visualized in the following steps −
 Identify objects and group into classes
 Identify the relationships among classes

18
  Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary
Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to time and external
changes needs to be examined. This is the purpose of dynamic modelling.
Dynamic Modelling can be defined as “a way of describing how an individual object responds to
events, either internal events triggered by other objects, or external events triggered by the outside
world”.
The process of dynamic modelling can be visualized in the following steps −
 Identify states of each object
 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition diagrams
 Express each state in terms of object attributes
 Validate the state–transition diagrams drawn
Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The functional model
shows the processes that are performed within an object and how the data changes as it moves
between methods. It specifies the meaning of the operations of object modelling and the actions of
dynamic modelling. The functional model corresponds to the data flow diagram of traditional
structured analysis.
The process of functional modelling can be visualized in the following steps −
 Identify all the inputs and outputs
 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria
Advantages/Disadvantages of Object Oriented Analysis
Advantages Disadvantages

Focuses on data rather than the procedures as Functionality is restricted within objects. This
in Structured Analysis. may pose a problem for systems which are
intrinsically procedural or computational in
nature.

19
 The principles of encapsulation and data It cannot identify which objects would generate
hiding help the developer to develop systems an optimal system design.
that cannot be tampered by other parts of the
system.

The principles of encapsulation and data The object-oriented models do not easily show
hiding help the developer to develop systems the communications between the objects in the
that cannot be tampered by other parts of the system.
system.

It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.

It can be upgraded from small to large

systems at a greater ease than in systems
following structured analysis.

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of
software development based upon the waterfall model. The phases of development of a system
using SASD are −
 Feasibility Study
 Requirement Analysis and Specification
 System Design
 Implementation
 Post-implementation Review
Advantages/Disadvantages of Structured Analysis
Advantages Disadvantages

As it follows a top-down approach in contrast to In traditional structured analysis models,

bottom-up approach of object-oriented analysis, it one phase should be completed before
can be more easily comprehended than OOA. the next phase. This poses a problem in
design, particularly if errors crop up or
requirements change.

20
 It is based upon functionality. The overall
purpose is identified and then functional
decomposition is done for developing the
software. The emphasis not only gives a better
understanding of the system but also generates
more complete systems.
The specifications in it are written in simple
English language, and hence can be more easily
analyzed by non-technical personnel.
Structured Approach Vs. Object-Oriented Approach
The following table explains how the object-oriented approach differs from the traditional
structured approach −
Structured Approach
It works with Top-down approach.
Program is divided into number of submodules or
functions.
Function call is used.
Software reuse is not possible.
Structured design programming usually left until
end phases.
Structured Design is more suitable for
offshoring.
It shows clear transition from design to
implementation.
The initial cost of constructing the
system is high, since the whole system
needs to be designed at once leaving
very little option to add functionality
later.
It does not support reusability of code.
So, the time and cost of development is
inherently high.
Object Oriented Approach
It works with Bottom-up approach.
Program is organized by having number of
classes and objects.
Message passing is used.
Reusability is possible.
Object oriented design programming done
concurrently with other phases.
It is suitable for in-house development.
Not so clear transition from design to
implementation.
21
 It is suitable for real time system, embedded It is suitable for most business applications,
system and projects where objects are not the game development projects, which are expected
most useful level of abstraction. to customize or extended.

DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart
diagram, and use cases all contribute.

In this, projects can be managed easily due to In this approach, projects can be difficult to
clearly identifiable phases. manage due to uncertain transitions between
phase.

Use Case Driven Object Oriented Analysis:-

DESCRIBED ABOVE

Use Case Model

Use-Case Model

The Use-case model is defined as a model which is used to show how users interact with the system
in order to solve a problem. As such, the use case model defines the user's objective, the
interactions between the system and the user, and the system's behavior required to meet these
objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to
the given model, each demonstrating a subset of the model components related to a specific
purpose.

Packages may include a use-case model, which is used to organize the model to simplify the
analysis, planning, navigation, communication, development and maintenance.

Various use-case models are textual and the text captured in the use-case specifications, which are
linked with the element of every use-case model.

DESCRIBED ABOVE

22
Object-Oriented Analysis
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s object model,
which comprises of interacting objects.
The main difference between object-oriented analysis and other forms of analysis is that in object-
oriented approach, requirements are organized around objects, which integrate both data and
functions. They are modelled after real-world objects that the system interacts with. In traditional
analysis methodologies, the two aspects - functions and data - are considered separately.
It is based on a set of basic principles, which are as follows-
1. The information domain is modeled.
2. Behavior is represented.
3. The function is described.
4. Data, functional, and behavioral models are divided to uncover greater detail.

1. The Subsystem Layer : It represents the subsystem that enables software to achieve user
requirements and implement technical frameworks that meet user needs.
2. The Class and Object Layer : It represents the class hierarchies that enable the system to
develop using generalization and specialization. This layer also represents each object.
3. The Message Layer : It represents the design details that enable each object to communicate
with its partners. It establishes internal and external interfaces for the system.
4. The Responsibilities Layer : It represents the data structure and algorithmic design for all
the attributes and operations for each object.

Object Analysis: Classification Approaches for Identifying classes:-

■ Four alternative approaches for identifying classes:

23
The noun phrase approach;
the ■ common class patterns approach;

the use- case derive, sequence/ collaboration modelling ■ approach; and the classes
, Responsibilities, and collaborators ( CRC) approach.

Noun Phrase approach – The noun phrase approach was proposed by Rebecca Wirfs-Brock,
Brian Wilker -son, and Lauren Wiener. –
In this method, you read through the requirements or use cases looking for noun phrases. – Nouns
in the textual description are considered to be classes and verbs to be methods of the classes. – The
nouns are listed, and the list divided into three categories: relevant classes, fuzzy classes (The
'fuzzy area," classes we are not sure about), and irrelevant classes.
1. Identifying Tentative classes.

2. Selecting classes from the Relevant and fuzzy categories.

3. The vialNet Bank ATM System: Identifying classes by using Noun phrase Approach.

4. Initial List of Noun phrases: candidate classes.

5. Reviewing the Redundant classes and Building a common vocabulary.
6. Reviewing the classes containing Adjectives.

7. Reviewing the possible Attributes.

8. Reviewing the class purpose

Classes, responsibilities and collaborators

■ classes, Responsibilities, and collaborators is a technique used for identifying classes‘
responsibilities and therefore the attributes and methods.

■ classes, Responsibilities, and collaborators is based on the idea that an object either can
accomplish a certain responsibility itself or it may require the assistance of other objects.
■ By identifying an object's responsibility and collaborators (co-operative objects with which it
works) you can identify its attributes and methods.
■ classes, Responsibilities, and collaborators cards are 4" X 6" index cards. All the information
for an object is written on a card, which is cheap, portable, readily available, and familiar.

24
Identifying Associations
■ Identifying associations begins by analysing the interactions between classes.
■ you must examine the responsibilities to determine dependencies.

25
 ■ In other words, if an object is responsible for a specific task (behaviour) and lacks all the
necessary knowledge needed to perform the task, then the object must delegate the task to another
object that possesses such knowledge

. ■ Is the class capable of fulfilling the required task by itself?

■ If not, what does it need?

■ From what other class can it acquire what it needs?

Guidelines for Identifying Association

■ A dependency between two or more classes may be an association.
■ A reference from one class to another is an association.

Identifying Object Relationships, Attributes and Methods:

Goals

• Analyzing relationships among classes.

• Identifying association.

• Association patterns.
• Identifying super- and subclass hierarchies.

Objects Relationships
• Three types of relationships among objects are:
• Association-Guide us in designing classes

• Super-sub structure (also known as generalization hierarchy)- provides us the direction of

inheritance. • Aggregation and a-part-of structure-guides us in defining mechanisms that properly
manage objects within objects

Associations
• A reference from one class to another is an association or physical or conceptual connection
between two or more objects.

• Basically a dependency between two or more classes is an association.

• For example, Jackie works for John.

Identifying Associations
• Identifying associations begins by analyzing the interaction between the classes.

26
• We can identify the associations by answering the following questions:
IF the class capable of fulfilling the required task by itself?

If not, what does it need?

From what other classes can it acquire what it needs?

Guidelines For Identifying Super Sub Relationships

• Top Down

• Bottom up
• Reusability

• Multiple Inheritance
Top-down

• Look for noun phrases composed of various adjectives on class name.

• Specialize only when the sub classes have significant behavior.
Bottom-up

• Look for classes with similar attributes or methods.

• Group them by moving the common attributes and methods to super class.

Reusability
• Move attributes and methods as high as possible in the hierarchy.

• At the same time do not create very specialized classes at the top of hierarchy.
• This balancing act can be achieved through several iterations.

Multiple inheritance
• Avoid excessive use of multiple inheritance.

• It is also more difficult to understand programs written in multiple inheritance system.

Association vs. Aggregation vs. Composition

Association Aggregation Composition

27
 Association relationship
is represented using an
arrow.
In UML, it can exist
between two or more
classes.
It incorporates one-to- It exhibits a kind of weak
one, one-to-many, many- relationship.
to-one, and many-to-
many association between
the classes.
It can associate one more
objects together.
In this, objects are linked
together.
It may or may not affect
the other associated
element if one element is
deleted.
Example: A tutor can
associate with multiple
students, or one student
can associate with
multiple teachers.
Object Responsibilities
These responsibilities are of two types. They are:
Aggregation relationship is
represented by a straight line
with an empty diamond at one
end.
It is a part of the association
relationship.
In an aggregation relationship,
the associated objects exist
independently within the scope
of the system.
In this, the linked objects are
independent of each other.
Deleting one element in the
aggregation relationship does
not affect other associated
elements.
Example: A car needs a wheel
for its proper functioning, but it
may not require the same
wheel. It may function with
another wheel as well.
The composition relationship is
represented by a straight line with
a black diamond at one end.
It is a part of the aggregation
relationship.
It exhibits a strong type of
relationship.
In a composition relationship, the
associated objects cannot exist
independently within the scope of
the system.
Here the linked objects are
dependent on each other.
It affects the other element if one
of its associated element is
deleted.
Example: If a file is placed in a
folder and that is folder is deleted.
The file residing inside that folder
will also get deleted at the time of
folder deletion.
28
 Doing
Knowing

Doing responsibilities of an object include

Doing something itself such as creating objects and doing calculations.

Initiating action in other objects.
Controlling and coordinating activities in other objects.

Knowing responsibilities of an object include:

Knowing about private encapsulated data.

Knowing about related objects.
Knowing about things it can derive or calculate.

29
Class responsibilities are the class's attributes and methods. Clearly, they represent the class's state
and behaviour. Collaborators represent the associations the class has with other classes.
A CRC model is really a collection of standard index cards that represent classes. The cards are
divided into three sections. Along the top of the card you write the name of the class. In the body
of the card you list the class responsibilities on the left and the collaborators on the right.

In reality the CRC model may make use of actual or virtual cards so that an organized
representation of classes can be developed. Responsibilities are the attributes and operations that
are relevant for the class. Collaborators are those classes that are needed to provide a
responsibility.

Responsibilities

Responsibilities basically consist of attributes and operation of a class. The attributes are the
stable features of a class be achieve from the statement of the scope or by understanding
the nature of the class. The operations of class exhibit the behaviour or the class.

UNIT-4
Design axioms and Corollaries.

OO Design Axioms

 An axiom is a fundamental truth that always is observed to be valid and for which there is no
counterexample or exception.

30
 The axioms cannot be proven or derived

 A theorem is a proposition that may not be self-evident but can be proven from accepted axioms.
Therefore, is equivalent to a law or principle.

 A theorem is valid if its referent axioms & deductive steps are valid.

 A corollary is a proposition that follows from an axiom or another proposition that has been
proven

 Suh’s design axioms to OOD :

o Axiom 1 : The independence axiom. Maintain the independence of components

o Axiom 2 : The information axiom. Minimize the information content of the design
. Axiom 1 States that, during the design process, as we go from requirement and use - case to a
system component, each component must satisfy that requirement, without affecting other
requirements

Axiom 2  Concerned with simplicity. Rely on a general rule known as Occam‟s razor.

 Occam‟s razor rule of simplicity in OO terms :

The best designs usually involve the least complex code but not necessarily the fewest number of
classes or methods. Minimizing complexity should be the goal, because that produces the most
easily maintained and enhanced application. In an object-oriented system, the best way to
minimize complexity is to use inheritance and the system‟s built-in classes and to add as little as
possible to what already is there.

Object-Oriented Design Axioms

• An AXIOM is a fundamental truth that always is observed to be valid and for which there is no
counter example or exception.
• A theorem is a proposition that may not be self evident but can be proven from accepted axioms.

• A corollary is a proposition that follows from an axiom or another proposition that has been
proven.
• Axiom l. The independence axiom. Maintain the independence of components.

• Axiom 2. The independence axiom. Minimize the information content of the design.
• Axiom I States that, during the design process, as we go from requirement and use case to a
system component each component must satisfy that requirement without affecting other
requirements.

31
• Axiom 2 is concerned with simplicity. "The best theory explains the known facts with a
minimum amount of complexity and maximum simplicity and straight forwardness.

Corollaries
May be called Design rules , and all are derived from the two basic axioms :The origin of collaries
as shown in figure 2. Corollaries 1,2 and 3 are from both axioms, whereas corollary 4 is from
axiom 1 and corollaries 5 & 6 are from axiom 2.

Corollary 1:

Uncoupled design with less information content.

 Coupling is a measure of the strength of association established by a connection

fromone object or software component to another.
 Coupling is a binary relationship.
 It is important for design because a change in one component should have a minimal
impact on the other components.
 Degree or strength of coupling between two components is measured by the amount
&complexity of information transmitted between them.
 OO design has 2 types of coupling :
o Interaction coupling and Inheritance coupling.

Interaction coupling
The amount & complexity of messages between components.
Desirable to have a little interaction.

32
 Minimize the number of messages sent & received by an object
Types of coupling among objects or components

Inheritance coupling
coupling between super-and subclasses
A subclass is coupled to its superclass in terms of attributes & methods

High inheritance coupling is desirable

Each specialization class should not inherit lots of unrelated & unneeded methods & attributes

Need to consider interaction within a single object or sw component► Cohesion

Cohesion ► reflects the‟single-purposeness‟ of an object ( see corollaries 2&3 )

Method cohesion ► a method should carry only one function.
A method carries multiple functions is undesirable

Corollary 2 : Single purpose .

Each class must have a purpose & clearly defined

Each method must provide only one service

Corollary 3 : Large number of simple classes.

Keeping the classes simple allows reusability

A class that easily can be understood and reused (or inherited) contributes to the overall system

Complex & poorly designed class usually cannot be reused.

33
Guideline ► The smaller are your classes, the better are your chances of reusing them in other
projects. Large & complex classes are too specialized to be reused.

The emphasis OOD places on encapsulation, modularization, and polymorphism suggests reuse
rather than building anew

Primary benefit of sw reusability ► Higher prpductivity

Corollary 4 : Strong mapping.

There must be a strong association between the analysis’s object and design’s object.

OOA and OOD are based on the same model.

As the model progresses from analysis to implementation, more detailed is added.

Corollary 5 : Standardization.

Promote standardization by designing interchangeable components and reusing existing classes or

components
The concept of design patterns might provide a way to capture the design knowledge, document
it, and store it in a repository that can be shared and reused in different applications

Corollary 6 : Design with inheritance.

Common behavior (methods) must be moved to super classes.
The superclass-subclass structure must make logical sense.

Design Patterns
• Design patterns are devices that allow systems to share knowledge about their design, by
describing commonly recurring structures of communicating components that solve a general
design problem within a particular context.

• In programming, we have encountered many problems that occurred before and will occur again.
the question we must ask ourselves is how we are going to solve it this time.
In software engineering, a design pattern is a general repeatable solution to a commonly
occurring problem in software design. A design pattern isn't a finished design that can be

34
 transformed directly into code. It is a description or template for how to solve a problem that can
be used in many different situations.

Designing classes
• The three basic types of attributes are
1. single-value attributes. 2. Multiplicity or multivalue attributes.

3. Reference to another object, or instance connection.

Design classes

 A set of design classes refined the analysis class by providing design details.
There are five different types of design classes and each type represents the layer of the
design architecture these are as follows:

1. User interface classes

 These classes are designed for Human Computer Interaction(HCI).
 These interface classes define all abstraction which is required for Human Computer
Interaction(HCI).
2. Business domain classes
 These classes are commonly refinements of the analysis classes.
 These classes are recognized as attributes and methods which are required to implement the
elements of the business domain.
3. Process classes
It implement the lower level business abstraction which is needed to completely manage the
business domain class.

4. Persistence classes
It shows data stores that will persist behind the execution of the software.

5. System Classes
System classes implement software management and control functions that allow to operate and
communicate in computing environment and outside world.

Design class characteristic

The characteristic of well formed designed class are as follows:

1. Complete and sufficient

35
 A design class must be the total encapsulation of all attributes and methods which are required to
exist for the class.

2. Primitiveness
 The method in the design class should fulfil one service for the class.
 If service is implemented with a method then the class should not provide another way to fulfil
same thing.
3. High cohesion
 A cohesion design class has a small and focused set of responsibilities.
 For implementing the set of responsibilities the design classes are applied single-mindedly to the
methods and attribute.
4. Low-coupling
 All the design classes should collaborate with each other in a design model.
 The minimum acceptable of collaboration must be kept in this model.

Object Oriented Design Philosophy

The OO philosophy suggests that the things manipulated by the program should correspond to
things in the real world. They should carry the same names as those things carry in the real world.
And they should interact in ways like those objects n the real world.

 The single most important activity in designing an application is coming up with a set of
classes that work together to provide the functionality you desire.
 A given problem always has many solutions. However, at this stage, you must translate the
attributes and operations into system implementation.
 You need to decide where in the class tree your new classes will go.
 Your goal in using these systems should be to reuse rather than create anew.

 The first step in building an application, therefore, should be to design a set of classes, each
of which has a specific expertise and all of which can work together in useful ways.
 Applying design axioms and carefully designed classes can have a synergistic effect, not
only on the current system but on its future evolution.
 If you exercise some discipline as you proceed, you will begin to see some extraordinary
gains in your productivity compared to a conventional approach.

36
Principles of Object-Oriented Design

Single Responsibility Principle (SRP)

The SRP requires that a class should have only a single responsibility

Open-Closed Principle (OCP)

The OCP requires that each software entity should be open for extension, but closed for
modification.

Example: Suppose an OrderValidation class has a method validate(Order order) that is

programmed to validate an order based on a set of hard-coded rules. This design violates the OCP
because if the rules change, the OrderValidation class has to be modified, tested, and compiled.

Liskov Substitution Principle (LSP)

The LSP requires that objects in a program should be replaceable with instances of their subclasses
without altering the correctness of that program.

Interface Segregation Principle (ISP)

The ISP requires that clients should not be forced to depend on interfaces that they do not use.

Example: Suppose a Vehicle interface shown in the figure is designed for clients to use

37
Dependency Inversion Principle (DIP)

The DIP requires that high level modules should not depend on low level modules, both should
depend on abstraction. Also, abstraction should not depend on details, details should depend on
abstractions.

Object constraint language

The Object Constraint Language (OCL) is an expression language that describes constraints on
object-oriented languages and other modelling artifacts. A constraint can be seen as a restriction
on a model or a system. OCL is part of Unified Modeling Language (UML) and it plays an
important role in the analysis phase of the software lifecycle.

Object Constraint Language (OCL), is a formal language to express side effect-free constraints.
Users of the Unified Modeling Language and other languages can use OCL to specify constraints
and other expressions attached to their models.

Expression language

OCL is a pure expression language. Therefore, an OCL expression is guaranteed to be without side
effect. It cannot change anything in the model

Modeling language

OCL is a modeling language, not a programming language. It is not possible to write program
logic or flow-control in OCL. You especially cannot invoke processes or activate non-query
operations within OCL. Because OCL is a modeling language in the first place, not everything in
it is promised to be directly executable.

Formal language

OCL is a formal language where all constructs have a formally defined meaning. The specification
of OCL is part of the UML specification.OCL is not intended to replace existing formal languages,
like VDM, Z etc.

Applications of OCL

38
OCL can be used for a number of different purposes:

To specify invariants on classes and types in the class model.

To specify type invariant for Stereotypes.
To describe pre- and post conditions on Operations and Methods.
To describe Guards.
As a navigation language.
To specify constraints on operations.

DESIGNING CLASSES :-
The set of design classes refine analysis classes and providing design detail that enables classes
to execute a software infrastructure that supports business solutions.

Types:

There are 5 different types of design classes that represent a different layer of design architecture
that can be developed:
1. User interface classes define abstraction that mandatory for human-computer interaction
[HCI]. In cases, HCI occurs within the context of metaphor, and design classes for the
interface may be visible representations of elements of metaphor.
2. Business domain classes are often refinements of analysis classes defined earlier. The class
identifies the attributes that are required to implement some elements of the business domain.
3. Process classes implement lower-level business Preoccupation need to manage business
domain classes.
4. Persistent classes represent the data stores that will persist beyond the execution of software.
5. System classes implement software management and control function that permits the
system to operate and convey within its computing environment and with the outside world

 Four minimal characteristics must have to be considered for a well-formed design classes:
o complete and sufficient
A complete and sufficient class gives users of the class (public operations) the
contract they expect-no more and no less.
o primitive
Primitiveness - services should be simple, atomic, and unique.
o high cohesion
Each class should capture a single, well-defined abstraction, using the minimal set
of features.

39
 o low coupling
A class should be associated with the minimum number of other classes to allow it
to fulfill its responsibilities.

CLASS VISIBILITY:-
 In designing methods or attributes for classes, you are confronted with two problems.

 One is the protocol, or interface to the class operations and its visibility; and the other
is how it is implemented.
 Often the two have very little to do with each other.

 For example, you might have a class Bag for collecting various objects that counts
multiple occurrences of its elements.
 The class's protocol, or the messages that a class understands, on the other hand, can
be hidden from other objects (private protocol) or made available to other objects
(public protocol).

There are four common ways that visibility can be achieved from object A to object B:

 Attribute visibility— B is an attribute of A.

 Parameter visibility— B is a parameter of a method of A.
 Local visibility— B is a (non-parameter) local object in a method of A.
 Global visibility— B is in some way globally visible.

Visibility is a big part of OOP. It allows you to control where your class members can be accessed
from, for instance to prevent a certain variable to be modified from outside the class. The default
visibility is public, which means that the class members can be accessed from anywhere. This
means that declaring the visibility is optional, since it will just fall back to public if there is no
access modifier.

Private members can only be accessed from inside the class itself.

Protected members can only be accessed from inside the class it self and its child classes.

Public members can be accessed from anywhere - outside the class, inside the class it self and
from child classes

THE PROCESS:-

40
  Apply design axioms to design classes, their attributes, methods, associations,
structures, and protocols.

◦ Refine and complete the static UML class diagram by adding details to that
diagram.

 Refine attributes.
 Design methods and the protocols by utilizing a UML, activity diagram
to represent the method's algorithm.

 Refine the associations between classes, (if required).

 Refine the class hierarchy and design with inheritance (if required).

 1.2. Iterate and refine.

There are three ways to design classes: by composition, via inheritance, and via interface.

Composition (or aggregation) is achieved by using existing class as a part of a new class. For
example, the ArrayStack class includes an array of objects.

Inheritance allows you to define a new class in terms of an old class. The new class automatically
inherits all public members of the original class. Inheritance is useful for creating specialized
objects that share comon behavior. We will see more on inheritance later in the course.

Interfaces act like inheritance in the way that they define a set of properties,

DESIGNING CLASSES: REFINING ATTRIBUTES:-

 The main goal of this activity is to refine existing attributes (identified in analysis) or
add attributes that can elevate the system into implementation.

 Attribute Types

◦ The three basic types of attributes are

 Single-value attributes.

 Multiplicity or multivalue attributes.

 Reference to another object, or instance connection.

 Attributes represent the state of an object.

41
  When the state of the object changes, these changes are reflected in the value of
attributes.

 The single-value attribute is the most common attribute type.

 It has only one value or state.
 For example, attributes such as name, address, or salary are of the single-value type

REFINING ATTRIBUTES FOR THE VIANET BANK OBJECTS:-

 During object-oriented analysis, we identified the following attributes :

◦ firstName

◦ lastName

◦ pinNumber

◦ cardNumber
 At this stage, we need to add more information to these attributes, such as visibility
and implementation type.

◦ #firstName: String

◦ #lastName: String

◦ #pinNumber: String

◦ #cardNumber: String

◦ #account: Account (instance connection)

DESIGNING METHODS AND PROTOCOLS:-
 The main goal of this activity is to specify the algorithm for methods identified so far.

 Once you have designed your methods in some formal structure such as UML activity
diagrams with an OCL description, they can be converted to programming Language
manually or in automated fashion
 A class can provide several types of methods [3]:

 Constructor. Method that creates instances (objects) of the class.

 Destructor. The method that destroys instances.

 Conversion method. The method that converts a value from one unit of
measure to another.

42
  Copy method. The method that copies the contents of one instance to another
instance.

◦ Attribute set. The method that sets the values of one or more attributes.

◦ Attribute get. The method that returns the values of one or more attributes.

◦ I/O methods. The methods that provide or receive data to or from a device.

◦ Domain specific. The method specific to the application.

◦ Corollary 1, that in designing methods and protocols you must minimize the
complexity of message connections and keep as low as possible the number of
messages sent and received by an object.

◦ Your goal should be to maximize cohesiveness among objects and software

components to improve coupling, because only, a, minimal amount of essential
information should be passed between component.

◦ Abstraction leads to simplicity and straightforwardness and, at the same time,

increases class versatility.

FIVE RULES :-
 Here are five rules [1]:

 If it looks messy, then it's probably a bad design.

 If it is too complex, then it's probably a bad design.

 If it is too big, then it's pr9bably a bad design.

 If people don't like it, then it's probably a bad design.

 If it doesn't work, then it's probably a bad design.

Packages
A package is a grouping and organizing element in which other elements reside, which must be
uniquely named. In the UML, packages are used in a manner similar to the way directories and
folders in an operating system group and organize files. For example, the project management
system may be decomposed into a collection of classes organized into packages as follows:
Utility
Date, time, and other utility classes

43
Workers
The Worker class and any other worker-related classes in which the Worker class is
contained inside of a package named Generic
Generic
Generic classes such as the Worker class and any other worker-related classes
Work Units
The UnitOfWork class and any other work-related classes
Packages allow us to partition our system into logical groups and then to relate these logical
groups; otherwise, it could become overwhelming to work with every class and its relationship at
once

MANAGING CLASSES :-
NHI MILA

User Interface Design • View layer Classes • Micro-level Processes • View Layer Interface
User Interface Design: -
o The main goal of UI is to display & obtain needed information in an accessible, efficient
manner. A well defined UI has visual appeal that motivates users to use application
o To view UI design as a creativity process it constituents are the following

1. A curious & imaginative mind

2. A broad Background & fundamental knowledge of existing tools & methods

3. An enthusiastic desire to do a complete & through job of discovering solutions once a

problem has been defined
4. Being able to deal with uncertainty & ambiguity & to defer premature closure

Designing View Layer classes: -

o The view layer objects are responsible for two major aspects of applications:

1. Input • responding to user interaction

2. Output • displaying or printing business objects

o The process of designing view layer classes is divided into four major activities
1. Macro level UI design process • identifying view layer objects

44
 2. Micro level UI design activities • constitute of mainly two steps such as
i. Designing the view layer objects by applying design axioms & corollaries

ii. Prototyping the view layer interface

3. Testing usability & user satisfaction

4. Refining and iterating the design

Macro–Level Process: -
o The main goal of this level is identifying view class by analyzing use cases. The interface
object handles all communication with actor but processes no business rules or object storage
activities
o The view layer macro process consists of two steps as shown in daigram

1. Determine if class interacts with a human actor

a. Identify view (interface) objects for class

b. Define relationships among the view (interface) objects

2. Iterate and refine

o The advantage of utilizing use cases in identifying & designing view layer objects is that the
focus centers on the user and including users as part of the planning & design is the best way to
ensure accommodating them

Micro – Level Process: -

o A user•centered interface replicates the user•s view of doing things by providing the outcomes
users expect for any action. The micro level process of designing view objects has two steps
1. For very interface object identified in macro UI design process, apply micro • level UI design
rules & corollaries to develop the UI

2. Iterate and Refine

o UI design rule 1: Making the interface simple (Application of corollary 2) •Labels, static text,
check boxes, group boxes & option buttons often clutter the interface & take up twice the room
mandated by actual data.

The following factors should be considered while evaluating the impact:

˜ Every additional feature potentially affects performance, complexity, stability, maintenance
& support costs of an application

45
 ˜ It is harder to fix a design problem after release of product because users may adapt or even
become dependent on a peculiarity in design

˜ Simplicity is different from being simplistic. Making something simple to use often requires
a good deal of work & code
˜ Features implemented by a small extension in application code do not necessarily have a
proportional effect in a UI

o UI design rule 2: Making the interface Transparent and Natural (Application of Corollary 4)
• It implies that there should be strong mapping between user•s view of doing things & UI classes.

Purpose of a View Layer Interface: -

o UI can employ one or more windows. Each window should serve a clear, specific purpose.
Windows commonly are used for the following purposes

∝ Forms & data entry windows … provide access to data that users can retrieve, display &
change in the application

∝ Dialog Boxes … display status information or ask users to supply information or make a
decision before continuing with a task. A typical feature of a dialog box is OK button

∝ Application windows (main windows) … is a container of application objects or icons. In

other words, it contains an entire application with which users can interact

o Guidelines for Designing forms & Data Entry windows:

END

46