CT Complete-1 PDF

Unit – I
Data Modeling: Business Growth-Organisational Model-Case Study of student MIS-What

is the purpose of such Models-Understanding the business-Types of models-model
development approach-the case for structural development-advantages of using a case tool.
System analysis and design-what is DFD-General Rules for Drawing DFD-Difference
Between Logical data flow diagram and Physical data flow diagram- Software verses
Information Engineering-How case tools store information.
1. Datamodeling:
 How we are modling the business
 When a new bussiness comes into gain a profit
 Management will take over the responsbility of desingning the detailes daily
 These will be implemented qnd checked for bugs for bussiness growth
2. Bussiness growth:
2 main factors
i) manpower ii) Fund flow
 There will be responsible heads in the organization

 There will pass accurate information to senior
 The various plans of the company can be projectd
 So the fundflow will increase, the decisions are made by the organization based on the
information based by various lvels of heads
 Fund flow increase the organization growth of business
 The raw material suppliers will increase
 Finished product also increase
Fund flow increase
Financial control increase Supplier rawmetrial Mrketting increse
Finished products increase
1
3. Oraganization model
Oranization model indicates how its business runs
Model Management
Develop model strategy Maintain project model Maintain corarate model
 Model can be used to improve the way of business

 Its indicate the strength and weakness
 The weakness can be evaluated and changed to strengths
 Rules: i) shape of the object ii)Relationship between objects
4. Case study: A student MIS system

o There are a lot of computer traning instutes who take in a students . and train
them in the use of computer
o Computer training institutes will have to adverttise , when a students reads the
advertisementand join the organization students is conversion
Eg: let’s considr the cost of letter

1. Type of envelope 2. Quality of paper + weight of paper 3. Weight of the
envelope 4. Printing cost for each letter 5. Coast of postage
Disadvantage of hard coding atomic values into program
 Hardcode it become impossible to implement changes when it takes place
 A small changes is made at the atomic level it can’t be implemented in the
computer system without making changes in the source file
 IT professionals we have to try and make the applications as flexible as possible
2
5. Purpose of such models:
 Once a model of a business is designed senior personal of business can apply
their knowledge and experience to the model to improve
 1. Bottelneck 2. Manpower requirement of the system 3. Financial requirement
of the system
Documentation:
A business is to document how the business operates ,document can be studied and
improved if required
6. Understanding the business
 Business people and the computer professional have to work together to create a
computerized system
 That can be improve the business better
Structured analysis
Purpose of analysis is to produce a system of specification that define the
structure of the problem.
Analysis and design- produces a best meets user needs
System specification is composed of data-flow diagrams
DFDis the central modeling tool
Improving system quality
7. System designers perspective models can improve the quality of system analysis
and design
8. Visually reviewing the major functions of the system
9. Easily missing components and organize system structure
10. Transferring personal from one department to another
11. A diagram depicting the transfer of data between programs
Project team co-ordination

These models can depict a high level overview of how a system will function all team
members can understand responsibility of system
12. Types of models two models i) Business model ii) information system models
Business model- it represent the business

Information system models- treks the way , in which it will be used documents the
business function, documents the business function which the information is accessed.
13. Both model will be graphically represent
14. The interaction between data and process
15. These are the model developed for several layers physical, logical, conceptual
8.model development approach

The model developer draws on knowledge of the business or system the business may
provide assistance in answering specific question about the model.
JAD session: Join Application Development session working between information
systems professionals and the business community model is created by the group.
3
What is CASE tool
Development of special S/W that works on micros, minis and mainframes called
Computer Aided Software Engineering
The case for structures development
 S/W development is an art and a science
 CASE technology is the automation of step-by-step methodologies
 Development from step-one planning to ongoing maintenance
Planning: Gathering information about user problems and requirements
Analysis: Determine user needs and system constraints testing, gathering functional
specification
Design: Diagrams and data flow
Implementation: Building, testing, installing and tuning S/W
Maintenance : Implementing plans, tuning, correcting and enhancing system.
Advantages of using CASE tools

 This maybe a simple diagram showing the flow of data between business
functions.
 These models help the system developer in the analysis and design activities by
displaying system components graphically at various levels.
The methodology link
1. Before 1970’s applications grew more complex and more people got involved
int the development and maintenance
2. CASE tools are used to support modeling activities
3. CASE tools can automate the generation of the physical database
4. CASE tool can also produce program code
5. This reduce time and optimized code
6. CASE tools provide additional information about the objects
7. CASE tools includes diagramming logic
8. CASE tool have the capability to track additional information about the objects.
9. Logical errors in system design are trapped and corrected immediately
10. CASE tools embedded with rules.
Casing the market:
 CASE tools has one of the highest growth rate many companies buying multiple
copies of tools
 CASE will most likely occur when developers and managers
 CASE tools are micro computer based powerful graphics to enhance the user
interface
System analysis and design:

Introduction:
4
 A computer can work on a task at very high speed and with great accuracy when
compared to a human being
 Analysis system required we can understand how the system function and what
are its inputs what kind of processing takes place and what kind of output is
produced.
 Analysis of the manual system helps him design a set of instructions that will
tell the computer what to do
 It is essentially systems analysis prior design, most computer system will not
produce to kind of output that we require
 System analysis and design in the early days was done based on the
programmers personal skills this varied person to person
 This method was very personalized this method had several clearly
understandable rules
 Its creates the structured diagrams and charts
Structured system analysis and design
1. Structured methodologies help to standardize and systematize s/w development
and maintenance
2. Strutting produces clear fast- to-write and easy- to- maintain programs
3. At that time data flow diagrams were drawn using plastic templates as a
diagramming assistance
4. Biggest drawback of structured methodologies their diagramming techniques
are manual, slow and tedious
5. CASE tool new structured methodologies by providing automated graphics
facilities for producing charts and diagram screen and report painters, data dictionaries
extensive reporting facilities analysis and checking tools documentation generators
and code generators.
6. Diagrams checks the logical error and point these out to the user of the tool
7. Rules were embedded into the tools this needed the DFD drawn to become very
accurate and to be used guiding to actual code writing
8. Diagramming tool and the hole S/W package behaved as a tool box
9. A toolbox with a set of sophisticated tools which had a good deal of intelligence
build
10. The entire toolbox to be called Computer Aided Systems Engineering
The people who pioneered SSAD
 Perter Yourdon, Gane sarson, Jackson martinDemarco,Mellor,Hately,Ward
2 methods used SSAD very popular
i) Peter yourdon’s methods,Chris Gane and Trish Sarson’s methods
Planning: Gathering information about user problems and requirements setting
goals
Analysis: Determining the design for a selected solution,including diagrams and
dataflow
Design: Detailing the design for a selected colution, including diagrams and data
flow
5
Implementation: Building testing,instaling and tunning s/w
Maintenance: Outlinig and implementing plans tuning,correcting and enhancing
systems.
Stage
Analysis stage the data gathered is formally entered into CASE tools as DFD
the data that has been identified for mainpulation is stored in a data dictionary
File structure is recognized then we can design forms that will be displayed on screen
to enable the user to key-in data this data keyed it will be then stored in the file
Hence DFD show us how data moves in the systen CASE tool is used as very
rigid guide to the actual writing of code.
What is Data Flow Diagram:
Input Process Output
DFD are graphical models of entities that need to work together in harmony for the
systems model to work correctly, these diagram help the designer visualize the flow of
data in a manual process and how it will move in an equivalent computer process
External entity
What data has to be stored processed and converted into information in which
the data is to be stored processed and converted into information
Process
Data it can be transfrmed into processed into output data single process can be
exploded into several processes data is converted into information
Datastore
Stores the data has been processed the data that comes out of processing
General rules for drawing DFD
6
1. Any DFD leaving a process must be based on data that are input to the process
2. All DFD are named their name reflects the data flowing between to perform the
process should be an input to the process
3. Only data needed to perform the process should be an input to the process
4. Be independent of any other process in the system it should depend upon it
own input and output
5. Process are always running they do not start or stop process is always ready to
perform work
6. Output of the process can take any of the following forms
a) An input DFD with information added by the process
b) A response or change of data from dollarsto profit
c) Change of status
d) Change of content
e) Change of organization
Difference between logical DFD and Physical DFD

Logical Physical
Logical DFD are drawn keeping Physical DFD drawn with
in mind how the work is going to be done reference to who is goging to
do the work
Mainly focus on the process which will
Do the work Physical DFD has to replac the
process in the logical DFD by
the logical DFD
by the people who are doing
the process
The Physical DFD bring the human being in picture
designer is completely satisfied that the DFD
is correct and that code written based not the DFD wil work without logival
errors Intraction between the
human being of thes/w, data
entry screens are necessary
Software versus information engineering:

 Logical program design is separate from physical design
 s/w engineering supports data flow , tree structured and procedural logic
diagrams and screen report
7
 diagram include those showing entity relationship data structures,
hierarchical tree-structured decomposition, data flow dependency,
screen and report layouts and detailed program logic
How case store information

Any application will undergo an initial stage of system analysis
and design
Application stored in case
App1 App2 APP n
For any new application that is created in a case tool a sub-directory has to be
created for it this subdirectory will contain all the information that is related to
that application directory will act like a dictionary for application designer .
With in the CASE tool there is a centralized storage location this is termed as a
data dictionary
Data dictionary also track the various components of the model
It capable of displaying the graphic files as well as the textual files
Data object of the model can be classified in ten categories
1. Screens 2. Fields 3. Records 4.Diagram 5. Processes 6. Repositories’ 7.
Connectors 8.Symbols 9.Plain objects 10. Reserved object
The data dictionary also stores information of the data objects related to
their attributes data structures data elements
Data dictionary split into two parts
Definition Diagrams
Data dictionary
8
One part of the data dictionary that will store information related to the case tools it will be
stored in the system directory
The second part contains data that is stored for a project data dictionary also contain linkages
between these data objects.
Unit – II
Approach used to solve the problem statement: How to deal with a problem statement-Data
flow diagram for Payroll System-Presentation Diagram for Payroll System-sehematics of the
model-Forms-Screens-Menu Screens-Dataentry Screens-Report Output Format-Utilities.
Installation of Ubridge and Synthesis: How to use the tools in Ubridge Systhesis for case-
Installation of Ubridge Synthesis-Computer Aided Software Engineering- Getting Ubridge to
work-Setup-Assign-Housekeep-The Ubridge page.
Approach used to solve the problem statement:

1. How to deal with the problem statement :
This system has to computerized to have a better understanding of how the new computerized will
work we will have to draw a schematic model for the current system
This method of understanding the data movement can be made more simple to
understand by drawing diagrams this diagrams this diagrams which represent the data flow is called
the data flow diagram
2. Data flow system for payroll system
The data flow diagram gives a better insight for a system analyst to understand the system the DFD
help the job of the system analyst to become easier but it is very difficult to make a non computer
understand this representation.
The representation must be in a style so that the client understand it. Such types of reprentation
diagrams are called PRESENTATION DIAGRAMS
Structured chart for payroll
/
XYZ organization
HRD Department TIME OFFICE ACCOUNT

DEPARTMENT
Name Name Earning Pf
Age Dept Basic FPF
Address Div HRA Loan
Status time in DA
Qualification time out CA
Blood group date IT
ETC
9
Case study of payroll system
3. Presentation diagram for payroll system
Dealing with all types of engineering material the organization, the payroll system is computerized
successfully the strength gained from this convince you are supposed to learn the current manual
system and change it to new computerized system
1. learn how the current manual system works
2. Meet the key personnel of the organization
3. conceptualize in diagrams
4. go back and talk
5. Draw your data flow diagrams
6. Construct the table structure
7. Getting programming done
8. Implement the new system
9. Check that it functions properly
10. If any flaws found then go back to step 1
11. Makes a smooth transfer from the manual to the computer system
This presentation will not include the following
1) Hardware and software environment
2) Details and bottleneck of the current manual system
The environmental model
This is an over view of the proposed system it concentration what has to be done rather than
how is to done. The various heads are
1) an event list
2) functional decomposition diagram
3) context diagram
4) presentation diagram
5) a statement of purpose
The event list

