Ct%20complete-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. 2. 3. 4. 5. 6.

Any DFD leaving a process must be based on data that are input to the process All DFD are named their name reflects the data flowing between to perform the process should be an input to the process Only data needed to perform the process should be an input to the process Be independent of any other process in the system it should depend upon it own input and output Process are always running they do not start or stop process is always ready to perform work 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 caseInstallation 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

HRD Department DEPARTMENT Name Age Address Status Qualification Blood group ETC

organization

TIME OFFICE

ACCOUNT

Name Dept Div time in time out date

Earning Basic HRA

Pf FPF Loan

DA CA IT

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. 9. 10. 11. 12. 13.

Exit menu screen Report menu screen Payslip screen Utilities menu screen Backup screen 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 Value clear to clear B bachup y p passwd y E main menuy y Please enter the following Backup Passwd Exit

library payroll payroll payroll

CHOICE

ubl ubl ubl

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 ReportIntroducing 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: 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 Data GRN Number Supplier Address Order Ref. Discount Grand Total

Relation 2 GRN Number Iterm Code Description Rate Quantity 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 Object

Diagram Definition Tool Ver 1.0 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. uBridge Synthesis Object

Diagram Definition Tool Ver 1.0 Diagram

Administrator 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. uBridge Synthesis

Diagram Definition Tool Ver 1.0

Object

Diagram

Administrator

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. uBridge Synthesis

Diagram Definition Tool Ver 1.0

30

Object

Diagram

Administrator

Diagram Name: rukmini

Icon window D Icon Label : rukus

Hot key:u

Icon Draw

M

Ok

I

cancel

help

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 uBridge Synthesis

Diagram Definition Tool Ver 1.0

32

Object

diagram

administrator

Diagram name: rukmini Diagram Description: Rukmini”s Gane & Sarson Manual Connection : No Icon

Object List Ok

Overlap Connection : No

Connector List Cancel

Symbol List Help

You would like to have different objects in your DFD. Select the Object List Button and the following screen will appear uBridge Synthesis Object

Diagram Definition Tool Ver 1.0

Diagram

Diagram name: rukmini Object name list

Administrator Add 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

Status:

Help

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:

uBridge Synthesis Object

Diagram Definition Tool Ver 1.0

Diagram

Administrator Add Object Window

Object name: External Entity G&S Explosion Rule

Ok

Connection Rule

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. uBridge Synthesis Object

Diagram Definition Tool Ver 1.0 Diagram

Administrator

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. uBridge Synthesis Object

Diagram Definition Tool Ver 1.0

Diagram

Administrator

Diagram name: rukmini

Add

Object name list

Diagram Object List

External entity G&S

External entity GS

External Entity YD

Process G&S

Process G&S

Data Store G&S

Process Y/D

Modify

Off Page

Data Store G&S

Report(Pres)

Data Store Y/D

Delete

Off Page

OK Status:

Cancel

Help Diagram: rukmini

This will take you back to the screen where we started defining our new object or diagram. The screen is as follows. uBridge Synthesis

Diagram Definition Tool Ver 1.0

37

Object

diagram

administrator

Diagram name: rukmini Diagram Description: Rukmini”s Gane & Sarson Manual Connection : No Icon

Object List

Overlap Connection : No

Connector List

Ok

Cancel

Symbol List 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 Object

Diagram definition Tool Ver 1.0 Diagram

Administrator

Diagram Connector window Diagram name:

rukmini

Connector Name List Slant arrow

Diagram Connector List 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 Object

diagram Defintion Tool Ver 1.0 Diagram

Administrator

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 uBridge Synthesis Object

Diagram Definition Tool Ver 1.0 Diagram

Administrator

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 Object

Diagram Definition tool Ver 1.0 Diagram

Administrator 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 uBridge Synthesis Object

Diagram Definition Tool Ver 1.0 Diagram

Administrator

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 objectoriented 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 objectoriented 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, relationships 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

Pincode

balance Deposit

transaction account

transdate

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.

Nothing is

Selected checking or savings account

Select transaction type (withdraw,deposit,transfer

Account has been selected

Select checking

Enter the 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

Alaramfixed

disable

Disabled

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 model

analysis

design

model

model

implementation model

testing 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 environment. 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 significantly 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 everchanging 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 provide 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 evergrowing 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

4.8.3



User satisfaction and usability tests based on the Usage/Use case



Iterate and refine the design

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 DiagramSequence 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

Being 737 Length :meter Fuel capacity :gal

Length: meter Doors : int Fuel capacity: gal

Lift ()

80

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

Company

Bank account

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 > 1 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

Car Wheel

Door

Engine

Car 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