Professional Documents
Culture Documents
CT 20complete 1 PDF
CT 20complete 1 PDF
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
1
3. Oraganization model
Model Management
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
DFDis 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
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.
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
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
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
7
diagram include those showing entity relationship data structures,
hierarchical tree-structured decomposition, data flow dependency,
screen and report layouts and detailed program logic
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.
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
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
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
Choice
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
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
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:-
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:
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
To get started with ubridge synthesis we need to first get into the tools by keying in
17
C:\synth>synth
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
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.
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
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)
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)
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.
19
Data Dictionary: Provides a direct data dictionary interface.
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.
(B) Diagram:
The diagramming menu has the options as below:
(C) DATA-DICTONARY:
20
The data dictionary is a repository of details of all entities handled with in SYNTHESIS
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.
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:
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.
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:
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.
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.
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.
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.
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
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.
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.
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.
All text files designated as section must be present in the user Directory and must have the extension
'TXT'.
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.
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
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:-
Design Screens
Menu
Screen
Define Fields
Define Field Validations
Chain the above in the manner that you desire, and run the model.
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.
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)
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.
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
Object: diagram
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.
Ok cancel help
Status:
User want to specify the Diagram name ,DiagramDescription,Manual Connection and the
Overlap Connection.
User can create own DFD, user will first create own icon.and then draw the own icon
,choose the icon option.
30
Object Diagram Administrator
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.
Line
Circle
Arc
Prev
Next
31
Last
First
Delete
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.
Line
Circle
Arc
Prev
Next
Last
First
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
Ok Cancel Help
You would like to have different objects in your DFD. Select the Object List Button and the
following screen will appear
External entity GS
33
External Entity YD Modify
Process G&S
Process Y/D
Off Page
OK Cancel Help
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:
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.
Screen
Record Add
DFD Yourdon
Data Model
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.
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.
Off Page
OK Cancel Help
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
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.
Slant line
Straight 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.
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
Screen Record
record Add
DFD Yourdon
Data Model
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.
40
uBridge Synthesis Diagram Definition tool Ver 1.0
New object/diagram
Get Object
Save Object
Get Diagram
Save Diagram
Quit
Status:
Now, select the save diagram option to save the new Diagram. This will Display a message to
you on the screen as follows
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.
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.
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.
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.
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.
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).
Client
Withdraw amount
checking account
Savings account
44
4.3.2 The OMT Dynamic Model
Account has
Nothing is
been selected
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.
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
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.
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.
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.
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.
51
3. Identify class and object relationships.
4. Identify class and object interfaces and implementation.
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).
Use cases are scenarios for understanding system requirements. A use case is an interaction
between users and a system.
Library
Doing research
member
Purchasing supplies
52
supplier
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]:
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.
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
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.
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.
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.
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.
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.
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.
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
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 .
• 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
• 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.
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:
Object-oriented analysis
Object-oriented design
Continuous testing
68
Diagram A : the process and components of the unified approach
Layered approach
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.
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.
5. identify classes.
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.
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.
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 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.
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.
Work station
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)
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.
Dynamic relationships show how the business objects interact to perform tasks.
For example an order interacts with inventory to determine product availability.
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.
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
Unit : V
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
Length :meter
Being 737
Fuel capacity :gal
Length: meter
80
Doors : int
Fuel
Lift ()
capacity: gal
1.3 Class interface notation:
1.5 Association Role: the role is part of the association, not part of the class.
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:
Fig (a)
1.7 Multiplicity: Multiplicity specifies the range of allowable associated classes. It is given for
role within associations, parts within composition
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)
Person
car
Company Person
Employer employee
Working days
salary
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
Car Car
Wheel 4 4 Wheel
Engine 1 1 Engine
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
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
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.
88
sender, or from a sender not shown on the current diagram. They are denoted going to or coming from an
endpoint element.
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:
90
The following diagram shows a loop fragment.
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.
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
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.
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.
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.
98
Deployment diagram:
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