This is required so that you can assure your client that you have understand his
current manual system fully.
4. Schematics of the model:
Main menu
Master menu
Pls
Loan
Govt
Exit me no ____ main menu
transaction
No days
10
Exit menu_______ main menu
Report menu
Payslip
Exit
Utilities mnu
Backup
Passwd
Exit
Exit menu
FORMS:
1.data type 2. Data length
To enable the programmer to do this the user data is stored in a temporary pool this temporary pool
is called FORM
This FORM or screen helps an analyst in 2 ways
1. A human being is a person who is always reluctant to change to increase the
accepatability of te new system the analyst can design forms that looks exactly
2. The problem of firing complex validationsion the user data can be solved by using
fors as the temporary pool to store data the valid data then can be picked up form the form
and can be transferred to the table
Displaying of the forms menus
1.creating fields on the form2. Positioning fields on the forms 3. Choosing the acceptable
default values for the field. 4. Chaining of screen by using fields on the form 5. Defining field
macro for the field 6. Providing help on field. 7. Providing help on the form
SCREENS:
1.main menu screen 2. Master menu screen 3.pls screen 4.loan screen 5. Govt screen 6.Transaction
menu screen. 7.do days screens 8. Exit menu screen 9. Report menu screen 10. Pay slip screen. 11.
Utilities menu screen 12. Backup screen. 13. Passwd screen.
CASE tools also provide an option to design all these data entry
screens
The total no. of screens that are to be designed can be determined from the diagrams
This will also make the documentation for the system
Thus documentation of the system cionsist of the dat aflow diagram the hierarchy of th e dat a
diagrams the system
Thus documentation of the system consist of the function of the current manual system the data flow
diagram the hierarchy of the system the presentation diagrams the screen current functioning of the
system
MENU SCREEN1.
1. Main menu screen
2. Master menu screen
3. Pls screen
4. Loan screen
5. Govt screen
6. Transaction menu screen
7. No_days screen
11
8. Exit menu screen
9. Report menu screen
10. Payslip screen
11. Utilities menu screen
12. Backup screen
13. Passwd screen
All the information regarding creation of the forms must be included when the
documentation is done
The documentation for the screens that has to be done in the payroll system is given n the
next section
Main menu
Master transaction utilities reports exit
Choice
Menu entry screen

P pls y payroll ubl
L loan y payrollubl
I govt y payrollubl
E mainmenu payroll ubl
Feid macro
Please enter
P pis master
L loan master
I govt master
E exit to main menu
Screen logic: this screen is a pull down for the master there are three master that can be accessed via
this screen
Pis master all the personal information regarding the employee will be kept in the master
Spin code
Position: row 13 column 53,width6,depth 1
Data entry screens:

A payroll system essentially bifurcates into distinct halves personal information like
Employee name:
Permanent address:
Contact Number:
Age:
Qualification:
Department name:
Divisionname:
Desigination:
12
Date of joining:
The organization:
Married:
No.of dependents:
Employeea are graded at different levels in an organization because of this you always have a
hierarchy in an organizations
Repots:
There are document like the salary register report and the salary summary report that has to
be generated every 3 month once every quarter the salary register report is forwarded to the
human resource department while the salary summary report goes to the financial accounting
department which use it for reporting the profit and loss statement
Utilitilities
Master transaction utilities reports exit
Backup
PASSWORD
Field EXIT CHOICE
Value clear to clear library
B bachup y payroll ubl
p passwd y payroll ubl
E main menuy y payroll ubl
Please enter the following
Backup
Passwd
Exit
Installation OF uBridge & Synthesis
How to use the tools in uBridge Synthesis for case
An individual case tool automates one small focused step in the life cycle process. Individual
tools fall into these general catogiries
Diagramming tools to pictorially reprecent system specification
Screen and report painters fort creating system specifications and for simple prototyping
Dictionaries information management systems and fecilities to store report and query technical and
project management system information.
Specification checking tools to ditect incomplete , syntactically incorrect ,and inconsistent
system specification
Code generators to be able to generate executable code from pictorial system specifications
Documentation generators to produce technical and user documentation required by structured
Methodologies.Prototyping tools help determine system requirements and predict perrformence
beforehand Screen dialog and navigation with entry and edits can be simulated with or without
compilers .Sorce code for record file screen and report discrptions can be generated automatically
.Also essential are executable specification languages. These are the most sophisticated prototypin
13
tools which involved specifying system requirements and executing specifications interactively to
refibnd correct and ensure completeness of the system to meet user requirements.CASE tools
essentially consist ofDiagramming section Prototyping section Code generation sectionInstallisation
of ubridge synthesisHardware requirements To instale CASE toolIBM PC/XT or true compatible
under ms-DOS ver 3.0 One floppy drive (5 ¼”,3 ½”)640 KB of RAMHard disk with at least 3 MB
of free spaceInstallation Create a dictionary,say synth
C:\>md synth
Change ypour directory to yhis directory
C:\>cd synth
Insert the first floppy in the drive and copy it in the synth directory in this way copy all the ten
floppys in the synth directory
C:\>copy a:*.* c:\synth
C:\synth\>INSTSYN
The installation program instsyn will operate for a while and give the message
“synthesis installation complete”
Computerized software is generally divided into two classes
Systems software
Commertial application software
Each class of software is developed in computer programming languages having its own
vocabulary,syntax and symantics
A great deal of preplanig has to go into the creation of such software questions arise
Did we clearly specify all our requirements?
Did the system specialist really understand what is required?
How reliable will the software developed be ?
Will it be developed ontime?
Will the software be easy to maintain ?
Will the software be clearly documented ?
Will we require special staff to run and maintain the software ?
Software is an abstract rather than a physical entity .this distinguishes it from most other engineering
product. software once designed has no continuous manufacturing phase. It needs to be maintained .
Software engineering is intended to assist the development of good quality software with in the buget
and time scale constrains today with the use of case tools all areas have been largely automated.
Computer aided software engeeniering(CASE)
Computer aided software engeeniering(CASE) is the latest technology which is healpin to produce
very relaiyable software case tools automate activities in all stages of the software devolepment life
cycle.
They are
Requirement definition
Design
Codeing
Development
Testing
Implementation
Documentation
The case tools themselves are pices of software either devolpoed in house or produced by third party
software houses and sold as property products once such product that helps automate most stages of
the software development life cycle is uBridge Synthesis.
14
CASE tools is the concept of a central repository called a data dictionary.holds all the software
system design data its diagram and documentation all related to the software under development.
CASE tools also provides a clear documentations trail to ease maintenance of the software and help
co-ordinate the development teams efforts.
Getting uBridge to work
The user interface that allows acces to the system configurations & security facilities is called the
SYSTEM MANAGER,’SYSMAN’ via this executable we can access various options that uBridge
provides.
C;/SYNTH>sysman
Access to SYSMAN executable is restricted via PASSWORD control.
When the system is loaded for the first time the password supplied is INDUS then the user interface
loaded and we have access to the various options of SYSMAN including the options of changing the
password.
The manner in which informations needs to be fed into SYSMAN is as follows:-
SETUP uBridge to work in the manner that you want.
1) The video mode in which uBridge needs to run, CGA, EGA and VGA
NOTE: A .com file needs to be run before invoking uBridge on a MGA/HGA system else the system
hangs (i.e.check installation uBridge)
2) Declare the printer port LPT1,LPT2.
Parallel or Serial and which port is declared.
3) The type of Input/Output for files
4) The type of printer driver required to work your printer.
5) CHANGE THE PASSWORD to System to one of your choice.
6) Identity the sub-directory where your favorite wordprocessor sits.
7) THE GRAFICS SET-UP
15
DEF FONT
Seveseveral type of fonts are used in ubridge while diagramming ,we have to sset up a DEFAULT
font to load when ubridge loads up,this default is defined in this window
MAX FONT
We can define the memory size used by ubridge to load fonts . large the memory size greater will be
the speed with whichubridge switches between fonts.
LABEL IMMEDIATE
While creating an OBJECT in window ubridge will ask you to name & lable then as soon as they are
created if the immediate switch is on this is a default seting thic can be changed for each window
SYSTEM LABLE
When you create a lable on a screen ubridge will always mark the label area carefully,making it
smaller then the “hot area” if this parameter is given as no then ubridge ask you to explicitly mark
the area of the lable
CONNECTOR COLOUR
We can select one of the sixteen colors for the connection between the objects on screen
The object/text set-up window:
THE OBJECT SCALE FACTOR

Object sizes in a window can can be scaled from 1to 7 with 4 being default size
TEXT SIZE:
Similerr to object text can also be scaled 1 to 5 with default being 3
OBJECT COLOUR
Object colour can be chosen from a palette of 16 colors
TEXT COLOUR
Text colour can be chosen from a palette of 16 colors
After having setup ubridge the next step is to tell the SYSMAN who will be the user of ubridge
This is done by entering the ASSIGN sub-menu system
This sub menu is brifureated in two part :
A) Where you can identify a user to the system
When you enter the user assignment screen you can add ,modify ,delete a user on the system save
and obtain help for the screen you are currently on
B) Where you identify a project and assign a user to a project
When you enter the project assignment screen you can add ,modify ,delete on your project
RELEASE:
Prevent any changes to the project data dictionary
REACTIVATE :
Aloes further changes to a project after it has been RELEASED
HOUSE KEEPING
16
On entering to a house keeping menu choice allows a user to backup and restore file from the current
sub directory concerned
This means we are now ready to begin to use ubridge capabilities for prototyping and testig to our
advantage
The ubridge page
There is a visible area on the screenon the screen on on which you work which is much less then the
actual page length
The maximum number of rows are 72
The maximum number of columns are 256
These have default setting that load up when ubridge loads up but via SYSTEM MNGEMENT
INTERFACE CHANGE SCREEN SIZE
Unit – III
Introduction to Ubridge: Introduction - Main flow of the system prototyping your Report-
Introducing the Novice Model of the Operation.Introducing Synthesis - Synthesis basic – Synthesis
- Menu Drawingthe screen-Requirement Definition-Diagram-Data Dictionary-Document-Synthesis
MainAdministration - Synthesis reference - importing and exporting screen.
INTRODUCING TO UBRIDGE
INTRODUCTION
CASE TOOLS must have an option so that the designing of the screen can be achived to do
this ubridge synthesis uses its first menu screenNow using this menu we must be able to draw our
screens.it must let us manipulate the assenthetics of the form.The form that are designed for the
payroll project suggest that we must be able to
1. draw boxes or lines

2. define simple field and table field
3. attach text to the form
4. attach default value for a field
5. stich filed validation to a field
6. chain different screen together
7. do cursor controlling
8. define the screen logic
To get started with ubridge synthesis we need to first get into the tools by keying in
17
C:\synth>synth
MAIN FLOW of the system

Use ubridge to create a screen all necessary video attributes such as bridge,flash,reverse of the screen
can be defined Here we introduce the various commands associated with screen Generation
Painting a screen
Screen libraries
Getting ascreen
Saving a screen
Placing text
Graphics
Pencil
Patterns
Visual effects
Clipping and pasteing
Undoing a mistake
MENU SCREEN
We can use the paint tool to design Menu screen,one menu screen can call another menu or data
entry type of screen this is done by aprocess called chainingDATA AS ubridge sees it In ubridge
DATA is defined as those are of the screen representing variable information .These screen can now
be defined as data entry screensMarketing a field,
Field name
Field detail
Listing field
Sequence of data entry
Deleting a field
BEILDING UP YOUR REQUIREMENT
The process of building llinks between screens is chaining.the chains thread together the different
screen you have painted into a coherent collection of requirement to build a chain we use the field
selectionlist.
press enter to select the starting point
position the highlight on the screen name you wish to select and press enter.
You can now select the execute option several options will be made available
1. current screen
2. all from current
3. specific screen
18
4. data manager
PROTOTYPING YOUR REPORTS:

