Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Case tool notes for bachelors 9f computer applications students who studied in bharathiar, Cheat Sheet of Integrated Case Studies

Notes for case tool subject for bachelor for computer application students studied in bharathiar University coimbatore

Typology: Cheat Sheet

2022/2023

Uploaded on 12/15/2023

nithina-murukesan
nithina-murukesan 🇮🇳

1 document

1 / 77

Toggle sidebar

Related documents


Partial preview of the text

Download Case tool notes for bachelors 9f computer applications students who studied in bharathiar and more Cheat Sheet Integrated Case Studies in PDF only on Docsity! Subject Name: Case Tools Concepts and Applications Department: Computer Applications Class: III – BCA A & B Semester: V 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.  How we are modeling the business  When a new business comes into gain a profit  Management will take over the responsibility of designing the details daily  These will be implemented qnd checked for bugs for bussiness growth 1. Business growth: 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 projected  So the fund flow will increase, the decisions are made by the organization based on the information based by various levels 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 raw material Marketing increase 1 Finished products increase Organization model Organization model indicates how its business runs Model Management Developmodel strategy Maintain project model Maintain corarate model  Model can be used to improve the way of business  Its indicate the strength and weakness  The ewakness can beevaluated and changed to strengths  Rules: i) shape of the object ii)Relationship between objects 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 automic values into program  Hardcode it become impossible to implement changes when it takes plaee  A small changes is made at the automic level it can’t be implemented in the computer systemwithout making changes in the source file  IT professionals we hve to try and make the applications as flexible as possible Purpose of suchmodels:  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 rrequirement of the system 2  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:  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 5  Perter Yourdon, Gane sarson, Jackson martinDemarco,Mellor,Hately,Ward 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 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 ina 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: DFD are graphical models of entites that need to work together in harmoney for the systems model to work correctly, these diagram help the designer visuallize the flow of data in a manual process and how it will mova 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 asingle process can be exploded into several processes data is converted into information Datastore 6 Input Process Output Stores the data has been processed the data that comes out of processing General rules for drawing DFD 1. Any DFD leaving a proces muxt be based on data that are input to the process 2. All DAD are named ther namre reflects the data flowing between to perform the process should be an input to the process 3. Only data needed to tperdform the process should be an input to the process 4. Be independent of any other process in the system it should depend uponit own input and output 5. Process are always running they donot start or stop process is alwys ready to perform work 6. Output of the process can take any of the following forms a) An input DFD with information added by the process b) A response or change of data from dollarsto profit c) Change of status d) Change of content e) Change of organization Difference between logical DFD and Physical DFD Logical Physical Logical DFD are drawn keeping Physical DFD drawn with in mind how the work is going to be done reference to who is goging to do the work Mainly focus on the process which will Do the work Physical DFD has to replac the process in the logical DFD by the logical DFD by the people who are doing the process The Physical DFD bring the human being in picture.Designer is completely satisfied That the DFD is correct and that code written based not the DFD will work without logical errors. Interaction between the human being of the s/w, data entry screens are necessary Software versus information engineering: 7 The representation must be in a style so that the client understands it. Such types of representation diagrams are called PRESENTATION DIAGRAMS Structured chart for payroll HRD Department TIME OFFICE ACCOUNT DEPARTMENT Name Name Earning Pf Age Dept Basic FPF Address Div HRA Loan Status time in DA Qualification time out CA Blood group date IT ETC 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 10 XYZ organization 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 6) 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 Exit menu_______ main menu Report menu 11 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 form 2. 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 12 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 Field Value clear to clear library B bachup y payroll ubl p passwd y payroll ubl E main menuy y payroll ubl Please enter the following Backup Passwd Exit INSTALLATION OF UBRIDGE & SYNTHESIS How to use the tools in uBridge Synthesis for case An individual case tool automates one small focused step in the life cycle process. Individual tools fall into these general catogiries Diagramming tools to pictorially reprecent system specification Screen and report painters fort creating system specifications and for simple prototyping Dictionaries information management systems and fecilities to store report and query technical and project management system information. Specification checking tools to ditect incomplete , syntactically incorrect ,and inconsistent system specification Code generators to be able to generate executable code from pictorial system specifications Documentation generators to produce technical and user documentation required by structured Methodologies.Prototyping tools help determine system requirements and predict perrformence beforehand Screen dialog and navigation with entry and edits can be simulated 15 Master transaction utilities reports exit Backup PASSWORD EXIT CHOICE 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 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 section Installisation 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 1. Systems software 2. Commercial 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) 16 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. 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. 17 Unit – III Introduction to Ubridge: Introduction - Main flow of the system prototyping your Report- Introducing the Novice Model of the Operation. Introducing Synthesis - Synthesis basic – Synthesis - Menu Drawingthe screen-Requirement Definition-Diagram-Data Dictionary- Document-Synthesis MainAdministration - Synthesis reference - importing and exporting screen. INTRODUCING TO UBRIDGE INTRODUCTION CASE TOOLS must have an option so that the designing of the screen can be achived to do this ubridge synthesis uses its first menu screen Now 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 C:\synth>synth MAIN FLOW 20 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 chaining DATA AS In ubridge DATA is defined as those are of the screen representing variable information These screen can now be defined as data entry screens  Marketing afield  Field name  Field detail  Listing field  Sequence of data entry  Deleting afield 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 selection list.  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 21 1. current screen 2. all from current 3. specific screen 4. data manager PROTOTYPING YOUR REPORTS: We can plan a report as much as 256 columns wide wee can paint a report using the screen paint option and acctualy define its contents. A complete report model can be created and chained to the model system accessible via the report option of the main menu to provide realityof the model flow INTRODUCING THE NOVICE MODE OF OPERATION: The novice mode makes the various activities such as painting of screens defining of data chaining of screens etc.. of ubridge. This mode thus makes a model of your system with out you having to paint screens define data chain screens together or any othere activity that is normally required to make such a model. Introducing SYNTHESIS After knowing what is uBridge, and how we can configure the system using SYMAN let's get to known SYNTHESIS, the systems analyis and design work bench SYNTHESIS Basics Starting SYNTHESIS You can run SYNTHESIS from any directory or sub-directory with the command: <pathname>SYNTH (ENTER) Adjusting to different Monitor types : SYNTHESIS assumes a color monitor when you run it using the command SYNTH(Enter) Thus if you have a monochrome monitor the resultant shades may not have adequate contrast you can override the color usage by keying in '/B' after SYNTH: <PATHNAME>SYNTH/B(Enter) The SYNTHESIS Main Menu 22 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 data 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. 25 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:- 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 levels 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 26 Supplier Name Supplier Address Order Reference *Item code *Description *Rate *Quantity *Total Discount Grand Total The list hs been derived from the format given above. Thstar before the data element indicates it is repeating in the format. First Normal Form A record in the first normal form (FNF)does not includ any repeating groups.So removing this from the group we get the following: Relation 1 Relation 2 Data GRN Number GRN Number Iterm Code Supplier Address Description Order Ref. Rate Discount Quantity Grand Total Total Second Normal Form With in the second normal form each field (or attribute or data item) depends on the whole key and not on part of the key. Relation 1 Relation 2 Relation 3 Date GRN Number Item code GRN Number Iterm Code Description Supplier Name Rate Supplier Address Order Ref. Quantity Discount Total 27 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. SYNTHESIS ADMINISTRATION & REFERENCES: 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. 30 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 POINTS TO REMBEMBER:  Prototyping of report  Model of the operations  Menu screens  Document & data dictionary  Importing & exporting screen SUGGESTED QUESTIONS 1. Explain the concept of flow of the system prototyping & novice model of the operation. 2. What is requirement? Explain the screen requirement with neat diagram. 3. Explain the concept of document & data dictionary 4. Explain the process of requirement diagram. 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 31 object 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 At the dos prompt key-in as follows C:\synth>ddt This will call the executable from the synthesis home directory.The main screen will open up which is as follows uBridge Synthesis Diagram Definition Tool Ver 1.0 Object Diagram Administrator Object: diagram 32 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 Object diagram administrator Diagram name: rukmini Diagram Description: Rukmini”s Gane & Sarson Manual Connection : No Overlap Connection : No Icon Object List Connector List Symbol List Ok Cancel Help You would like to have different objects in your DFD. Select the Object List Button and the following screen will appear uBridge Synthesis Diagram Definition Tool Ver 1.0 Object Diagram Administrator Diagram name: rukmini Add Object name list Diagram Object List External entity GS External Entity YD Modify Process G&S 35 Process Y/D Data Store G&S Data Store Y/D Delete Off Page OK Cancel Help Status: Diagram: rukmini The Object Name List will show you all the objects that are available to you. Choose the object that you want and click the add menu. Say, you choose External Entity Gane & Sarson from the Object Name List, select the add button then a screen will appear as follows: uBridge Synthesis Diagram Definition Tool Ver 1.0 Object Diagram Administrator Add Object Window Object name: External Entity G&S Explosion Rule Connection Rule Ok Cancel Help 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. 36 uBridge Synthesis Diagram Definition Tool Ver 1.0 Object 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 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. After completing the process , select the ok menu to get your change accepted. uBridge Synthesis Diagram Definition Tool Ver 1.0 37 Ok Cancel Help Now you will have to specify the Expansion Rule menu and the following pop p window opens up as follows uBridge Synthesis Diagram Definition Tool Ver 1.0 Object 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 uBridge Synthesis Diagram Definition tool Ver 1.0 Object 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 Diagram Definition Tool Ver 1.0 40 Object 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. 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. 41 The trend in object-oriented methodologies, sometimes called second-generation object-oriented methods. 4.2 SURVEY OF SOME OF THE OBJECT-ORIENTED METHODOLOGIES 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 co- workers describes a method for the analysis, design, and implementation of a system using an object-oriented technique. OMT is a fast, intuitive approach for identifying and modeling all the objects making up a system. Details such as class attributes, method, inheritance, and association also can be expressed easily. The dynamic behavior of objects within a system can be described using the OMT dynamic model. This model lets you specify detailed state transitions and their descriptions within a system. Finally, a process description and consumer-producer relationships can be expressed using OMT's functional model. OMT consists of four phases, which can be performed iteratively: 1. Analysis. The results are objects and dynamic and functional models. 2. System design. The results are a structure of the basic architecture of the system along with high-level strategy decisions 3. Object design. This phase produces a design document, consisting of detailed objects static, dynamic, and functional models 4. Implementation. This activity produces reusable, extendible, and robust code. OMT separates modeling into three different parts: 1. An object model, presented by the object model and the data dictionary. 2. A dynamic model, presented by the state diagrams and event flow diagrams. 42 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. 45 legend FIQURE 4-3 OMT DFD of the ATM system. The data flow Hoes Include arrows to show the direction of data element movement The circles represent processes. The boxes represent external entities. A data store reveals the storage of data. 1.4 THE BOOCH METHODOLOGY 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, 46 process data store dataflow external entity 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. 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. 47 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 member 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) 50 Checking out books Getting an interlibrary loan Doing research Reading books, newspaper Purchasing supplies 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. • 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 51 to object-oriented analysis and design (hat centers on understanding the ways in which a system actually is used. 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 domain object analysis design implementation testing 52 Ok Not ok 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. 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. 55 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 software engineering, including development organization, the software development process, project planning, requirements engineering, and software configuration management. 4.6.1 Generative and Nongenerative Patterns Generative patterns are patterns that not only describe a recurring problem, they can tell us how to generate something and can be observed in the resulting system architectures they helped shape. Nongenerative patterns are static and passive: They describe recurring phenomena without necessarily saying how to reproduce them. We should strive to document generative patterns because they not only show us the characteristics of good systems, they teach us how to build them. Alexander explains that the most useful patterns are generative. These patterns in our minds are. more or less, menial images of (he patterns in he world: they are abstract representations of the very morphological rules which define the patterns in the world. However, in one respect they are very different. The patterns in the world merely exist. Bui the same patterns in our minds are dynamic. They have force. They arc generative. They tell us what to do; they tell us how we shall, or may. generate them; and they tell us too. that under certain circumstances, we must create them. Alexander wants patterns, and especially pattern languages, to be capable of generating whole, living structures. Part of the desire to create architectures that Emulate life lies in die unique ability of living things to evolve and adapt to their ever- changing environments (not only for the sake of individual survival but also for survival of the species). Alexander wants to impart these same qualities into his architecture. 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. 56 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. • 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 57 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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 ever-growing repository of patterns. People can contribute new solutions, lessons learned (or antipatterns), and more examples within a variety of contexts. How do you know a partern when you come across one? The answer is you do not always know. You may jot down the beginning of some things you think are patterns, but it may turn out that these are not patterns at all, or they are only pieces of patterns, simply good principles, or general rules that may form part of the rationale for a particular pattern. It is important to remember that a solution in which no forces are present is not a pattern . These guidelines are summarized from Buschmann : • Focus on practicability. Patterns should describe proven solutions to recurring problems rather than the latest scientific results. • Aggressive disregard of originality. Pattern writers do not need to be the original inventor or discoverer of the solutions that they document. • Nonanonymous review. Pattern submissions are shepherded rather than reviewed. The shepherd contacts the pattern authors) and discusses with him or her how the patterns might be clarified or improved on. • Writers' workshops instead of presentations. Rather than being presented by the individual authors, the patterns are discussed in writers' workshops, open forums where all attending seek to improve the patterns presented by discussing what they like about them and the areas in which they are lacking. • 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 AJKCAS – Study Material – Odd Semester 2019 - 20 | 60 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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. : 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. AJKCAS – Study Material – Odd Semester 2019 - 20 | 61 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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. 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 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. AJKCAS – Study Material – Odd Semester 2019 - 20 | 62 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 The same arguments can be made about patterns and frameworks. Specifica- tions 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. 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. 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). AJKCAS – Study Material – Odd Semester 2019 - 20 | 65 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 workstation fig 10: Object are completely independent of how they are represented or 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. 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. AJKCAS – Study Material – Odd Semester 2019 - 20 | 66 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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 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 .  A Pattern in waiting which is not yet known to recur sometimes is called a “protopattern” Expected Questions AJKCAS – Study Material – Odd Semester 2019 - 20 | 67 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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 3. Interaction diagram 3.1 sequence diagram 3.1.2 collaboration diagram 3.2 state chart diagram AJKCAS – Study Material – Odd Semester 2019 - 20 | 70 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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. AJKCAS – Study Material – Odd Semester 2019 - 20 | 71 Being 737 Being 737 Length :meter Fuel capacity :gal Doors : int Lift () AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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. ---------->o Employer employee < Married to Fig (a) AJKCAS – Study Material – Odd Semester 2019 - 20 | 72 Being 737 Length: meter Fuel capacity: gal Doors:int Being 737 Length :meter Fuel capacity :gal Doors : int Lift () Person Bank account Company Person Person AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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. 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 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. 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 AJKCAS – Study Material – Odd Semester 2019 - 20 | 75 car Wheel Light Door Engine Car Wheel 4 Light 4.10 Door 2.5 Engine 1 Car 4 Wheel 4.10 Light 2.5 Door 1 Engine AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105  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.  A sequence dig does not show the relationship among the roles. 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. 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 3.4 UML activity diagram AJKCAS – Study Material – Odd Semester 2019 - 20 | 76 AJK COLLEGE OF ARTS AND SCIENCE Navakkarai, Coimbatore - 641 105 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 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 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.  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. 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. AJKCAS – Study Material – Odd Semester 2019 - 20 | 77