We can plan a report as much as 256 columns wide wee can paint a report using the screen paint
option and acctualy define its contents. A complete report model can be created and chained to the
model system accessible via the report option of the main menu to provide realityof the model flow
INTRODUCING THE NOVICE MODE OF OPERATION:
The novice mode makes the various activities such as painting of screens defining of data chaining of
screens etc.. of ubridge. This mode thus makes a model of your system with out you having to paint
screens define data chain screens together or any othere activity that is normally required to make
such a model.
Introducing SYNTHESIS
After knowing what is uBridge, and how we can configure the system using SYMAN let's get to
known SYNTHESIS, the systems analyis and design work bench
SYNTHESIS Basics
Starting SYNTHESIS
You can run SYNTHESIS from any directory or sub-directory with the command:
<pathname>SYNTH (ENTER)
Adjusting to different Monitor types :
SYNTHESIS assumes a color monitor when you run it using the command SYNTH(Enter)
Thus if you have a monochrome monitor the resultant shades may not have adequate contrast you
can override the color usage by keying in '/B' after SYNTH:
<PATHNAME>SYNTH/B(Enter)
The SYNTHESIS Main Menu
Once you logged in through the login window of SYNTHESIS the main menu of SYNTHESIS will
be displayed
The SYNTHESIS Main Menu has the following options:
Requirement : Paint your screen and report layouts the way you see them. Describe
data that you want your system to handle.Build your vie of system.
Diagram : Gives you choice of nine standard Diagramming techniques.
19
Data Dictionary: Provides a direct data dictionary interface.
Document : Build a document based on the data dictionary.this document could be

a system document, a user manual or a plain proposal
Administrator : Use the administrator to set up colors, select a printer and access
DOS.
Quit :At theend of a session, this option will take you back to the DOS
prompt.
Drawing the screens

REQUIREMENTS DEFINTION
This option allows yor to make a requirement definition of the system analysis abs design
When You choose this option,SYNTHESIS actually calls UBridge 2.0+(which is the precursor to
SYNTHESIS) This is a requirement definition toll ehich assists you in defining your system
requirements.
At the end of the requiremment definition, ou have a modle of your system which shows you exactly
what you new system is going to do.
(B) Diagram:
The diagramming menu has the options as below:
Draw : To actually position and draw an object and to connect the

objects.
Label :To place a short textual description on an object or
connector.
Describe :To give more details about the object
Tolls : To make changes in your diagram like moving ,cut &
Paste zooming in and out, exploding and imploding
process.
Control :Display a control panel to change the font,size &color
setting.
Window :Activates the window manager.its allow you to
create .move remove & resize the window.
Administrator : Lets you get ,save load and print Diagrams
Quit: : used to exit from the diagramming menu.
(C) DATA-DICTONARY:
20
The data dictionary is a repository of details of all entities handled with in SYNTHESIS
The data Dictionary is two part:

Part 1 Data Dictionary
The first part of the data dictionary contains data that is stored of use by SYNTHESIS only.
2.Part II of the Data Dictionary

The second contains data that is stored for project.
Once you invoke DATA DICTIONARY option, you will be offered the following options:
.Direct interface: A means by which you can view, ad,modify or delete contents of data dictionary.
.Data Analysis: A facillity to help you check completeness of your diagrams.
.Reports : You can extract selective lists of specific entities in a project.
.Query : You can find out "Where all" A field of data is used and "what if "a
repository is modified
.Extract : Using the Extract facility , you can generate C and COBOL code of
data structures in your project data data dictionary.
THE DIRECT INTERFACE:
Entities in the data dictionary are handled the direct interface in three different ways:
General information is entered though the "Entity Window"this applies to all entities.
The "field" entity requires additional information that is entered through the "Field Window" after
entering the "Entity Window"
The "Record" entity requires additional information that is entered through the " Window" after
entering the "Entity Window".
21
DIAGRAM ANALYSIS:
Three types of diagram Analysis can be preformed in SYNTHESIS.
Data flow diagram analysis for ensuring completeness of a diagram.
When you invoke the option . A list of all data flow diagram stored in the dictionary will be
displayed.select for analysis. The diagram will Be Subjected to checks for ensuring completeness.
The result of a check will be out put to the output device that you select. It will either inform you that
the diagram is correct or if it is not,will list out the missing information.
Level balancing for ensuring integrity across data flow diagrams
In a dsata flow diagram, you can have a "process" that explodes to another data flow diagram. The
data flows the connected to this "process" should be accounted for in the dat flow diagram that
represents the process.
For the payroll project the output of level balancing will be like given below:
LEVELLED DATA FLOW DIAGRAMS:

When the analysis of any system is undertaken,frist abroad view of the system is obtained.once the
overall view of the system is clear.then the details can be worked out.the earlier data flow diagrams
gave only a broad view.these DFD's were referred to as first level DFD's.
To depict details each process in the first level DFD is exploded to another DFD, this DFD being
referred to as the second level DFD, showing only those details which are concerned with the
process that has been exploded.
It is completely possible that a process in the second level DFD can be further exploded.this sort of
exploding downward can continue,depending upon the complexity of the processes being described
and the actual degree to which the process needs to be described.
When a system is too large for its DFD to be shown on a single page it is partitioned into subsystems
.if the subsystem are still too large to be shows on one page they must be further divided into
subsystems and so on until a subsystem fits on one page.
The main DFD(over the view of the system) contains references to this kind of explosion .This
indicates,to the reader of the DFD, the level through which he would have to work prior being able to
see the entire system.Since each of these explosions are described by a DFD,a levelled set of DFD's
are obtained.
Leveling Conventions:-
At the topmost in the hierarchy of a levelled DFD(i.e.a DFD that has been exploded several levels
down)is the Context Analysis Diagram .this is the parent of the first level breakdown diagram in turn
is the parent to the next level of DFD(i.e. The child).this is how the levelling conventions work.
Balancing of a data flow diagram:-
Data flows into and out of a process in a parent diagram.this is the equivalent is called balancing.the
balancing rule is s follows:-
22
Ll data flows shown entering a child diagram must be represented on the parent by the same data
flow entering that process.output from the child diagram must be the same as outputs from the
associated process in the parent diagram.
There is one exception:-
Trivial rejects need not be balanced between parent and child.
The advantages of levelled data flow diagrams:-
Levelled DFD,s allow a top down approach. They help build a specification which can be red
top-down.this means a manager can restrict his reading to the top few leveles and still get the
picture.system code writers and users can read from the abstract to the detailed,narrowing in on
particular areas of interest.
Normlization
Normalization is a technique that has been developed to ensure that the data structure is efficient.it
is not the only one, but it has received widespread support and it has the advantage of not costiong
anything in terms of additional hardware and software.
.
The process was developed by E.F.Codd and it involves three stages. This has been based on
the SET theory of mathematics.
Guidelines for choosiong a Kev
1. The key must have a unique value for each occurrence of the group of data concerrned
2.the key must not repeat within a group of data (The item code does in the GRN)
3.Where the data can only be identified uniquely by a key made up of more than one data item, a
compound key, choose the least number of items.
UNF relations
Date
Grn Number
Supplier Name
Supplier Address
Order Reference
*Item code
*Description
*Rate
*Quantity
23
*Total
Discount
Grand Total
The list hs been derived from the format given above. Thstar before the data element indicates it is
repeating in the format.
First Normal Form
A record in the first normal form (FNF)does not includ any repeating groups.So removing this
from the group we get the following:
Relation 1 Relation 2
Data GRN Number
GRN Number Iterm Code
Supplier Address Description
Order Ref. Rate
Discount Quantity
Grand Total Total
Second Normal Form
With in the second normal form each field (or attribute or data item) depends on the whole key
and not on part of the key.
Relation 1 Relation 2 Relation 3

Date GRN Number Item code
GRN Number Iterm Code Description
Supplier Name Rate
Supplier Address
Order Ref. Quantity
Discount Total
Grand Total
Rule 1 Separate the Repeating Group
24
DOCUMENT:
Through the document module, you can build a complete document based on the content of the
data dictionary and the extrancous data. The documents that you can build are system proposala,
system specification, system manuals and user manuals.
Once you choosethis option, you have the following choices,
1. CREATE a document
2. MODIFY a document
3. GENERATE a document
4. Wordprocessor
On Selecting the first option, you will be asked to enter a document name and then you will be asked
whether you wish to break up the proposal into further chapters.
If you say yes, the first chapter is picked and you are asked whether you wish to break it further
into sub-chapters. Choose No. Now, you are asked to specify the sections of this chapter.
A section can either be a uBridge screen, a diagram or a text file.
Text files should be in ADCII format and can be either:
Word processor outputs
Reports generated using the "Diagram Analysis",

"Query" or "Report" facilities
Report generated using the uBridge 'print Document' fcility
All text files designated as section must be present in the user Directory and must have the extension
'TXT'.
The "Introduction" chapter would contain the following section ;
1.INTROI.TXT :A text file that explains the objectives of the system.
25
2.Stores Interaction :A presentation diagram that shows the human interaction involved in the
stores system. .
3. INTRO2.TXT :A text file that explains the overviews of the system.
The other chapter can be broken up in to sub chapter that themselves. Can contain sections.
Then you proceed with entering the section details.
Key in: INTRO1.TXT
You are asked to select either T for text, S for screen or D for Diagram.
Enter this information about all the sections in a similar manner
The document definition provided by you is stored in a document iibrary.
1. EXPLODE:
Definition:
The explode command lets you decribe a pocess, data flow, connector or repository in detail as
another diagram, record or screen. The implode command does the reverse of the explde command.
2. FIELD:
Definition
A field is data element that cannot be broken or exploded into further element
3.PRINT DIAGRAM:
Definition
Within Diagramming you can print either a complete diagram or part of a diagarm, using the
administrator.
4. TOOLS:
Definition
Tools are provided diagramming to let oyu edit your diagram, zoom in and explode to another
diagra.
5. CUT
You can cut a block of objects from a diagram. In doing so, the objects and their internal
connector get deleted from the diagram and inserted in the cut-clipboard will be overwritten by the
next cut or object move. All connectors that pass through the selected area and terminate or start
from with in the selected area will be deleted in a cut. These connectors may be recovered.
6. PASTE:
The contents of the cut- clipboard can be pasted any where in the diagram where it was cut from,
or in any other diagramming window, provided the diagramming methodology used in the active
window is the same as the one used in the window where the last cut or move object was performed.
26
The way uBridge flow:-
uBridge the prototyping tool:
Design Screens
Menu
Screen
Data Entry Screens
Define Fields
Define Field Validations
Design Report Formats
Chain the above in the manner that you desire, and run the model.
IMPORTING AND EXPORTING SCREENS
Using the interface option to import text to draw screens
Introduction:-
If you have drawn your screens using some other editor then it is also possible to transfer the
screens to the uBridge requirement tool. The only restriction that the file in which you have drawn
your screens must be a pure ASCU file.
Say you have drawn a screen using wordstar as shown below.
The character like'----' 'll' '=' etc, or nor ascii values. Convert this files an ASCII files by printing files
by printing it on an ASSCII printer.This will convert the file shown below
Select(F2) End(F3)
To transfer this screen follow the given flow
UNIT IV
Diagram definition tool: Introduction-Starting DDT-Drawing your own Icon - Defining the
connection rules-Rebuilding your icon. Object oriented methodologies: Rumaugh Et.Al‘s object
27
modeling techniques-The Booch methodology –The Jacobson Et.Al Methodologies-Pattern-Frame
works-The Unified Approach.
DIAGRAM DEFINITION TOOL
INTRODUCTION
It is also to create own rules for drawing the data flow diagrams,drawn using the standard
methodologies by Gane and sarson.Peter Yourdon etc.
The user modify the systems to suit his/her requirements.This can be achieved by using the
Diagram Definition Tool provided by ubridgesynthesis.ubridge synthesis can create new icons or
diagrams.
If you take a listing synthesis Home directory ,it will show an executable
ddt.exe.Whenubridge is installed there is a file called DDT.EXE which will let to draw you your
own diagrams and icons.
DDT works on CGA,EGA,VGA and Hercules graphics monitors.the following files are
present in the systems directory.
1. DDT.EXE
2. UBCOLOR.UBE
3. UBHELP.UBE
4. UBINDX.UBE
5. UCDATA.UBE
The file UCDATA.UBE will be modified during DDT interaction.It is suggested that you make a
back up copy o this file before using DDT so that an accidental corruption of the file due to incorrect
interaction can be avoided.
STARTING DDT
28
At the dos prompt key-in as follows
C:\synth>ddt
This will call the executable from the synthesis home directory.The main screen will open up which
is as follows
uBridge Synthesis Diagram Definition Tool Ver 1.0
Object Diagram Administrator
Object: diagram
Diagram DDT opening screen
Select the administrator option.This option will let you create new diagrams modify existing diagram
etc.The screen will open up as follows.
New Object/Diagram
Get Object
Save Object
Get Diagram
Save Diagram
Quit
Status:
29
Since we want to create a new diagram select the option New object/Diagram.the screen that opens
up is as follows.
Diagram Name: rukmini
Diagram Descrition: RukminiGane&Sarson
Manual Connection :No Overlap Connection: No
Iconobject list connector listsymbol list
Ok cancel help
Status:
User want to specify the Diagram name ,DiagramDescription,Manual Connection and the
Overlap Connection.
DRAWING YOUR OWN ICON
User can create own DFD, user will first create own icon.and then draw the own icon
,choose the icon option.
30
Diagram Name: rukmini
Icon window
D
Icon Label : rukus Hot key:u
Icon Draw
M
Ok cancel help
I
User have to specify a label to this icon .this will be automatically attached to the icon that user will
create.after specifying the icon label select icon drawoption .this will put you in the following
screen.
Connector anchor hotarea grid setolor quit
Line
Circle
Arc
Prev
Next
31
Last
First
Delete
Redraw do you want to save changes? (y/n)
zap
use any or all the option that are available to you and draw an icon the way you like .so after drawing
the icon the screen will look as follows.
Connector anchor hotarea grid setolor quit
Line
Circle
Arc
Prev
Next
Last
First
Delete do you want to save changes? (y/n)
Redraw
zap
Do the desired diagram and save your diagram by selecting the Quit option that is given
above. You will return back to the previous screen,i.e
32
Object diagram administrator
Diagram name: rukmini
Diagram Description: Rukmini”s Gane & Sarson
Manual Connection : No Overlap Connection : No
Icon Object List Connector List Symbol List
Ok Cancel Help
You would like to have different objects in your DFD. Select the Object List Button and the
following screen will appear
Diagram name: rukmini Add
Object name list Diagram Object List
External entity GS
33
External Entity YD Modify
Process G&S
Process Y/D
Data Store G&S
Data Store Y/D Delete
Off Page
OK Cancel Help
Status: Diagram: rukmini
The Object Name List will show you all the objects that are available to you. Choose the object that
you want and click the add menu.
Say, you choose External Entity Gane & Sarson from the Object Name List, select the add button
then a screen will appear as follows:
Add Object Window
Object name: External Entity G&S
Explosion Rule Connection Rule
Ok Cancel Help
34
DEFINING THE CONNECTION RULES
For any object that you will select, the Explosion Rule & Connection Rule must be
specified. First select the Explosion rule menu. A pop up window opens up as follows.
Explosion Rule Window
Object name: External Entity G&S
Object name list Exploded Name List
Screen
Record Add
DFD Gane & Sarson
DFD Yourdon
Data Model
ERD Chen Delete
ERD Merise
OK Cancel Help
35
Here since the External Entity cant be exploded, we are not giving any Explosion name List.
You will have to select the object from the Object Name List and select the add menu to add it to the
Exploded Name List. After you have finished, select the ok button to return back to the previous
screen,
As per the default method, process can be exploded into DFD Gane & Sarson, Structure Chart,
Diagram and screen.
Data store can be exploded into a record and so on.
Similarly for each of the Object List it will ask for Explosion Rule and the Connection Rule.
36
After completing the process , select the ok menu to get your change accepted.
Diagram name: rukmini Add
Object name list Diagram Object List
External entity G&S External entity GS
External Entity YD Process G&S Modify
Process G&S Data Store G&S
Process Y/D Off Page
Data Store G&S Report(Pres)
Data Store Y/D Delete
Off Page
OK Cancel Help
Status: Diagram: rukmini
This will take you back to the screen where we started defining our new object or diagram. The
screen is as follows.
37
Object diagram administrator
Diagram Description: Rukmini”s Gane & Sarson
Manual Connection : No Overlap Connection : No
Icon Object List Connector List Symbol List
Ok Cancel Help
Select the Connection List menu to define the type of connection you want. On selection of this
menu the following pop up window will appear.
uBridge Synthesis Diagram definition Tool Ver 1.0
Diagram Connector window
Connector Name List Diagram Connector List
Slant arrow straight arrow Add
Slant line
Straight line Modify
Straight arrow
Double arrow Delete
Double headed arrow
38
One to many
Ok cancel Help
Select the connector name from the Connector Name, List and choose the Add menu to
add that connector to the Diagram Connector List. When you choose the add menu to the following
pop up opens up on the screen as follows.
This will pick up the connector type from the name that you have selected. You will have to specify
the Connector Type that you have selected.
The window that opens up is as follows.
uBridge Synthesis diagram Defintion Tool Ver 1.0
Add Connector Window
Connector type: straight arrow
Connector Name: st_arr Hot key: s
Expansion Rule
Ok Cancel Help
39
Now you will have to specify the Expansion Rule menu and the following pop p window
opens up as follows
Object name list Connector Expand List
Screen Record
record Add
DFD Gane & Sarson
DFD Yourdon
Data Model
ERD Chen Delete
Structure Diagram
Erd Merise
OK Cancel Help
Select the name from the Object Name List and then select the Add menu. This will add the
entry in the Connector Expand List. After having finished this, select the Ok menu to accept
your changes and return back to main screen.
The main screen is as follows
40
uBridge Synthesis Diagram Definition tool Ver 1.0
New object/diagram
Get Object
Save Object
Get Diagram
Save Diagram
Quit
Status:
REBUILDING YOUR ICON
Now, select the save diagram option to save the new Diagram. This will Display a message to
you on the screen as follows
Clearing screen to build icon press any key……
After the new diagram is saved, select the Quit option and come to the prompt, i.e
C:\synth>
The new icon that was drawn right now must be built in the system so that it will be accessible.
To do this run the iconmake.exe so that whatever icon you have drawn can be actually accesed.
41
At the prompt key-in the following
C:\|synth>iconmake
This will rebuld the icon and will be incorporated in the diagram definition tool.
When you will select Diagrams from the main menu of u?Bridge Synthesi, it will show you the
icon that you have connected along with the label. This is how you create your own Diagram
Defintion.
Introduction: too many methodologies:
In 1980’s many methodology were wondering how analysis and design methods and
processes would fit into the object oriented world and Techniques to help people execute
good analysis and design.
1. 1986, Booch developed object-oriented design concept.

2. 1987, Sally Shlaer and Steve Mellor created the concept of the recursive design approach.
3. 1989, Beck and Cunningham produced class-responsibility-collaboration cards.
4. 1990, Wirfs-Broke, Wilkerson, and Wiener came up with responsibility driven design,
5. 1991, Jim Rumbaugh led a team at the research labs of general electric to develop the object
modeling technique.
6. 1991 peter code and ED Yourdon developed the code lightweight and prototype-oriented
approach to methods.
7. 1994, Ivan Jacobson introduced the concept of the use case and object oriented software
engineering.
The trend in object-oriented methodologies, sometimes called second-generation object-
oriented methods.
4.2 SURVEY OF SOME OF THE OBJECT-ORIENTED METHODOLOGIES
42
Each methodology has its own strengths.
 The Rumbaugh et al method is well studied for describing the object model or the static
structure of the system
 The Jacobson et al is good for producing user-driven analysis models.
 The Booch method produces detailed object-oriented design models.
4.3 RUMBAUQH ET AU'S OBJECT MODELING TECHNIQUE
The object modeling technique (OMT) presented by Jim Rumbaugh and his coworkers
describes a method for the analysis, design, and implementation of a system using an object-
oriented technique. OMT is a fast, intuitive approach for identifying and modeling all the objects
making up a system.
Details such as class attributes, method, inheritance, and association also can be
expressed easily. The dynamic behavior of objects within a system can be described using the
OMT dynamic model.
This model lets you specify detailed state transitions and their descriptions within a
system. Finally, a process description and consumer-producer relationships can be 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 results are a structure of the basic architecture of the system along
with high-level strategy decisions
3. Object design. This phase produces a design document, consisting of detailed objects
static, dynamic, and functional models
4. Implementation. This activity produces reusable, extendible, and robust code.
OMT separates modeling into three different parts:
1. An object model, presented by the object model and the data dictionary.
43
2. A dynamic model, presented by the state diagrams and event flow diagrams.
3. A functional model, presented by data flow and constraints.
4.3.1 The Object Modal
The object model describes the structure of objects in a system: their identity, re-
lationships to other objects, attributes, and operations. The object model is represented
graphically with an object diagram (see Figure 4-1).
The object diagram contains classes interconnected by association lines. Each

class represents a set of individual objects. The association lines establish relationships among
the classes.
Client
First name client account account
Lastname number transaction
Pincode balance account transdate
Deposit transaction transtype
Withdraw amount
create transaction postbalance
checking account
withdraw checking savings account
Savings account
44
4.3.2 The OMT Dynamic Model
OMT provides a detailed and comprehensive dynamic model, in addition to letting

you depict states, transitions, events, and actions. The OMT state transition diagram is a
network of states and events (see Figure 4-2). Each state receives one or more events, at which
time it makes the transition to the next state. The next state depends on the current state as well
as the events.
Account has
Nothing is
been selected
Selected checking or Select checking

savings account
Select transaction type Enter the

(withdraw,deposit,transfer amount
confirmation
45
4.3.3 The OMT Functional Modal
The OMT data flow diagram (DFD) shows the flow of data between different
processes in a business. An OMT DFD provides a simple and intuitive method for describing
business processes without focusing on the details of computer systems [31.
Data flow diagrams use four primary symbols:
1. The process is any function being performed; for example, verify Password or PIN in the ATM
system (see Figure 4-3).
2. The dataflow shows the direction of data element movement; for example, PIN code.
3. The data store is a location where data are stored; for example, account is a data store in the
ATM example.
4. An external entity is a source or destination of a data element; for example, the ATM card
reader.
Overall, the Rumbaugh et al. OMT methodology provides one of the strongest tool sets for
the analysis and design of object-oriented systems.
46
legend
process data store dataflow external entity
FIQURE 4-3
OMT DFD of the ATM system. The data flow Hoes Include arrows to show the direction of
data element movement The circles represent processes. The boxes represent external entities.
A data store reveals the storage of data.
1.4 THE BOOCH METHODOLOGY
47
The Booch methodology is a widely used object-oriented method that helps you
design your system using the object paiadigm. It covers the analysis and design phases of an
object-oriented system.
Booch sometimes is criticized for his large set of symbols. Even though Booch
defines a lot of symbols to document almost every design decision, if you work with his method,
you will notice that you never use all these symbols and diagrams. You start with class and object
diagrams (see Figures 4-4 and 4-5) in the analysis phase and refine these diagrams in various
steps.
Only when you are ready to generate code, do you add design symbols— and
this is where the Booch method shines, you can document your
object-oriented code.
The Booch method consists of the following diagrams:
 Class diagrams
 Object diagrams
 State transition diagrams
 Module diagrams
 Process diagrams
 Interaction diagrams
The Booch methodology prescribes a macro development process and a micro development
process.
4.4.1 The Macro Development Process
 The macro process serves as a controlling framework for the micro process and can
take weeks or even months. The primary concern of the macro process is technical
management of the system.
 Such management is interested less in the actual object-oriented design than in how well
the project corresponds to the requirements set for it and whether it is produced on time.
48
In the macro process, the traditional phases of analysis and design to a large extent are
preserved [4]. The macro development process consists of the following steps:
1. Conceptualization. During conceptualization, you establish the core requirements of the
system. You establish a set of goals and develop a prototype to prove the concept.
2. Analysis and development of the model. In this step, you use the class diagram to describe the
roles and responsibilities objects arc to carry out in performing
the desired behavior of the system. Then, you use the object diagram to describe the desired
behavior of the system in terms of scenarios or, alternatively, use the interaction diagram to
describe behavior of the system in terms of scenarios.
3. Design or create the system architecture. In the design phase, you use die class diagram to decide
what classes exist and how they relate to each other. Next, you use the object diagram lo decide
what mechanisms are used to regulate how objects collaborate.
the module diagram to map out where each class and object should be declared. Finally,
you use the process diagram to determine to which processor to allocate a process. Also,
determine the schedules for multiple processes on each relevant processor.
49
FIGURE A
Object modeling using Booch notation. The arrows represent specialization; lor example, the
class Taurus Is subclass of the class Ford.
4. Evolution or implementation. Successively refine the system through many iterations. Produce a
stream of software implementations (or executable releases), each of which is a refinement of
the prior one.
5. Maintenance. Make localized changes to the system to add new requirements and eliminate
bugs.
4.4.2 The Micro Development Process
50
Each macro development process has its own micro development processes. The micro process
is a description of the day-to-day activities by a single or small group of software developers,
which could look blurry to an outside viewer, since the analysis and design phases are not
clearly defined.
Operator turnoffAlaram
Silenced
sounding
Enable disable
Disabled
Alaramfixed
Diagram: an alarm class state transition diagram with booch notation.this diagram can capture
the state of a class based on a stimulus.
The micro development process consists of the following steps:
1. Identify classes and objects.

2. Identify class and object semantics.
51
3. Identify class and object relationships.
4. Identify class and object interfaces and implementation.
4.5 THE JACOBSON ET AL. METHODOLOGIES
The Jacobson el al. methodologies (e.g., object-oriented Business Engineering (OOBE),

object-oriented Software Engineering (OOSE), and Objectory) cover the entire life cycle and
stress traceability between the different phases, both forward and backward.
This traceability enables reuse of analysis and design work, possibly much bigger factors
in the reduction of development time than reuse of code. At the heart of their methodologies is
the use-case concept, which evolved with Objectory (Object Factory for Software
Development).
4.5.1 Use Cases
Use cases are scenarios for understanding system requirements. A use case is an interaction
between users and a system.
Library
Checking out books
Getting an interlibrary loan
Doing research
member
Reading books, newspaper
Purchasing supplies
52
supplier
Diagram A: some uses of a library
The use-case model captures the goal of the user and the responsibility of the system to its
users . (Diagram A)
In the requirements analysis, the use cases are described as one of the following [4]:
• Nonformal text with no clear flow of events.

• Text, easy to read but with a clear flow of events to follow (this is a recom mended style).
• Formal style using pseudo code.
The use case description must contain
• How and when the use case begins and ends.

• The interaction between the use case and its actors, including when the interaction occurs and
what is exchanged.
• How and when the use case will need data stored in the system or will store data in the system.
• Exceptions to the flow of events.
53
• How and when concepts of the problem domain are handled.
Every single use case should describe one main flow of events. An exceptional or
additional flow of events could be added. The exceptional use case extends another use case to
include the additional one.
The use-case model employs extends and uses relationships.The extends relationship is
used when you have one use case that is similar to another use case but docs a bit more. In
essence, it extends the functionality of the original use case (like a subclass). The uses
relationship reuses common behavior in different use cases.
Use cases could be viewed as concrete or abstract. An abstract use case is not complete
and has no actors that initiate it but is used by another use case. This inheritance could be used in
several levels. Abstract use cases also are the ones that have uses or extends relationships.
4.5.2 Object-oriented Software Engineering: Objectory
Object-oriented software engineering (OOSE), also called Objectory, is a method of

object-oriented development with the specific aim to fit the development of large, real-time
systems.
The development process, called use-case driven development, stresses that use cases
are involved in several phases of the development (see Diagram B), including analysis, design,
validation, and testing. The use-case scenario begins with a user of the system initiating a
sequence of interrelated events.
The system development method based on OOSE, Objectory, is a disciplined process for
the industrialized development of software, based on a use-case driven design. It is an approach
to object-oriented analysis and design (hat centers on understanding the ways in which a system
actually is used.
54
By organizing the analysis and design models around sequences of user interaction and
actual usage scenarios, the method produces systems that are both more usable and more robust,
adapting more easily to changing usage.
Jacobson et al.'s Objectory has been developed and applied to numerous application areas
and embodied in the CASE tool systems.Objectory is built around several different models:
• Use case-model. The use-case model defines (he outside (actors) and inside (use case) of the
system's behavior.
• Domain object model. The objects of the "real" world are mapped into the domain object
model.
• Analysis object model. The analysis object model presents how the source code
(implementation) should be carried out and written.
• Implementation model. The implementation model represents the implementation of the
system.
• Test model. The test model constitutes the test plans, specifications, and reports.
Use case model
Express in
Tested in
structured implemented
Ok
Not ok
55
domain object analysis design implementation testing
model model model model model
Diagram B : the use-case model is considered in every model and phase.
The maintenance of each model is specified in its associated process. A process is created
when the first development project starts and is terminated when the developed system is taken
out of service.
4.5.3 Object-Oriented Business Engineering
Object-oriented business engineering (OOBE) is object modeling at the enterprise level. Use
cases again are the central vehicle for modeling, providing traceability throughout the software
engineering processes.
• Analysis phase. The analysis phase defines the system to be built in terms of the problem-domain
object model, the requirements model, and the analysis model.
The analysis process should not take into account the actual implementation en-
vironment. This reduces complexity and promotes maintainability over the life of die system,
since die description of die system will be independent of hardware and software requirements.
In t heir view, a full development of the domain model will not localize changes and
therefore will not result in die most "robust and extensible structure." This model should be
developed just enough to form a base of understanding for the requirements model.
56
The analysis process is iterative but the requirements and analysis models should be
stable before moving on to subsequent models. Jacobson et al. suggest that prototyping with a
tool might be useful during this phase to help specify user interfaces.
• Design and implementation phases. The implementation environment must be identified for the
design model. This includes factors such as Database Management System (DBMS),
distribution of process, constraints due to the programming language, available component
libraries, and incorporation of graphical user interface tools.
It may be possible to identify the implementation environment concurrently with analysis.
The analysis objects are translated into design objects that fit the current implementation
environment.
• Testing phase. Finally, Jacobson describes several testing levels and techniques. The levels
include unit testing, integration testing, and system testing.
4.6 PATTERNS
An emerging idea in systems development is that the process can be improved sig-
nificantly if a system can be analyzed, designed, and built from prefabricated and predefined
system components.
One of the first things that any science or engineering discipline must have is a
vocabulary for expressing its concepts and a language for relating them to each other.
Therefore, we need a body of literature to help software developers resolve commonly
encountered, difficult problems and a vocabulary for communicating insight and experience
about these problems and their solutions.
The use of design patterns originates in the work done by a building architect named
Christopher Alexander during the late 1970s. Alexander wrote two books, A Pattern Language
57
[1J and A Timeless Way of Building [2] that, in addition to giving examples, described his
rationale for documenting patterns.
Alexander's articulation on pattern work was soon employed by object-oriented thinkers

looking for ways to describe commonly occurring design solutions and programming paradigms.
As described in their seminal work in cataloging program design concepts. Gamma, Helm,
Johnson, and Vlissides |15] say that the design pattern
Identifies the key aspects of a common design structure that make it useful for creating a
reusable object-oriented design. [Furthermore, it] identifies the participating classes and instances, their
roles and collaborations, and the distribution of responsibilities.
It describes when it applies, whether it can be applied in view of other design constraints, and the
consequences and trade-offs of its use.
Currently, patterns are being used largely for software architecture and design and, more
recently, for organizations, specification models, and many other aspects of software
development processes.
The main idea behind using patterns is to provide documentation to help categorize and
communicate about solutions to recurring problems.
The pattern has a name to facilitate discussion and the information it represents. A definition
that more closely reflects its use within the patterns com
A pattern is (an) instructive information that captures the essential structure and insight of a successful
family of proven solutions to a recurring problem that arises within a certain context and system of
forces.
The documentation of a pattern, in essence, provides the contexts under which it is suitable
and the constraints and forces that may affect a solution or its consequences.
Communication about patterns is enabled by a vocabulary that describes the pattern and its
related components such as name, context, motivation, and solution.
58
By classifying these components and their nature (such as the structural or behavioral nature
of the solution), we can categorize patterns.
A pattern involves a general description of a solution to a recurring problem bundle with

various goals and constraints. But a pattern does more than just identify a solution,
It also explains why the solution is needed. For better or for worse. However, the meteoric rise
in popularity of software patterns frequently has caused them to be overhyped.
Patterns have achieved buzzword status: It is immensely popular to use the word pattern to
garner an audience. However, not every solution, algorithm, best practice, maxim, or heuristic
constitutes a pattern (one or more key pattern ingredients may be absent). Even if something
appears to have
all the requisite pattern components, it should not be considered a pattern until it has been
verified to be a recurring phenomenon (preferably found in at least three existing systems; this
often is called the rule of three). A "pattern in waiting," which is not yet known to recur,
sometimes is called a proto-pattern.
Many also feel it is inappropriate to decisively call something a patient until it has undergone
some degree of peer scrutiny or review [5]. Coplien [12] explains that a good pattern will do the
following:
• It solves a problem. Patterns capture solutions, not just abstract principles or strategics.
• It is a proven concept. Patterns capture solutions with a track record, not theories or speculation.
• The solution is not obvious. The best patterns generate a solution to a problem indirectly—a
necessary approach for the most difficult problems of design.
• It describes a relationship. Patterns do not just describe modules, but describe deeper system
structures and mechanisms.
• The pattern has a significant human component. All software serves human comfort or quality
of life; the best patterns explicitly appeal to aesthetics and utility.
The majority of the initial patterns developed focus on design problems and still design
patterns represent most solutions. However, more recent patterns encompass all aspects of
59
software engineering, including development organization, the software development process,
project planning, requirements engineering, and software configuration management.
4.6.1 Generative and Nongenerative Patterns
Generative patterns are patterns that not only describe a recurring problem, they can
tell us how to generate something and can be observed in the resulting system architectures
they helped shape.
Nongenerative patterns are static and passive: They describe recurring phenomena
without necessarily saying how to reproduce them.
We should strive to document generative patterns because they not only show us the
characteristics of good systems, they teach us how to build them. Alexander explains that the
most useful patterns are generative.
These patterns in our minds are. more or less, menial images of (he patterns in he world:
they are abstract representations of the very morphological rules which define the patterns in the
world. However, in one respect they are very different.
The patterns in the world merely exist. Bui the same patterns in our minds are dynamic. They
have force. They arc generative. They tell us what to do; they tell us how we shall, or may.
generate them; and they tell us too. that under certain circumstances, we must create them.
Alexander wants patterns, and especially pattern languages, to be capable of generating

whole, living structures. Part of the desire to create architectures that
Emulate life lies in die unique ability of living things to evolve and adapt to their ever-
changing environments (not only for the sake of individual survival but also for survival of the
species). Alexander wants to impart these same qualities into his architecture.
60
Similarly, in software, good software architecture is all about being adaptable and resilient to
change. So another aspect of generativity is about striving to create "living" architecture capable
of dynamically adapting to fulfill changing needs and demands.
The successive application of several patterns, each encapsulating its own problem and forces,
unfolds a larger solution, which emerges indirectly as a result of the smaller solutions. It is die
generation of such emergent behavior that appears to be what is meant by generativity.
In this fashion, a pattern language should guide its users to generate whole architectures that
possess die quality.
4.6.2 Patterns Template
Every pattern must be expressed "in die form of a rule [template] which establishes a
relationship between a context, a system of forces which arises in that context, and a
configuration, which allows these forces to resolve themselves in mat context" [2J.
Currently, several different pattern templates have been defined mat eventually will represent a
pattern. Despite this, it is generally agreed dial a pattern should contain certain essential
components. The following essential components should be clearly recognizable on reading a
pattern :
* Name. A meaningful name. This allows us to use a single word or short phrase to refer to the
pattern and the knowledge and structure it describes.
Good pattern names form a vocabulary for discussing conceptual abstractions. Sometimes, a
pattern may have more than one commonly used or recognizable name in the literature.
In this case, it is common practice to document these nicknames or synonyms under the
heading of aliases or also known as. 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. Often the forces oppose these objectives as well as
each other.
61
• Context. The preconditions under which the problem and its solution seem to recur and for which
the solution is desirable. This tells us the pattern's applicability. 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 conflict with
one another and with the goals we wish to achieve (perhaps with some indication of their
priorities).
A concrete scenario that serves as the motivation for the pattern frequently is employed
(sec also Examples). Forces reveal the intricacies of a problem and define the kinds of trade-offs
that must be considered in the presence of the tension or dissonance they create. A good pattern
description should fully encapsulate all the forces that have an impact on it.
* Solution. Static relationships and dynamic rules describing how to realize the desired
outcome. This often is equivalent to giving instructions that describe how to construct
the necessary products. The description may encompass pictures, diagrams, and prose
that identify the pattern's structure, its participants, and their collaborations, to show
how the problem is solved. The solution should describe not only the static structure but
also dynamic behavior.
The static structure tells us the form and organization of the pattern, but often the
behavioral dynamics is what makes the pattern "come alive." The description of the pattern's
solution may indicate guidelines to keep in mind (as well as pitfalls to avoid) when attempting a
concrete implementation of the solution. Sometimes, possible variants or specializations of the
solution are described as well.
* 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; and the resulting
context left in its wake. Examples help the reader understand the pattern's use and
applicability. Visual examples and analogies often can be very useful.
62
An example may be supplemented by a sample implementation to show one way the
solution might be realized. Easy-to-comprehend examples from known systems usually are
preferred.
* Resulting context. The state or configuration of the system after the pattern has been
applied, including the consequences (both good and bad) of applying the pattern, and
other problems and patterns that may arise from the new context.
It describes the postconditions and side effects of the pattern. This is sometimes called a
resolution of forces because it describes which forces have been resolved, which ones remain
unresolved, and which patterns may now be applicable.
Documenting the resulting context produced by one pattern helps you correlate it with
the initial context of other patterns (a single pattern often is just one step Inward accomplishing
some larger task or project
• Related patterns. The static and dynamic relationships between this pattern and others within the
same pattern language or system. Related patterns 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.
Such patterns might be predecessor patterns whose application leads to this pattern,
successor patterns whose application follows from this pattern, alternative patterns that describe a
different solution to the same problem but under different forces and constraints, and
codependent patterns that may (or must) be applied simultaneusly with this pattern.
• Known uses. The known occurrences of the pattern and its application within existing systems.
This helps validate a pattern by verifying that it indeed is a
proven solution to a recurring problem. Known uses of the pattern often can serve as
instructional examples (see also Examples).
Although it is not strictly required, good patterns often begin with an abstract that provides a
short summary or overview. This gives readers a clear picture of the pattern and quickly
informs them of its relevance to any problems they may wish to solve (sometimes such a
63
description is called a thumbnail sketch of the pattern, or a pattern thumbnail). A pattern should
identify its target audience and make clear what it assumes of the reader.
4.6.3 AntIpattarns
A pattern represents a "best practice," whereas an antipattern represents "worst practice" or a

"lesson learned." Antipatterns come in two varieties:
• Those describing a bad solution to a problem that resulted in a bad situation.

• Those describing how to get out of a bad situation and how to proceed from there to a good
solution.
Antipatterns are valuable because often it is just as important to see and understand bad
solutions as to see and understand good ones. Coplien explains that
The study of anti-patterns is an important research activity.
The presence of "good" patterns in a successful system is not enough; you also must show that
those patterns are absent in unsuccessful systems. Likewise, it is useful to show the presence of certain
patterns (anti-patterns) in unsuccessful systems, and their absence in successful systems.
64
4.6.4 Capturing Patterns
Writing good patterns is very difficult, explains Appleton [5]. Patterns should pro-
vide not only facts (like a reference manual or users' guide) but also tell a story that
captures the experience they are trying to convey.
A pattern should help its users comprehend existing systems, customize systems to
fit user needs, and construct new systems. The process of looking for patterns (o document is
called pattern mining (or sometimes reverse archilecting). An interesting initiative started
within the software community is to share experience with patterns and develop an ever-
growing repository of patterns.
People can contribute new solutions, lessons learned (or antipatterns), and more
examples within a variety of contexts.
How do you know a partern when you come across one? The answer is you do not always
know. You may jot down the beginning of some things you think are patterns, but it may turn
out that these are not patterns at all, or they are only pieces of patterns, simply good
principles, or general rules that may form part of the rationale for a particular pattern. It is
important to remember that a solution in which no forces are present is not a pattern .
These guidelines are summarized from Buschmann :
• Focus on practicability. Patterns should describe proven solutions to recurring problems

rather than the latest scientific results.
• Aggressive disregard of originality. Pattern writers do not need to be the original inventor
or discoverer of the solutions that they document.
• Nonanonymous review. Pattern submissions are shepherded rather than reviewed. The
shepherd contacts the pattern authors) and discusses with him or her how the patterns
might be clarified or improved on.
• Writers' workshops instead of presentations. Rather than being presented by the individual
authors, the patterns are discussed in writers' workshops, open forums where all attending
seek to improve the patterns presented by discussing what they like about them and the
areas in which they are lacking.
65
• Careful editing. The pattern authors should have the opportunity to incorporate all the
comments and insights during the shepherding and writers' workshops before presenting the
patterns in their finished form.
UML is becoming the universal language for modeling systems; it is intended to be
used to express models of many different kinds and purposes, just as a programming
language or a natural language can be used in many different ways.
The UML has become the standard notation for object-oriented modeling systems.
It is an evolving notation that still is under development. The UA uses the UML to describe
and model the analysis and design phases of system development .
4.7 FRAMEWORKS
Frameworks arc a way of delivering application development patterns to support best

practice sharing during application development—not just within one company, but across
many companies—through an emerging framework market. This is not an entirely new
idea. Consider the following :
• An experienced programmer almost never codes a new program from scratch— she'll use
macros, copy libraries, and template like code fragments from earlier programs to make a
start on a new one. Work on the new program begins by filling in new domain-specific code
inside the older structures.
• A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new data model from scratch— he'll have a selection of
model fragments that have been developed over lime to help new modeling projects hit the
ground running. New domain-specific terms will be substituted for those in his library
models.
A framework is a way of presenting a generic solution to a problem that can be
applied to all levels in a development . However, design and software frameworks are the
most popular. A definition of an object-oriented software framework is given by Gamma et
al. :
66
A framework is a set of cooperating classes that make up a reusable design for a
specific class of software. A framework provides architectural guidance by partitioning the
design into abstract classes and defining their responsibilities and collaborations.
A developer customizes a framework to a particular application by subclassing and

composing instances of framework classes. The framework captures the design decisions
that are common to its application domain. Frameworks thus emphasize design reuse over
code reuse, though a framework will usually include concrete subclasses you can put to work
immediately.
A single framework typically encompasses several design patterns. In fact, a

framework can be viewed as the implementation of a system of design patterns.
Even though they are related in this manner, it is important to recognize that frameworks and
design patterns are (we distinctly separate beasts): A framework is executable software,
whereas design patterns represent knowledge and experience about software.
In this respect, frameworks are of a physical nature, while patterns arc of a logical
nature: Frameworks are the physical realization of one or more software pattern solutions;
patterns are the instructions for how to implement those solutions.
Gamma et al. describe the major differences between design patterns and frameworks as
follows :
• 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.
In contrast, design patterns have to be implemented each time they are used. Design
patterns also explain the intent, trade-offs, and consequences of a design.
• 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. In contrast, design patterns can be used in nearly any kind of application.
67
While more specialized design patterns are certainly possible, even these would not dictate
an application architecture.
4.8 THE UNIFIED APPROACH
The approach promoted in this book is based on (he best practices that have proven
successful in system development and, more specifically, (he work done by Booch,
Rumbaugh, and Jacobson in their attempt to unify their modeling efforts.
The unified approach (UA) establishes a unifying and unitary framework around
their works by utilizing the unified modeling language (UML) to describe, model, and
document the software development process.
The idea behind the UA is not to introduce yet another methodology. The main
motivation here is to combine the best practices, processes, methodologies, and guidelines
along with UML notations and diagrams for better understanding object-oriented concepts
and system development.
The unified approach to software development revolves around (but is not limited to) the
following processes and concepts (Diagram A). The processes are:
Use-case driven development
Object-oriented analysis
Object-oriented design
Incremental development and prototyping
Continuous testing
68
Diagram A : the process and components of the unified approach
The methods and technology employed include
Unified modeling language used for modeling
Layered approach
Repository for objects-oriented system development patterns and framework
Component –based development.
69
The UA allows iterative development by allowing you to go back and forth
between the design and modeling or analysis phases.it makes backtracking very easy and
departs from the linear waterfall process,which allows no form of backtracking.
4.8.1Object oriented analysis
Analysis is the process of extracting the needs of a system must so to satisfy the users
requirements.the goal of object oriented analysis is ti first understand the domain of the
problem and the system’s responsibilities by understanding how the user use or will use the
system.
OOA Process consist of the following steps:
1. identify the actors
2. develop a simple business process model using UML activity diagram.
3. develop the Use case
4. develop interaction diagrams
5. identify classes.
4.8.2 Object oriented design

Booch provides the most comprehensive object oriented design method.Rumbaugh and
Jacobson high level models provide good avenues for getting started.booch’s object diagrams and
rumbaugh domain models .we can produce designs that are traceable across
requirements,analysis,design,coding and testing.
OOD process consists of
 Designing classes,attributes ,methods,associations,structures and

protocols,apply design axioms.
 Design the access layer
 Design the prototype user interface
70
 User satisfaction and usability tests based on the Usage/Use case
 Iterate and refine the design
4.8.3 Iterative development and continuous testing
Testing often uncovers design weaknesses or at least provides additional information
you will want to use,repeat the entire process,taking what you have learned and
reworking your design or moving on to reprototyping and retesting.
4.8.4 Modeling based on the Unified modeling language

The unified modeling language was developed by the joint efforts of the leading object
technologists grady booch, ivar Jacobson & james rumbaugh with contributions from
many others.
The UML merges the best of the notations used by the three most popular analysis
& design methodologies; booch’s methodology, Jacobson use case & rumbaugh object
modeling technique.
The UML is becoming the universal language for modeling system it is intended to
be used to express models of many different kinds and purposes, just as a programming
language or a nature language can be used in many different ways.
4.8.5 The UA Proposed Repository

In modem businesses, best practice sharing is a way to ensure that solutions to
process and organization problems in one pan of the business are communicated to
other pans where similar problems occur. Best practice sharing eliminates duplication of
problem solving.
For many companies, best practice sharing is institutionalized as part of their
constant goal of quality improvement. Best practice sharing must be applied to
application development if quality and productivity arc to be added to component reuse
benefits. Such sharing extends the idea of software reusability to include all phases of
software development such as analysis, design, and testing
.
71
The idea promoted here is to create a repository that allows the maximum reuse
of previous experience and previously defined objects, patterns, frameworks, and user
interfaces in an easily accessible manner with a completely available and easily utilized
format.
As we saw previously, central to the discussion on developing this best practice

sharing is the concept of a pattern. Everything from the original user request to
maintenance of the project as it goes to production should be kept in the repository.
The advantage of repositories is that, if your organization has done projects in the past,
objects in the repositories from those projects might be useful.
You can select any piece from a repository—from the definition of one data
element, to a diagram, all its symbols, and all their dependent definitions, to entries—
for reuse.
The UA's underlying assumption is that. if we design and develop applications

based on previous experience, creating additional applications will require no more than
assembling components from the library.
Additionally, applying lessons learned from past developmental mistakes to

future projects will increase the quality of the product and reduce the cost and development
time. Some basic capability is available in most object-oriented environments, such as
Microsoft repository.
VisualAge. PowerBuilder, Visual C++, and Delphi. These repositories contain

all objects that have been previously defined and can be reused for putting together a new
software system for a new application. If a new requirement surfaces, new objects will be
designed and stored in the main repository for future use.
The same arguments can be made about patterns and frameworks. Specifications of
the software components, describing the behavior of the component and how it should be
used, are registered in the repository for future reuse by teams of developers.
The repository should be accessible to many people. Furthermore, il should be

relatively easy to search the repository for classes based on their attributes, methods.
72
or other characteristics. For example, application developers could select prebuilt components
from the central component repository that match their business needs and assemble these
components into a single application, customizing where needed.
Tools to fully support a comprehensive repository are not accessible yet, but this will
change quickly and, in the near future, we will sec more readily available tools to capture all
phases of software development into a repository for use and reuse.
4.8.6 The layered approach to software development

Most of the system developed with todays CASE tools or client server application
development environments tend to lean toward what is known as two layer architecture
Work station
Figure: Two layered architecture: interface and data
In two layered system, user interface screens are tied to the data through
routines that sit directly behind the screens, for example a routine that executes when you
click on the button.
With every interface you create,you must recreate the business logic needed to
run the screen. The routine required to access the data must exist within every screen.Any
changes to the business logic must be accomplished in every screen and cannot be reused
easily in other project.
73
The better approach to system architecture is one that isolates the functions of the interface
from the function of the business. This approach also isolates the business from the details
of the data access(fig.10).
workstation
fig 10: Object are completely independent of how they are represented or stored.
74
Fig 11: Business objects represent tangible elements of the application. They should be
completely independent of how they are represented to the user of how they are
physically stored.
Using the three layered approach, you are able to create object that represent tangible
elements of your business yet a completely independent of how they are represented to
the user or how they are physically stored.
The three layered approach consists of a view or user interface layer, a business layer
and an access layer(fig :11)
4.8.6.1. The business layer
The business layer contains all the objects that represent the business (both data and
behavior). This is where the real objects such as order, customer, line item, inventory
and invoice exist.
The responsibilities of the business layer are very straight forward: model the objects of
the business and how they interact to accomplish the business process.
75
These objects should not be responsible for the following:
1.Displaying details
Business objects should have no special knowledge of how they are being displayed
and by whom. They are designed to be independent of any particular interface, so the
details of how to display an object should exist in the interface(view) layer of the object
displaying it.
2.Data Access Details
Business objects should no special knowledge of where they come form. It does
not matter to the business model whether the data are stored and retrieved via sql or file
i/o. the business objects need to know only to whom to talk about being stored or
retrieved. The business objects are modeled during the object-oriented analysis.
A business model captures the static and dynamic relationships among a

collection of business objects.
A static relationship includes objects associations and aggregations. For example

a customer could have more than one account or a order could be aggregated from one
or more line items.
Dynamic relationships show how the business objects interact to perform tasks.
For example an order interacts with inventory to determine product availability.
4.6.2.The User Interface(View) layer
The user interface layer consists of objects with which the user interacts as well as
objects needed to manage or control the interface. The user interface layer also is called
the view layer.
This layer typically is responsible for two major aspects of the applications.
1.Responding to user interactions.

The user interface layer object must be designed to translate actions by the user such as
Clicking on a button or selecting from a menu into an appropriate response.
2.Displaying business objects
76
This layer must paint the best possible pictures of the business objects for the user. In
one interface this may mean entry fields and list boxes to display an order and its items.
In another it may be graph of the total price of a customer’s orders.
The user interface layers objects are identified during the object oriented design phase.
4.8.6.3 The Access Layer
The access layer contains objects that know how to communicate with the place where
the data actually reside, whether it be a relational database, mainframe , Internet, or file
regardless of where the data actually reside. The access layer has two major
responsibilities
1. Translate Request
The access layer must be able to translate any data related request from the business
layer into the appropriate protocol for data access.
2. Translate results
The access layer also must be able to translate the data retrieved back into the
appropriate business objects and pass those objects backup into the business layer.
Access objects are identified during object oriented design.
Points to Remember
 An abstract use
case is not complete and has no actors that initiate it but is used by another
Use case.
 A framework is a
way of presenting generic solution to a problem that can be applied to all
levels in the development.
 A pattern is
instructive information that captures the essential structure.
 The process of
looking for patterns to document is called Pattern mining .
77
 A Pattern in waiting
which is not yet known to recur sometimes is called a “protopattern”
UNIT V
Introduction to UML-UML Diagram-Class Diagram-Use Case Diagram-Interaction Diagram-

Sequence Diagram-Collobration Diagram-State Chart Diagram-Activity Diagram-Component
Diagram-Deployment Diagram.
Unit : V
Model: model is an abstract representation of a system

System: system is used here in a bored sense to include any process or structure
Most modeling techniques used for analysis and design involves graphics languages these
graphics languages are sets of symbols
The symbols are used according to certain rules of the methodology for communication the
complex relationship of information more clearly than descriptive text.
Objector is build around several different models:
Use case model:
The use-case model defines the outside and inside of the system’s behavior
Domain object model: objects of the ‘real’ world are mapped into the domain object model
Analysis object model: the analysis object model presents how the source code should be
carried out and written.
Implementation model: the implementation model represents the implementation of the system.
Test model: the test model constitutes the test plans, specification and reports.
Static and dynamic models: Models can represent static or dynamic situation.
Static model: static model can be viewed as a snap shot of systems parameters at rest or at a
specific point time
Static models are needed to represent the structural or static aspect of a system developing is
static model.
Dynamic model: a dynamic model relationship show how the business objects the business
objects interact to perform tasks.
Dynamic most useful during the design and implementation phases of the system development
Why modeling
Construction is as essential as having a blue print for building a large building
Good models are essential for communication among project teams.
As the complexity of systems increases so does the importance of good modeling techniques.
Model elements: fundamental modeling concepts and semantics
Notation- visual rendering of model elements.
Guidelines – expression of usage within the trade
78
Clarity- picking out errors and omissions from a graphical or visual representation than from
listings of code or tables of numbers
We can understand the system due to this visual examination.
Familiarity: the representation form for the model may turn out to be similar to the way in
which the information actually is represented and used by the employees currently working in
the problem domain.
Maintainability of locations to be changed and visual confirmation of those changeds will
reduce errors you can make
Simplication: use of a higher level representation generally result in the use of fewer but more
general construct
Advantages of modeling:
1. Models make it easier to express complex ideas
2. The main reason for modeling is the resection of complexity models reduces complexity
by separating those aspects that are unimportant i.e. It makes complex situations easier to
understand
3. Models enhance and reinforce learning and training
4. The cost of the modeling analysis is much lower than the cost of similar
experimentations.
Few ideas regarding modeling
 A model is a rarely correct on the first try
 Always seek the advice and criticism of others
 Avoid excess model revision, as they can distort the essence of your model
2. Introduction to the unified modeling language:
UML is a language for specifying constructing, visualizing and documents the UML is a
graphical language with sets of rules and semantics
the rules and semantic of a model are expressed in English in a form known as object constraint
language (OCL) OCL is a specification language that usage simple logic for specifying the
properties of a system.
UML is not intended to be a visual programming language
UML does have a tight mapping to a family of object oriented language
UML not supporting other diagrams
Primary goals in the design of the design of the UML
1. Provide users a ready to-use expressive visual modeling language so they can develop
and exchange meaningful models.
2. Provide extensibility and specification mechanisms to extend the core
3. Be independent of particular program languages and development processes
4. Provide a formal basis for understanding
5. Encourage the growth of the object oriented tools market
6. Support higher level development concepts
7. Integrate best practices and methodologies
UML diagrams:
Nine graphical diagrams:
1. class diagram
2. Use-case diagram
79
3. Interaction diagram
3.1 sequence diagram
3.1.2 collaboration diagram
3.2 state chart diagram
3.3 activity diagram
4. implementation diagram
4.1 component diagram
4.2 deployment diagram
Diagrams one creates has a great influence on how a problem is encountered and how a
corresponding solution as shaped.
1. UML Diagram
UML diagram also referred to as object modeling is the main static an analysis diagram
This diagram show static model a class diagram is a collection of static modeling
elements
Such as classes and their relationship connected as a graph to each other and to their
contents as a graph to each other and to their contents
This visual representation of the objects their relationship and their structure is for easy of
understanding.
What are the goals of the system?
What must the system accomplish?
The main task of object modeling is to graphically of object modeling is to graphically
show what each object will do in the problem domain describe the structure and the
relationship among objects by visual notation.
1.1 class Notation:
 static structure a class is drawn as a rectangle with three components by
horizontal lines the two name compartment holds the class name other
general properties of the class such as attributes are in the middle
compartment and the bottom compartment holds a list of operations
 a separator line is not drawn about the presence or absence of elements in
it
1.2 Object diagram:

 A static object diagram is an instance of a class diagram
 It shows a snapshot of the detailed stage of the system at a point in time
 Notation is the same for an object diagram and a class diagram
 Class diagram can contain objects, so a class diagram with objects and no
classes is an object diagram.
Being 737 Being 737
Length :meter
Being 737
Fuel capacity :gal
Length: meter
80
Doors : int
Fuel
Lift ()
capacity: gal
1.3 Class interface notation:
 Class interface notation

is used to describe the externally visible behavior of a class
 Indentifying class
interface is a design activity of object oriented system development
 A class that requires the
operations in the interface may be attached to the circle by a dashed arrow
1.4 Binary association Notation:
 A binary association is
drawn as a solid path connecting two classes or both ends may be connected to
the same class
 An association may have
an association name
 The association name may
have an optional black triangle in ti. The triangle indicating the direction in which
to read the name.
 The end of an association
where it connects to a class is called the association role.
1.5 Association Role: the role is part of the association, not part of the class.
Each association has two or more roles to which it is connected.
The association works for connects two roles.
Person ---------->o Bank account
Company Person
81
Person
Employer employee
< Married to
Fig (a)
The association works for connects two roles employee and employer. A person is an employee
of a company and a company is an employer a person.
1.6 Qualifier:
a qualifier is an association attribute. Eg a person may be associated to a bank object may be

associated to bank object.
Bank Account Person
Fig (a)
1.7 Multiplicity: Multiplicity specifies the range of allowable associated classes. It is given for
role within associations, parts within composition
A multiplicity specification is shown as a text string comprising a period separated sequence of

interger intervals, where an interval represents a range of integers in this format.
Bank
Account #
Fig (b) *
0.1
Person
82
An attribute of this association is the account# the account# is the qualifier of the association fig
(b)
Lower bound ……. Upper bound
1.8 OR association: an Or association indicates a situation in which only on of several potential

associations may be instantiated at one time for any single object. This is shown as a dashed line
connecting two or more associations all of which must have a class in common.
Person
car
1.9 N-Ary association

company
An N-Ary association is an association among more than two classes. Since n-ary association is
more difficult to understand it is better to convert an a-ary association to binary association. The
role attachment may appear on each path as with a binary association. Multiplicity may be
indicated
An association class symbol may be attached to the diamo0nd by a dashed line.
Company Person
Employer employee
Working days
salary
1.10 Aggregation and composition
Aggregation is a form of association a hallow diamond is attached to the end of the path to
indicate aggregation .however the diamond may not be attached to the both ends of a line, and
83
Team Player
known as the a-part –of , is a form of aggregation with strong ownership to represent the
component of a complex object. Composition is a solid diamond at the end of a path.
Consist of >
class
1.11 Generalization: generalization is the relationship between a more general class and a more
specific class. Generalization is displayed as a directed line with a closed hollow arrowhead.
car
Wheel Light Door Engine
Car Car
Wheel 4 4 Wheel
Light 4.10 4.10 Light
Door 2.5 2.5 Door
Engine 1 1 Engine
Different ways to show composition
2. Use-case diagram:
A use case diagram is a graph of actors a set of use case enclosed by a system boundary
communication association between the actors and the use case
84
A use case is shown as an ellipse containing the name of the use case . the name of the
use case can be placed below or inside the ellipse. Actor names and use case names
should follow the capitalization
1. Communication: the communication relationship of an actor in a use case is shown by

connecting the actor symbol to the use case symbol with a solid path
2. Uses: a user relationship between use case is shown by a generalization arrow from the
use case.
85
3. Extends: the extends relationship is used when you have one use case that is similar to
another use case but does a bit more .
3. UML Dynamic
modeling(Behavior diagram)
The diagrams we have looked at so far largely are static . however events happen
dynamically in all system : objects are created and destroyed , objects send messages to
one another in an orderly fashion and in some systems external events.
Behavior diagram
 Interaction diagram
 Sequence diagram
 Collaboration diagram
 State chart diagram
 Activity diagram
3.1 UML interaction
diagram
 It’s capture the behavior
of a single use case showing the pattern of interaction among object. The
diagram shows a number of example objects and the messages passed
between those objects within the use case
3.1.1 UML sequence diagram

 UML SDS are an easy
and intuitive way of describing the behavior of a system by viewing between
the system and its environment
 A sequence diagram
shows an interaction arranges in a time sequence
 2 dimension
 1. Vertical dimension --
 rep the time
 2. Horizontal dimension -
 rep the different object
 The vertical line is called
lifeline.
 The life line represents
the object existence during the interaction.
86
 A sequence dig does not
show the relationship among the roles.
Lifelines
A lifeline represents an individual participant in a sequence diagram. A lifeline will usually have a
rectangle containing its object name. If its name is self then that indicates that the lifeline represents the
classifier which owns the sequence diagram..
Sometimes a sequence diagram will have a lifeline with an actor element symbol at its head. This will
usually be the case if the sequence diagram is owned by a use case. Boundary, control and entity elements
from robustness diagrams can also own lifelines.
Messages
Messages are displayed as arrows. Messages can be complete, lost or found; synchronous or
asynchronous; call or signal. In the following diagram, the first message is a synchronous message
(denoted by the solid arrowhead) complete with an implicit return message; the second message is
asynchronous (denoted by line arrowhead) and the third is the asynchronous return message (denoted by
the dashed line).
87
Execution Occurrence
A thin rectangle running down the lifeline denotes the execution occurrence or activation of a focus of
control. In the previous diagram, there are three execution occurrences. The first is the source object
sending two messages and receiving two replies; the second is the target object receiving a synchronous
message and returning a reply; and the third is the target object receiving an asynchronous message and
returning a reply.
Self Message
A self message can represent a recursive call of an operation, or one method calling another method
belonging to the same object. It is shown as creating a nested focus of control in the lifeline’s execution
occurrence.
Lost and Found Messages

Lost messages are those that are either sent but do not arrive at the intended recipient, or which go to a
recipient not shown on the current diagram. Found messages are those that arrive from an unknown
88
sender, or from a sender not shown on the current diagram. They are denoted going to or coming from an
endpoint element.
Lifeline Start and End

A lifeline may be created or destroyed during the timescale represented by a sequence diagram. In the
latter case, the lifeline is terminated by a stop symbol, represented as a cross. In the former case, the
symbol at the head of the lifeline is shown at a lower level down the page than the symbol of the object
that caused the creation. The following diagram shows an object being created and destroyed.
Duration and Time Constraints

By default, a message is shown as a horizontal line. Since the lifeline represents the passage of time down
the screen, when modelling a real-time system, or even a time-bound business process, it can be important
to consider the length of time it takes to perform actions. By setting a duration constraint for a message,
the message will be shown as a sloping line.
89
Combined Fragments
It was stated earlier that Sequence diagrams are not intended for showing complex procedural logic.
While this is the case, there are a number of mechanisms that do allow for adding a degree of procedural
logic to diagrams and which come under the heading of combined fragments. A combined fragment is
one or more processing sequence enclosed in a frame and executed under specific named circumstances.
The fragments available are:
 Alternative fragment (denoted “alt”) models if…then…else constructs.

 Option fragment (denoted “opt”) models switch constructs.
 Break fragment models an alternative sequence of events that is processed instead of the whole of
the rest of the diagram.
 Parallel fragment (denoted “par”) models concurrent processing.
 Weak sequencing fragment (denoted “seq”) encloses a number of sequences for which all the
messages must be processed in a preceding segment before the following segment can start, but
which does not impose any sequencing within a segment on messages that don’t share a lifeline.
 Strict sequencing fragment (denoted “strict”) encloses a series of messages which must be
processed in the given order.
 Negative fragment (denoted “neg”) encloses an invalid series of messages.
 Critical fragment encloses a critical section.
 Ignore fragment declares a message or message to be of no interest if it appears in the current
context.
 Consider fragment is in effect the opposite of the ignore fragment: any message not included in
the consider fragment should be ignored.
 Assertion fragment (denoted “assert”) designates that any sequence not shown as an operand of
the assertion is invalid.
 Loop fragment encloses a series of messages which are repeated.
90
The following diagram shows a loop fragment.
There is also an interaction occurrence, which is similar to a combined fragment. An interaction

occurrence is a reference to another diagram which has the word "ref" in the top left corner of the frame,
and has the name of the referenced diagram shown in the middle of the frame.
Gate
A gate is a connection point for connecting a message inside a fragment with a message outside a
fragment. EA shows a gate as a small square on a fragment frame.
91
Part Decomposition
An object can have more than one lifeline coming from it. This allows for inter- and intra-object messages
to be displayed on the same diagram.
State Invariant / Continuations

A state invariant is a constraint placed on a lifeline that must be true at run-time. It is shown as a rectangle
with semi-circular ends.
A Continuation has the same notation as a state invariant but is used in combined fragments and can
stretch across more than one lifeline.
92
3.2 UML Collaboration
diagram
Another type of interaction diagram is the collaboration diagram
A collaboration diagram rep a collaboration which is a set of objects related in a

particular context. And interaction, which is a set of messages exchanged among the
objects within the collaboration to active a desired outcome.
Arrow indicate the message sent within the given use case
A collaboration diagram provides several numbering schemes. The simplest is fig (a)
93
3.3 UML state chart
diagram
o It’s also called state
diagram shows the sequence of states that an object goes through during its in
response to outside stimuli and messages
o The state is the set of
values that describes an object at a specific point in time and is represented by
state symbols and the transition is representing by arrows connecting the state
symbols. A state dig may contain sub diagrams.
o A state dig rep the state
of the method execution.
o A state is represented as
a rounded box which may contain one or more compartments.
o The name compartment
holds the optional name of the state.
o The internal transition
compartment holds a list of internal actions or activities performed
94
3.4 UML activity diagram
An activity diagram is a variation or special chase of a state machine. In which the stages
are activates represents the performance of operations.
An activity model is similar to a state chart diagram where a token a blank dot represent
the operation.
An activity is shown as a round box, containing the name of the operation
95
4. Implementation
diagram
Implementation diagrams show the implementation phase of system development
Such as the source code structure and the run-time implementation structure there are two
types of implementation diagrams: component diagrams show the structure of the code
itself, and deployment diagram show the structure of the run time system. These are
relatively simple high-level diagrams component-based development later.
Component diagram model the physical components in a design. These high-level

physical components may or may not be equivalent to the many smaller components you use into
the creation of your application.
96
 A package is used to
show how you can group together classes
 A component diagram is
a graph of the design components connected by dependency relationship.
Component Diagrams
Component Diagrams illustrate the pieces of software, embedded controllers, etc. that will make up a
system. A Component diagram has a higher level of abstraction than a Class diagram - usually a
component is implemented by one or more classes (or objects) at runtime. They are building blocks, such
that eventually a component can encompass a large portion of a system.
The diagram below demonstrates some components and their inter-relationships. Assembly connectors
'link' the provided interfaces supplied by Product and Customer to the required interfaces specified by
Order. A dependency relationship maps a customer's associated account details to the required interface,
'Payment', indicated by Order.
Components are similar in practice to package diagrams as the define boundaries and are used to group
elements into logical structures. The difference between Package Diagrams and Component diagrams is
97
that Component Diagrams offer a more semantically rich grouping mechanism. With Component
Diagrams all of the model elements are private whereas Package diagrams only display public items.
Representing Components
Components are represented as a rectangular classifier with the keyword «component», optionally the
component may be displayed as a rectangle with a component icon in the right-hand upper corner.
Required Interfaces
The Assembly connector bridges a component’s required interface (Component1) with the provided
interface of another component (Component2); this allows one component to provide the services that
another component requires. Interfaces are collections of one or more methods which may or may not
contain attributes.
Components with Ports

Using Ports with Component Diagrams allows for a service or behavior to be specified to its environment
as well as a service or behavior that a Component requires. Ports may specify inputs, outputs as well as
operating bi-directionally. The following diagram details a component with a port for Online services
along with two provided interfaces Order Entry and Tracking as well as a required interface Payment.
98
Deployment diagram:
 Shows the configuration

of run-time processing elements ant the software components , process, and objects that
live in them.
 A dependency diagram is
a graph of nodes connected by communication association. Nodes may contain
components instance, which means that the component lives. Or runs at these node.
 System is representd by
three-dimensional box.
 Connection between the
nodes.
 Deployment Diagrams
A Deployment Diagram models the run-time architecture of a system. It shows the configuration
of the hardware elements (nodes) and shows how software elements and artifacts are mapped
onto those nodes.
 Node
A Node is either a hardware or software element. It is shown as a 3-dimensional box shape, as
below

 Node Instance
A node instance can be shown on a diagram. An instance can be distinguished from a node by the
fact that its name is underlined and has a colon before its base node type. An instance may or may
not have a name before the colon. The following diagram shows a named instance of a computer.

 Node Stereotypes
A number of standard stereotypes are provided for nodes, namely «cdrom», «cd-rom»,
99
«computer», «disk array», «pc», «pc client», «pc server», «secure», «server», «storage», «unix
server», «user pc». These will display an appropriate icon in the top right corner of the node
symbol

 Artifact
An Artifact is a product of the software development process. That may include process models
(e.g. Use Case models, Design models etc), source files, executables, design documents, test
reports, prototypes, user manuals and so on.
 An artifact is denoted by a rectangle showing the artifact name, the «artifact» stereotype and a
document icon, as follows.

 Association
In the context of a deployment diagram, an association represents a communication path between
nodes. The following diagram shows a deployment diagram for a network, showing network
protocols as stereotypes and also showing multiplicities at the association ends.
100
 Node as Container
A node can contain other elements, such as components or artifacts. The following diagram
shows a deployment diagram for part of an embedded system and showing an executable artifact
as being contained by the motherboard node.
101
102

CT Complete-1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CT Complete-1 PDF

Uploaded by

Copyright:

Available Formats

Unit – I

Data Modeling: Business Growth-Organisational Model-Case Study of student MIS-What

i) manpower ii) Fund flow

 There will be responsible heads in the organization

Fund flow increase

Financial control increase Supplier rawmetrial Mrketting increse

Finished products increase

Oranization model indicates how its business runs

Develop model strategy Maintain project model Maintain corarate model

 Model can be used to improve the way of business

4. Case study: A student MIS system

Eg: let’s considr the cost of letter

Project team co-ordination

Business model- it represent the business

8.model development approach

Advantages of using CASE tools

System analysis and design:

General rules for drawing DFD

Difference between logical DFD and Physical DFD

Software versus information engineering:

How case store information

Application stored in case

App1 App2 APP n

Approach used to solve the problem statement:

HRD Department TIME OFFICE ACCOUNT

The event list

Master transaction utilities reports exit

Menu entry screen

Data entry screens:

Master transaction utilities reports exit

Installation OF uBridge & Synthesis

How to use the tools in uBridge Synthesis for case

SETUP uBridge to work in the manner that you want.

THE OBJECT SCALE FACTOR

1. draw boxes or lines

MAIN FLOW of the system

BEILDING UP YOUR REQUIREMENT

press enter to select the starting point

PROTOTYPING YOUR REPORTS:

Adjusting to different Monitor types :

The SYNTHESIS Main Menu

Diagram : Gives you choice of nine standard Diagramming techniques.

Document : Build a document based on the data dictionary.this document could be

Drawing the screens

Draw : To actually position and draw an object and to connect the

The data Dictionary is two part:

2.Part II of the Data Dictionary

THE DIRECT INTERFACE:

Three types of diagram Analysis can be preformed in SYNTHESIS.

Data flow diagram analysis for ensuring completeness of a diagram.

Level balancing for ensuring integrity across data flow diagrams

LEVELLED DATA FLOW DIAGRAMS:

Balancing of a data flow diagram:-

There is one exception:-

Trivial rejects need not be balanced between parent and child.

The advantages of levelled data flow diagrams:-

Guidelines for choosiong a Kev

First Normal Form

Second Normal Form

Relation 1 Relation 2 Relation 3

Rule 1 Separate the Repeating Group

Once you choosethis option, you have the following choices,

A section can either be a uBridge screen, a diagram or a text file.