Kabarak University Department of Computer Science.: Inte 313 Object-Oriented Analysis and Design

INTE 313
OBJECT-ORIENTED ANALYSIS AND DESIGN
KABARAK UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE.

Module No: Module Title: Module Leader Contact Address: Email: Cell: Module Aims & Purpose: This modules aims to introduce students to the design, development, implementation and management of large scale software engineering projects. They will also appreciate strategies to adopted in project management and formation of project teams and acquiring knowledge in testing software development. Objectives and distinctive features: To provide an understanding of the Software development Process To identify the requirement and analyze the specification To provide the risk in Software Engineering To test the software using the different types of testing techniques
Course outline
BMIT
317
inte
313
OBJECT ORIENTED ANALYSIS AND DESIGN Mr. Masese international@gmail.com 0727171725
Characteristics of Object-Oriented Paradigm, Object oriented Analysis: Use case, class and dynamic modelling, Object oriented design: architecture, developing Collaboration and Sequence diagrams, detailed design, UML modelling language: activity, component, deployment diagrams. Object constraint language, Comparison of OML and UML, Object oriented life cycle models: fountain, Software reuse, software testing, Object oriented systems, Object Oriented CASE Tools
Indicative Content:
Week 1- 3 Characteristics of object oriented paradigm, object oriented analysis, object oriented principles and their applications Week 4-5 Object oriented design: system Development Life cycle, approaches to system analysis and design & Object Oriented Methodologies Week 6 -7 Software Testing and Testing environment Week 8 -10
Prepared by Masese N
INTE 313
UML modeling language: activity, component, deployment diagrams, object costaint language, collaboration and sequence diagrams Week 10- 11 Software architecture and Design Patterns Week 12-13 User interface Design , case Tools and software reuse
Learning Outcomes: Upon satisfactory completion of this module a student should be able to: Explain the characteristics of object oriented paradigm. Understand object oriented systems and trends. Develop reusable software components Develop software using object oriented methods. Teaching and learning Strategy: Lectures, Presentations by members of the class, Case discussions, Tutorials, Assignments, Continuous assessment tests, Lab Practical, Library, appropriate software, manual/notes Instructional Materials/Equipment: Course text, Handouts, White board, Presentation slides, Journals Arrangements for revision and private study: All sessions will be supported electronically. Tutors will operate an appointment system for student consultations. Assessment Strategy: Continuous Assessment Tests: Class test I Class test II Assignments Total module work End-of-semester examination Total
20% 20% 10% 50% 50% 100%
Method of Re-assessment: Students failing this module will be re-assessed by supplementary examination. Main texts Given the breadth and dynamic nature of the subject matter, there is no single Core Text. Relevant texts include:
1. Meiler Page-Jones (2000) Fundamental of Object-Oriented Design in UML. Addison Wesley. 2. John Deacon(2004)Object-Oriented Analysis and Design,John Deacon 3. James J. Odell(1998)Advanced Object-Oriented Analysis and Design Using
UML,Cambridge University Press
Reference texts
4. Giuseppe Castagna(1997)Object-Oriented Programming,Birkhuser 5. Goran Svenk(2003)Object-Oriented Programming,Thomson Delmar Learning
INTE 313
THE OBJECT ORIENTED PARADIGM INTRODUCTION A program can be defined as Algorithms + Data Structures = Programs The main distinction between traditional system development methodologies and newer object-oriented methodologies depends on their primary focus. In an object-oriented environment, 1) Software is a collection of discrete objects that encapsulate their data as Well as the functionality to model real-world "objects." 2) An object orientation yields important benefits to the practice of software Construction 3) Each object has attributes (data) and methods (functions). 4) Objects are grouped into classes; in object-oriented terms, we discover and 5) Describe the classes involved in the problem domain. 6) Everything is an object and each object is responsible for itself. 1) Traditional approach: focuses on the functions of the system 2) Object -oriented systems development , centers on the object, which combines data and functionality Object oriented analysis and design is a collection of tools and techniques for systems development that will utilize object technologies to construct a system and its soft wares Object: object has entity that has unique identity, a set of operations that can be applied to it, and state that stores the effect of the operations'' Objects have state. Described by the values of their attributes at any point in time. The state can change. Objects have operations. The operations are the only means by which the state of an object may be changed. Also called methods or member functions. Eg: person object Namedata Basic pay.data Salary.methods() Tax.methods() Object An entity able to save a state (information) and which offers a number of operations (behaviour) to either examine or affect this state characteristics of an object Objects have an internal state that is recorded in a set of attributes.
INTE 313
Objects have a behavior that is expressed in terms of operations. The execution of an operations changes the state of the object and/or stimulates the execution of operations in other objects. Objects (at least in the analysis phase) have an origin in a real world entity. Class: A class is a user defined data type which holds both data and functions, the internal data of a class is called member data(data member) and the functions are called member functions, the member functions mostly manipulate the internal data of a class Is a user defined which defines a collection of similar objects ,the entire set of data and code of an objects can be made a user defined data type with the help of a class Structures and classes Structures contain one or more data items(members) which are grouped together as a single unit. Other hand is similar to a structure data type but it consists of only data elements but also functions which operate on the data. Secondly structure all the elements are public by default while the class it is private. Syntax of a class Class name { Private: Data_type members Implementation operations List of friendly functions Public: Data_type members Implementation operations Protected: Data_type members Implementation operations }; Where: Private: a member data can only accessed by the member function and friendly functions of that class Public: can be accessed by any function in the outside of t he class where it is declared Protected:
INTE 313
A simple class example class student { long int rollno; private: int age; // variable declaration char sex; float height; public : void getdata( );// functions declaration void disinfo(void); void process(); }; program to perform arithmetic operations using the member functions #include<iostream.h> class sample { private: int x; int y; public : void getinfo() { cout << enter any two numbers ?<<endl; cin >> x >> y; } void display() { cout << x = << x << endl; cout << y= << y<< endl; cout <<sum = <<sum() <<endl; cout <<dif = <<diff() <<endl; cout<<mul=<<mult()<<endl; cout<<div=<<div()<<endl; } int sum() { return( x+y); } int diff() { return( x-y); } int mult() { return( x*y); } int div() { return( x /y); };
INTE 313
void main(void) { sample obj1; obj1.getinfo(); obj1.display(); obj1.sum(); obj1.diff(); obj1.mult(); obj1.div(); } // program to demonstrate array of class objects #include<iostream.h> const int MAX =100; class student { private : long int rollno; int age; char sex; float height; public : void getinfo() { cout << Roll no:; cin >> rollno; cout<<Age:; cin>>age; cout <<Sex:; cin >>sex; cout<<Height:; cin>>height; } void disinfo() { cout<< endl; cout << Roll no = <<rollno<<endl; cout << Age = <<age<<endl; cout << Sex = <<sex<<endl; cout << Height = <<height<<endl; } }; // end of class definition void main() { student object[max]; // array of objects
INTE 313
int i,n; cout <<how many students ? \n<<endl; cin >>n; cout <<enter the following information. \n<<endl; for(i=0 ; i<=n-1; ++1) { int j = i; cout <<endl; cout <<record = << j+1 <<endl; object[i].getinfo(); } cout << contents of class \n; for(i =0; i<= n-1; ++i) { object[i].disinfo(); }} Inheritance: This Is the process by which objects acquire the properties of objects of another class,it supports the concept of hierarchical classification. In oop , the concept of inheritance provide the idea of reusability, this means that we can add additional feature to an existing class with out modifying it, is a relationship between different classes which share common characteristics. ability to re use the same objects which are created by the parent class If class B inherits class A, then both the operations and information structure in class A will become part of class B employee
driver
manager
Types of inheritance Single Inheritance Is the process of creating new classes from an existing base class .the existing class is known as direct base class and the newly created class is called a singly derived class. Single inheritance is the ability of a derived class to inherit the member functions and variables from the existing base class. Defining the derived class
INTE 313
The declaration f a singly derived class is as that same of an ordinary class, a derived class consist of the following components The key word class name of the derived class a single colon the type of derivation(private, public or protected) name of the base or parent class General syntax Class derived_class_name:private/public/protected base_class_name{ private: // data members public: // data members // methods protected: data members }; example class basic { private : char name[20]; long int rollno; char sex; public: void getdata(); void display(); } // end of class definition class physical_fit :public basic // class physical_fit extends public basic { private: float height; float weight; public: void getd(); void disp();
INTE 313
};
INTE 313
MULTIPLE INHERITANCE Some object-oriented systems permit a class to inherit its state (attributes) and behaviors from more than one super class. .
In the following example, classes A, B, and C are direct base classes for the derived class X: class A { /* ... */ }; class B { /* ... */ }; class C { /* ... */ }; class X : public A, private B, public C { /* ... */ }; // class X extends public A, private B, public C { /* ... */ }; Polymorphism: refers to the ability of executing different operations in response to the same message. Polymorphism can also be static or dynamic. Polymorphism is the process where identically named methods(member functions) that have different behavior depending on the type of object they refer, The process of defining a number of objects of different classes into group and call the member to carry out operation of objects using different function calls. Polymorphism can be done in the following ways: Compile time mainly achieved by function overloading and operator overloading Runtime polymorphism mainly achieved by virtual functions
shape
circle
square
10
INTE 313
Encapsulation hiding data. Objects generally do not expose their internal data members to the outside world (that is, their visibility is protected or private). Messages passing An operation is invoked when the object receives a message. Objects collaborate by sending messages. The message contains the name of the operation and possibly some parameters (this is very similar to a function call, and in some languages is implemented as a function call). Abstraction- refers to the act of representing essential features without including the back ground details. Mainly used in the classes where we define list of abstract attributes such as size, weight and cost and functions to operate on this attributes created An abstraction focuses on the outside view of an object and so serves to separate an objects essential behavior from its implementation. Deciding upon the right set of abstractions for a given domain is the central problem in object-oriented design. The following are the kinds of abstractions: Entity abstraction An object that represents a useful model of a problem domain or solution domain entity Action abstraction An object that provides a generalized set of operations, all of which perform the same kind of function Virtual machine abstraction An object that groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations Coincidental abstraction An object that packages a set of operations that have no relation to each other Modularity Modularization consists of dividing a program into modules which can be compiled separately, but which have connections with other modules. The traditional practice in the C/C++ community is to place module interfaces in files named with a .h suffix; these are called header files. Applying the Object Model Benefits of the Object Model The following are the practical benefits to be derived from the application of the object model. The use of the object model helps us to exploit the expressive power of object-based and
11
INTE 313
The use of the object model encourages the reuse not only of software but of entire designs, leading to the creation of reusable application frameworks. The use of the object model produces systems that are built upon stable intermediate forms, which are more resilient to change. The object models guidance in designing an intelligent separation of concerns also reduces development risk and increases our confidence in the correctness of our design. The object model appeals to the workings of human cognition.
Design Objectives The primary objective of the design. of course, is to deliver the requirements as specified in the feasibility report. In general, the following design objectives should be kept in mind: a. Practicality: The system must be stable and can be operated by people with average skills in their day to day operations before they are trained from time to time Efficiency: This involves accuracy, timeliness and comprehensiveness of the system output. Cost: it is desirable to aim for a system with a minimum cost subject to the condition that it must satisfy all the requirements. Flexibility: The system should be modifiable depending on the changing needs of the user. Such modifications should not entail extensive reconstructing or recreation of software. It should also be portable to different computer systems. Security: This is very important aspect of the design and should cover areas of hardware reliability, fall back procedures, physical security of data and provision for detection of fraud and abuse.
b. c. d.
e.
THE OBJECT ORIENTED ANALYSIS(OOA) Object-oriented analysis (OOA) deals with developing software engineering requirements and specifications that expressed as a system's object model Benefits OOA Maintainability through simplified mapping to the real world, which provides for less analysis effort, less complexity in system design, and easier verification by the user;
12
INTE 313
Reusability of the analysis data which saves time and costs; and depending on the analysis method and programming language through the inheritance. The object oriented systems can be easily be upgraded from small to large systems It is easy to divide the work in a project based on the objects The software complexity can be easily be solved
Classes and Objects

The Nature of an Object, What is and What isnt an Object From the perspective of human cognition, an object is any of the following: A tangible and/or visible thing Something that may be apprehended intellectually Something toward which thought or action is directed Real world objects are not the only kinds of objects that are of interest to us during software development. An object represents an individual, identifiable item, unit or entity, either real or abstract with a well defined role in the problem domain. Some objects may have crisp conceptual boundaries, yet represent intangible events or processes. Some objects may be tangible, yet have fuzzy physical boundaries. An object has state, behavior and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable. State The state of an object encompasses all of the (usually static) properties of the object plus the current(usually dynamic) values of each of these properties. The objects exist in time are changeable, have state are instantiated and can be created, destroyed and shared. The fact that every object has state implies that every object takes up some amount of space, be it in the physical world or in computer memory. Behavior Behavior is how an object acts and reacts, in terms of its state changes and message passing. The behavior of an object represents its outwardly visible and testable activity. An operation is some action that one object performs upon another in order to elicit a reaction. In most object-oriented programming languages, operations that clients may perform upon an object are typically declared as methods, which are part of the classs declaration. The state of an object represents the cumulative results of its behavior. Operations An operation denotes a service that a class offers to its clients. A client performs five kinds of operations: Modifier An operation that alters the state of an object
13
INTE 313
An operation that accesses the state of an object, but does not alter the state Iterator An operation that permits all parts of an object to be accessed in some well-defined order Constructor An operation that creates an object and/or initializes its state Destructor An operation that frees the state of an object and/or destroys the object itself In pure object-oriented programming languages, operations may only be declared as methods, since the language does not allow us to declare procedures or functions separate from any class. All methods are operations, but not all operations are methods: some operations may be expressed as free subprograms Relationships among Objects Kinds of Relationships Objects contribute to the behavior of a system by collaborating with one another. The relationship between any two objects encompasses the assumptions that each makes about the other including what operations can be performed and what behavior results. Two kinds of object hierarchies namely: Links Aggregation Links It is defined as a physical or conceptual connection between objects. An object collaborates with other objects through its links to these objects. Stated another way, a link denotes the specific association through which one object(the client) applies the services of another object(the supplier) or through which one object may navigate to another. Message passing between two objects is typically unidirectional, although it may occasionally be bidirectional. As a participant in a link, an object may play one of three roles: Actor An object that can operate upon other objects but is never operated upon by other objects; in some contexts, the terms active object and actor are interchangeable. Server An object that never operates upon other objects; it is only operated upon by other objects. Agent An object that can both operate upon other objects and be operated upon by other objects; an agent is usually created to do some work on behalf of an actor or another agent. Aggregation
Selector
14
INTE 313
Whereas links denote peer-to-peer or client/supplier relationships, aggregation denotes a whole/part hierarchy with the ability to navigate from the whole(also called the aggregate) to its parts(also known as its attributes). Aggregation is a specialized kind of association. APPROACHES TO SYSTEM DESIGN Object oriented design is an approach used to specify the software solution in terms of collaborating objects, their attributes and their methods The fundamentally approaches attempt to perform the following: a. improve productivity of analysts and programmers b. improve documentation and subsequent maintenance and enhancements. c. cut down drastically on cost overruns and delays d. improve communication among the user, analyst, designer, and programmer. e. standardize the approach to analysis and design f. simplify design by segmentation. (A) Object oriented Design It mainly deals with the associations of the different classes, objects and message passing to the classes and objects where by the entity class is an object class that contains business related information and implements the analysis classes It maps the actual problem and system responsibility into the actual model. Mainly redefine the object requirement definitions identified earlier in the program during analysis and to define specific objects (b)Prototyping This is a traditional method where by the system Analyst has to draw on paper the layout of out puts, input and database and the flow of the whole system in a paper This is time consuming process and is also prone to errors and emissions hence it is inaccurate However now days the systems analyst use the modern engineering techniques to perform the same role Major merits It encourages active end user participation Any change or modifications can be easily be made at the early stages of the system design hence ensuring quality assurance of the whole system It increases the creativity because it allows for quicker user feedback which can lead to better solutions
15
INTE 313
Major demerits It often suffer from slower performance than 3rd generation languages counter parts The scope of complexity can expand compared to the original plan. It encourages a return to the code ,implement and repair to the life cycle that used to dominate information systems (C) Rapid Application Development Is system design approach that utilizes structured prototyping and joint application development techniques to quickly develop systems The developer first builds preliminary data and process model of the business requirements then the prototypes help the analyst and users to verify those requirements and to formally refine the data process model It also encourages the participation development among system owner. Users, designers and the builders of the system (D) Model Driven Design It mainly emphasizes drawing system model to document technical and implementation aspects of a new system however this has been done through software programs like Microsoft Visio (E) Information Engineering Is a model driven and data centered but process sensitive technique for planning analyzing and designing information system, the primary tool of information engineering is data model it involves conducting business area requirement analysis form which information system applications are carved out for the entire system. Difficulties In System Analysis And Design Hardware Software The existing hardware will obviously affect the system design. The available software (operating system, utilities, language etc.) in the market will constrain the design.
BudgetThe budget allocated for the project will affect the scope and depth of design. Time-scale The new system may be required by a particular time (e.g. the start of a financial year). This may put a constraint on the designer to find the best design. Interface with other systems The new system may require some data from another computerized system or may provide data to another system in which case the files must be compatible in format and the system must operate with a certain processing cycle.
OBJECT ORIENTED METHODOLOGIES

RUMBAUGHS 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
16
INTE 313
object-oriented technique. OMT is a fast. intuitive approach for identifying and modeling all the objects making up a system. 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. Major phases available: 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. 3. A functional model, presented by data flow and constraints. THE OBJECT MODEL The object model describes the structure of objects in a system: their identity, relationships to other objects, attributes, and operations. 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. THE OBJECT MODEL 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 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.
17
INTE 313
The OMT object model of a bank system. The boxes represent classes and the filled triangle represents specialization. Association between Account and transaction is one too many; since one account can have many transactions, the filled circle represents many (zero or more). The relationship between Client and Account classes is one to one: A client can have only one account and account can belong to only one person (in this model joint accounts are not allowed). THE OMT FUNCTIONAL MODEL 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. 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 . 2. The data flow 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.
18
INTE 313
A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it. The term system is used here in a broad sense to include any process or structure. Static Model A static model can be viewed as a snapshot of a system's parameters at rest or at a specific point in time. Static models are needed to represent the structural or static aspect of a system. Dynamic Model A dynamic model, in contrast to a static model, can be viewed as a collection of procedures or behaviors that, taken together, reflect the behavior of a system over time. Dynamic relationships show how the business objects interact to perform tasks. For example, an order interacts with inventory to determine product availability.
19
INTE 313
SYSTEM DESIGN System:A collection of components that work together to realize some objective forms a system. Basically there are three major components in every system, namely input, processing and output.
SYSTEM CHARACTERISTICS : Organisation Is arrangement of components to achieve objectives Interaction Interaction refers to the manner in which each component functions with other components of the system. Interdependence Interdependence means those parts of the organization or computer systems depend on one another. Integration Integration is concerned with how a system is tied together
System development life cycle
System study is the First phrase the preliminary survey of the system is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identification of users requirement and the limitations and problems of the present system are studied
The major aim of this phrase is to:
problem identification and project initiation

20
INTE 313
background analysis inference or findings Feasibility study : feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources and .of course, the cost effectiveness. Types of Feasibility studies
(a) operational Feasibility is a measure of how a solution meets the identified system requirements to solve the problem and take advantage of the opportunists envisioned for the system (b) cultural(or political)Feasibility is the measure how the people feel a bout the solution and how it will be accepted in a given organization climate (c) Technical Feasibility is the measure of practicality of a specific solution and the availability of technical resources and expertise to implement and maintain it. Mainly consider: Is the proposed technology or solution practical? Do we currently possess the necessary technology? Do we possess the necessary technical expertise? (d) Schedule Feasibility is the measure of how reasonable the project time table is. (e) Economic Feasibility is the measure of the cost effective of the project or solution (f) Legal Feasibility is the measure of how well a solution can be implemented within existing legal frame work Objective :In the process of feasibility study, to the cost and benefits are estimated with greater accuracy.
System analysis : Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system.
The major objectives of system analysis are: Specification of what the new system is to accomplish based on the user requirements. Functional hierarchy showing the functions to be performed by the new system and their relationship with each other. List of attributes of the entities - these are the data items which need to be held about each entity (record)
21
INTE 313
System design is based on the user requirements and the detailed analysis of a new system, the new system must be designed eg input design, output design, design, database design, Coding the new system into computer programming language Testing : to remove all the bugs through unit testing, system testing, integration testing ,acceptance testing Implementation: is the stage of a project during which theory is turned into practice. During this phase, all the programs of the system are loaded onto the user's computer. After loading the system, training of the users starts
Parallel run: In such run for a certain defined period, both the systems i.e. computerized and manual are executed in parallel. This strategy is helpful because of the following:
o o
Manual results can be compared with the results of the computerized system. Failure of the computerized system at the early stage, does not affect the working of the organization, because the manual system continues to work, as it used to do.
Pilot run: In this type of run, the new system is installed in parts. Some part of the new system is installed first and executed successfully for considerable time period. When the results are found satisfactory then only other parts are implemented. This strategy builds the confidence and the errors are traced easily
Maintenance : is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environment.
Review of the system from time to time. The review of the system is done for:

knowing the full capabilities of the system knowing the required changes or the additional requirements studying the performance
22
INTE 313
TEST CASE DEVELOPMENT USING USE CASE Testing There are two philosophical views on the purpose of software testing: 1) The purpose of software testing is to demonstrate that there are no defects. 2) The purpose of software testing is to detect defects. Testing Approaches There are two general approaches to testing: white box testing and black box testing. In white box testing, test cases are formulated based on the internal design of the artifact being tested. For example, if the artifact is the code for a class, then we can use the internal logic of the class to create test cases that exercise all control flow paths through the code, so that every statement is executed at least once. In black box testing, the artifact being tested is treated as a black box that, given a set of inputs,produces some output. This means that no knowledge of the internal design of the artifact is assumed. Test cases are created based on the range of the input values that the artifact should accept (or reject) and their relationships to the expected output values. Testing Techniques 1)Coverage testing. This is a white box technique that attempts to achieve a certain level of code coverage. Typical types of coverage considered are: 1) Statement coverage requires that enough test cases be created to exercise every statement in code at least once. 2) Branch coverage requires that all the alternatives of every decision branch in the code be exercised at least once. 3) Condition coverage requires the true/false outcome of every condition in the code is exercised at least once. This is not the same as branch coverage, since the logical expression for a branch may, for example, be a conjunction of multiple conditions. 2)Boundary value testing. This is a black box testing technique, where test cases are written such that they involve input or output values that are around the boundary of their permissible range. For example, if a function takes a day of month argument then values such as -1, 0, 1,30, 31, 32 are around the boundary of permissible values and would be good input test data.
23
INTE 313
Domain analysis. This is a black box technique that involves analysing the domain of each input value, and subdividing it into sub-domains, where each sub-domain involves similar values in the sense that if you use one of these values in a test-case, it will be as good as any other value in that sub-domain. For example, the domain of an amount input value might be subdivided into the ranges 01000, 1001-100,000, and >100,000; these three sub-domains being different from an authorization point of view. Testing Stages During its development lifecycle, software is subjected to testing at a number of stages, as Summarized as 1)Every unit. Unit Testing Developers To detect any variances between the unit behaviour and its specification. 2)Some units Integration Testing To detect any discrepancies in the interfaces between the units To detect any discrepancies in the modules that makes up the application To detect any variances between the way the application, application is robust enough to undergo extensive testing performed by the user to check whether the delivered to its intended system meets his requirements customer.
3)modules combined Integration Testing
4)When an integrated system testing
5) acceptance testing
Regression Testing With any type or stage of testing, one has to deal with the problem of tested artifacts being modified. There are two ways of regression testing productively: By selecting a high yield subset of the original tests and only running these. By using appropriate testing tools to automate the testing process, so that they can be performed with minimal human intervention.
24
INTE 313
Test Planning Successful testing requires appropriate planning. Given that test planning requires substantial amount of effort and a considerable length of time, the actual planning must begin well before the artifacts to be tested are ready for testing. Test planning covers four key activities: 1) 2) 3) 4) The creation of a test strategy that will guide all testing activities. The creation of test plans for the different stages of testing. The setting up of the test environment so that the test plan can be carried out. The creation of test scripts for automated testing.
Test Strategy The test strategy provides an overall framework for all testing activities in a project (or group of related projects) The primary objectives of a test strategy are to: Ensure a consistent approach to testing at all stages. Spell out the things that are crucial to the project as far as testing is concerned (e.g., iteration speed, robustness, completeness). Provide guidelines on the relevant testing techniques and tools to be used. 1) Provide guidelines on test completion criteria (i.e., define what is good enough testing), and the expected amount of effort that should go into testing. 2) Provide a basis for reusing test cases and identifying areas that can benefit from automation. 3) Establish standards, templates, and the deliverables that need to be used/produced during testing. Test Plan A test plan is a documentation of the test cases to be performed and associated instructions for performing the tests. Two levels of test plans are often used: A master test plan is used to identify the high-level objectives and test focus areas. A detailed test plan is used to document the test cases produced as a result of analysing the test focus areas identified in the master test plan.
Test Environment
25
INTE 313
The computing environment to be used for conducting the tests needs to be planned, so that it is ready for use when testing commences. Issues to be considered include: Construction of test harnesses. A test harness is a software tool that can be used to invoke the software being tested and feed test data to it. A test harness is necessary when the software being tested cannot be executed on its own (e.g., a component) Setting up of test boxes. Later stages of testing (e.g., system testing) require the use of clean test machines that are set up specifically for the purpose of testing Creation of test databases. Most applications use a database of some form. The database schemas need to have been set up and the database populated with appropriate test data so that the tests can be carried out. Setting up of security access and accounts. Access to most applications is subject to security rights and having appropriate user accounts. Additional accounts may also be needed to access backend systems, databases, proxy servers,
6.3 System Testing As stated earlier, system testing is the most labour intensive testing stage and of direct relevance to acceptance testing. Function Testing functions/processes. Exception Testing Stress Testing operate. Volume Testing Scalability Testing scale. Availability Testing Usability Testing Documentation Testing application. Identify defects in the realisation of the business Identify incorrectly handled exception Identify stress levels beyond which the application cannot Identify data volume levels beyond which the application cannot operate. Identify the limit beyond which the application will not Measure the availability of the application over a prolonged period of time. Identify problems that reduce the applications ease of use. Identify problems in the user documentation for the
26
INTE 313
Installation application. Migration Testing
Identify problems in the installation process for the Identify problems in the migration of data from the legacy system to the application.
27
INTE 313
UML The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems Goals of UML The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices Types of UML Diagrams Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include 1) Use Case Diagram displays the relationship among actors and use cases. User case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors.
28
INTE 313
An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task. How to Draw: User Cases Diagrams Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. 2. 3. 4. 5. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.
These steps would generate this simple use case diagram:
29
INTE 313
2) CLASS DIAGRAMS Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.
30
INTE 313
A generalization is used when two classes are similar, but have some differences. Look at the generalization below:
State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.1
31
INTE 313
3) ACTIVITY DIAGRAMS Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something How to Draw: Activity Diagrams Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time
32
INTE 313
4) INTERACTION DIAGRAMS Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).
33
INTE 313
Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. the diagrams are read left to right and descending. The example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Messages pass between the different objects until the object of class 1 receives the final message.
Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML
34
INTE 313
4) PHYSICAL DIAGRAMS There are two types of physical diagrams: deployment diagrams and component diagrams Deployment diagrams It shows the physical relationship between hardware and software in a system. Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Component Diagram Component diagrams show the software components of a system and how they are related to each other Displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.
35
INTE 313
SOFTWARE ARCHITECTURE Software architecture is a description of the subsystem and components of a software system and the relationships between them, subsystem and components are typically specified in different views to show the relevant functional and non functional properties of software system In terms of object oriented development, the conceptual architecture is concerned with the structure of the static class model and the connections between the components of the model The model architecture describes the way the system is divided into subsystems or modules and how the program code is organized into files and directories and grouped into libraries The execution architecture focuses on the dynamic aspects of the system and the communication between components as tasks and operations execute The logical architecture comprise the class model while physical architecture is concerned with mapping the software onto the hard ware components Four aspects of software architecture Type of architecture example of elements example of relationships Conceptual components connectors Module sub systems,module exports,imports Code files,directors,libraries include,contains Execution tasks,threads,objects interactions uses,calls Sub system A sub system typically groups together elements of the system that share some common properties,an object oriented sub system encapsulates a coherent set of responsibilities in order to ensure that it has integrity and can be maintained Example The elements of a sub system might all deal with data management ,another element might deal with human computer interface and last element may focus on particular functional requirement application Data formatting
Data management library classes
36
INTE 313
The sub division of information has the following advantage It produces smaller units of development It helps to maximize reuse at component level It helps the developers to cope with complexity It improves maintainability It aids portability Each sub system provides services for other sub systems, and there are two different styles of communication that make this possible Client/ server : require the client to know the interface of the server sub system, but communication is only in one direction, the client request for resources from the server. Peer to peer communication: here the sub system can act as the server and client at the same time . Simple layered architecture It mainly consist of three main layers: application, data formatting and data management library classes Data formatting users the services that are provided by the data management system, this data formatted before it is passed upwards to the application layer where the application is used to provide different types of protocols for common activities being supported by the operation. Steps offer guidelines on the issue that need to be addressed during he development of a layered architecture define the criteria by which the application will be grouped into layers,the lowest layer provides primitive services for direct access to the hardware, while other layers above it provide more complex services. determine the number of layers Name the layers and assign functionality to them
37
INTE 313
Specify the services for each layer, better in the lower layers to have small number of low services that are used by a large number of services in higher layers specify the interface for each layer specify the structure of each layer .specify the communication between the adjacent layers
Model view controller The mvc architecture views. The structure is capable of supporting user requirements that are updates to the views, they are aimed for maintainability and portability of the whole architecture. Model: the model provides the central functionality of the application and is aware of each of its depend view and controller components View: corresponds to a particular style and format of presentation of information to the user Controller: accepts user input in the form of events that trigger the execution of the operations within the model Data base management issues Dbms offers support for: Different views of the data by different users Control of multi user access Security Enforcement of integrity constraints Data recovery Portability across platforms separates the application into three major components :main functionality, views that present the user interface and controller that manage the updates to
38
INTE 313
Data access via query language DESIGN PATTERNS Patters provide a means for capturing knowledge about problems and successful solution in software development, they employ best design practices and sound software development principles. Principles for pattern design Abstraction Encapsulation Information hiding Modularization Separation of concerns Coupling and cohesion Sufficiency, completeness Separation of interface and implementation Single point reference. PATTERNS AND NON FUNCTIONAL REQUIREMENTS Patterns can address the issue that are raised by non functional requirements, the important functional properties of software architecture Changeability Interoperability Efficiency Reliability Testability Reusability The main categories of patters include: A. Creational, structural B. behavioral patterns
39
INTE 313
Creational patterns They are concerned with the construction of object instances, they separate the operation of an application from how its objects are created, this decoupling of object creation from the operation of the application gives the designer considerately flexibility in configuring all aspects of the object creation Singleton :is used to ensure that only one instance of a class is created, in order to understand the use of the patterns we need to consider the circumstances under which a single instance may be required.
company
companyName CompanyAddress CompanyRegistrationNumber
// class scope(or static) attribute
// class scope operation

getCompanyDetails()
It provides the following advantages: Provides controlled access to the sole object instance as the singleton class encapsulates the instance The name space is not unnecessarily extended with the global variables The singleton class may be sub classed Structural patterns They address issues concerted with the way which classes and object are organized, they offer effective object oriented constructs such inheritance, composition to satisfy particular requirements Behavioral patterns
40
INTE 313
They address the problem that arise when assigning responsibilities to class and when designing algorithms, behavioral patterns not only suggest particular static relationship between object and classes but also describe how the object communicate. They may use inheritance structures to spread behavior from simpler components State pattern: they are localized and the behavior for different states is separated where state transitions are made explicit, the state object that is currently active indicates the current state of the context object Where a state object has no attribute relevant to a specific context object it may be shared among the context objects State object may be created and deleted as the context object changes state thus introducing the system.
41
INTE 313
Software analysis patterns Software analysis patterns or analysis patterns in software engineering are conceptual models, which capture an abstraction of a situation that can often be encountered in modeling. An analysis pattern can be represented as "a group of related, generic objects (metaclasses) with stereotypical attributes (data denitions), behaviors (method signatures), and expected interactions dened in a domain-neutral manner Describing an analysis pattern Suggestions have been raised since to have a consistent and uniform format for describing them. It includes : Pattern name: a pattern name should really reflect the meaning of what it is abstracting. It should be simple so that one can refer to it during analysis. Intent: the intent aims to describe the goal the pattern is trying to achieve. It should also describe the problem it tries to solve. Motivation: "A scenario that illustrates the problem and how the analysis pattern contributes to the solution in the concrete scenario" Forces and context: "Discussion of forces and tensions which should be resolved by the analysis pattern" Solution: "Description of solution and of the balance of forces achieved by the analysis pattern in the scenario in the motivation section. Includes all relevant structural and behavioural aspects of the analysis pattern. Consequences: this should emphasise how the goal is achieved by the analysis pattern with its limitation. Design: Suggestions of design implementations of this pattern. Known uses: Real world examples of this pattern usage. Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and
42
INTE 313
supports model-driven engineering of software systems. MDA approach OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams (e.g. class diagrams)[ OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.). Object oriented Model-driven architecture tools The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals . The OMG documents the overall process in a document called the MDA Guide. Basically, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels. In the following section "model" is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. Types of MDA tools Creation Tool A tool used to elicit initial models and/or edit derived models. Analysis Tool A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model. Transformation Tool
43
INTE 313
A tool used to transform models into other models or into code and documentation. Composition Tool A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel. Test Tool A tool used to "test" models as described in Model-based testing. Simulation Tool A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution. Metadata Management Tool A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation ) Reverse Engineering Tool A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.
Model-driven engineering (MDE) is a software development methodology which focuses on creating and exploiting domain models (that is, abstract representations of the knowledge and activities that govern a particular application domain), rather than on the computing (or algorithmic) concepts. The MDE approach is meant to increase productivity by maximizing compatibility between systems (via reuse of standardized models), simplifying the process of design (via models of recurring design patterns in the application domain), and promoting communication between individuals and teams working on the system (via a standardization of the terminology and the best practices used in the application domain).
INPUT DESIGN
44
INTE 313
They are mainly used to enter data to the database or interact with the user where he can manipulate the data . The goal of designing input data is to make data entry as easy, logical and error free from errors as possible. In entering data, operators need to know the following: to produce cost effective method to achieve the highest level of accuracy.
To ensure the input is acceptable and understood by the user; for example, filling out the date field is required through the edited format mm/dd/yy. Input stages Data recording Data transcription Data conversion Data verification Data control Data correction : collection of data at its stages : transfer of data to an input form : to conversion of the input data to computer acceptable medium : checking the conversion process : checking accuracy and controlling the flow of the data to the computer : correcting the errors that are found in any of the stages above.
Input types External : they are prime inputs for the system eg sales orders ,purchase ,invoices Internal :they are user communications with the system eg file amendments ,adjustments Operational: they are computer department s communication with the system eg job parameter, file names Computerized : they are inputs in computer media coming form other internal systems or external systems eg bank records are passed over on magnetic tape Input media INPUT DESIGN GUIDELINES The design of input play very significant role in getting the correct output. It covers all phases of input from creation of initial data (original recording) to actual entering the data to the system for processing. The input design is the link that ties the information system into the world of its users They focus on: Controlling amount of input Flexibility and validation of the data form design to ensure accuracy and efficiency of input Keeping the process simple to the users INPUT MEDIA AND DEVICES
45
INTE 313
Source data are input into the system in a variety of ways. The following media and devices are suitable for operation: a. Punch cards are either 80 or 96 columns wide. Data are arranged in a sequential and logical order. Operators use a keypunch to copy data from source documents onto cards. This means that the source document and card design must be considered simultaneously. MICR translates the special fonts printed in magnetic ink on checks into direct computer input. Mark-sensing readers automatically convert pencil marks in predetermined locations on a card to punched holes on the same card. Optical character recognition (OCR) readers are similar to MICR readers, except that they recognize pencil, ink or characters by their configuration (shape) rather than their magnetic pattern. They are often used in remote locations as freestanding input preparation devices or direct input media to the system. Optical bar code readers detect combination of marks that represent data. The most widely known system is the Universal Product Code (UPC), which codes retail items in stores. Automatic tag reading is a major breakthrough in speeding up customer service and eliminating costly data input errors at the point of sale. It is virtually impossible for the sale clerk to enter incorrect merchandise information such as department and class type data. Automatic tag reading is the ideal way to collect unit inventory information fast, accurately and economically.
b.. c d
OUTPUT DESIGN Outputs from the computer systems are required primarily to communicate the results of processing to users, they are used to provide permanent copy of the results for later consultation Output to be produced usually depends upon the following consideration: Type of Generally different levels of users will have different requirements from the : user and system. Some want exception reports (e.g. when sales fall below a certain level), purpose some want summary reports (e.g. sales quantity and value for each region) while some want details (e.g. list of invoices for a period). Again statutory reports will normally be as per requirement specified under the law and the designer will not have much flexibility to change the format. Content : The data that are needed to be included in the output. These will be related to the purpose of the output.(numeric ,alphanumeric,total) Format : This refers to the arrangement of data on the report. size of the paper, titles, headlines, colour of the paper etc.hardcopy,softcopy Frequency : At what frequency (daily, weekly, monthly, annually etc.) and when (after annual and timing closing of accounts, after the end of the fiscal Year, before the last day of every
46
INTE 313
month etc.) : Often sheer volume of the output deters one from using the output The sheer bulk of the report may also create problems for handling, filing or printing time. Sequence : The usefulness of an output very often depends on the sequence of data printed. A proper sequence will also help distribution of outputs to different users (e.g. payslips printed department-wise facilitates easier payment).reg no, sales area This relates to the content, appearance and accuracy of the output. Outputs Quality : generated for external users should be given special attention in respect of its getup, quality of paper etc. Volume Various types of outputs include External --- mainly from the out side the organization Internal within the organization Operational with in computer department eg program listings, statistics Interactive --- mainly through communication
Output media System analyst has to determine the appropriate medium for the output; this involves consideration of wide range of devices including line printer, graph plotter, type writer, visual display unit, and magnetic media. The choice of output media will be affected by the following factors: The suitability of the device to the particular application The need for the hard copy The response time The location of the users The software and hard ware available
47
INTE 313
System Description Techniques

INTRODUCTION Graphical representation of any process is always better and more meaningful than its representation in words. Moreover, it is very difficult to arrange and organize the large amount of data into meaningful interpretation of the whole. System Analysis and Design makes use of the various tools for representing and facilitating comprehension of the complex processes and procedure involved. FLOWCHARTS The pictorial representation of the programs or the algorithm is known as flowcharts. It is nothing but a diagrammatic representation of the various steps involved in designing a system. Some of the boxes which are used in flowcharts are:
A flowchart consists of a set of flowchart symbols connected by arrows. Each symbol contains information about what must be done at that point & the arrow shows the flow of execution of the algorithm i.e. they show the order in which the instructions must be executed. The purpose of using flowcharts is to graphically present the logical flow of data in the system and defining major phases of processing along with the various media to be used. Flowcharts are of three types:

System flowcharts Run flowcharts
48
INTE 313
Program flowcharts
(a) System Flowcharts System flowchart describes the data flow for a data processing system. It provides a logical diagram of how the system operates. It represents the flow of documents, the operations performed in data processing system. It also reflects the relationship between inputs, processing and outputs. Following are the features of system flowcharts:

the sources from which data is generated and device used for this purpose various processing steps involved the intermediate and final output prepared and the devices used for their storage
(b) Run flowcharts Run flowcharts are used to represent the logical relationship of computer routines along with inputs, master files, transaction files and outputs. Figure30. 2 illustrates a run flowchart.
(c) Program flowcharts
49
INTE 313
A program flowchart represents, in detail, the various steps to be performed within the system for transforming the input into output. The various steps are logical/ arithmetic operations, algorithms etc. It serves as the basis for discussions and communication between the system analysts and the programmers. Program flowcharts are quite helpful to programmers in organizing their programming efforts. These flowcharts constitute an important component of documentation for an application.
(d) Data flow diagram Data flow diagrams are the most commonly used way of documenting the process of current & required systems. As their name suggests they are a pictorial way of showing the flow of data into, around & out of a system. (e) Defining DFD Graphical representation of a systems data and how the processes transform the data is known as Data Flow Diagram (or DFD). Unlike, flowcharts, DFDs do not give detailed descriptions of modules but graphically describe a systems data and how the data interact with the system. (f) Components of DFD
50
INTE 313
DFDs are constructed using four major components

external entries data stores processes and data flows
(i) External Entities External entities represent the source of data as input to the system. They are also the destination of system data. External entities can be called data stores out side the system. These are represented by squares. (ii) Data Stores Data stores represent stores of data within the system. Examples, computer files or databases. An open-ended box represents a data/store data at rest or a temporary repository of data. (iii) Process Process represents activities in which data is manipulated by being stored or retrieved or transferred in some way. In other words we can say that process transforms the input data into output data. Circles stand for a process that converts data into information. (iv) Data Flows Data flows represents the movement of data from one component to the other. An arrow identifies data flow data in motion. It is a pipeline through which information flows... Data flows are generally shown as one-way only. Data Flows between external entities are shown as dotted lines.
(g) Physical & Logical DFD

Consider the figure30.4. It is clear
from the figure that orders are placed, orders are received, the location of ordered parts is determined and delivery notes are dispatched along with the order.
51
INTE 313
Fig 30.4 It does not however tell us how these things are done or who does them. Are they done by computers or manually and if manually who does them ? A logical DFD of any information system is one that models what occurs without showing how it occurs. A physical DFD shows, how the various functions are performed? Who does them? Consider the following figure:
Fig 30.5 The figure 30.5 is opposite, it shows the actual devices that perform the functions. Thus there is an "order processing clerk", an "entry into computer file" process and a "run locate program" process to locate the parts ordered. DFD(s) that shows how things happen, or the physical components are called physical DFD(s). Typical processes that appear in physical DFDs are methods of data entry, specific data transfer or processing methods. (h) Difference between flowcharts & DFD The program flowchart describes boxes that describe computations, decisions, interactions & loops. It is an important to keep in mind that data flow diagrams are not program flowcharts and should not include control elements . A good DFD should
have no data flows that split up into a number of other data flows
52
INTE 313
have no crossing lines not include flowchart loops of control elements not include data flows that act as signals to activate processes.
A data flow diagram uses four basic symbols to form a picture of a logical system.
Calculat e
Symbols
A Process
Square of Given
1
A process is an automated action or manual activity which takes some input and produces some output.
A Data Store
Number
File Of Integers
A Data Flow
Given Number
Permanent or semipermanent store for data/information a file of something or a variable
Source or Destination
Destinati on Identifier Source Identifie r
A data item which flows from a source or to a destination or from/to a process
A notation to indicate that a particular destination or a particular source appears more than once on a dataflow diagram.
Destinati on Identifier Source Identifie r
53
INTE 313
Level -0 Diagram
describes the overall processing of the system show one process for each major processing step or functional requirement data flows from the context appear on system diagram also (level balancing) can show a single data store to represent all data in aggregate at this level can draw duplicate sources, sinks and data stores to increase legibility
Drawing a Level 0 Diagram list the major data stores list major business steps draw a segment for each business step assemble into single DFD re-organize until satisfied number processes
Context Diagram This diagram treats the system as a black box. It focuses on the inputs and outputs to the system and the sources and destinations of these.
Making Vegetable Soup

Gas Supplier Water Supplier
54
INTE 313
Gas
Water
Soup
THE SYSTEM
Diners
Waste Water Waste Dispos al Compa ny Peelings Packaging Goods
Supermarket
55
INTE 313
Level One DFD
Gas Water 3
Gas Supplier
Add Require d
Water Supplier Water
Cooking Pot
Place in Cooking
3
Cook Soup 5
Amount
4
of
2 Ingredients Water Prepared
Pot
Soup
Prepare Serve Ingredie nts

Peelings Dirty water Waste Dispos al Compa ny 1 Water Packaging 2
Soup Diners
Soup 6
Obtain Ingredie nts

Ingredients 1 SuperGoods market
THE SYSTEM
Water Supplie r
56
INTE 313
Automatic Ticket System CONTEXT DIAGRAM

ticket_&_change ticket_request
User
money price
Automatic Ticket Machine
weekly_stats
Main Computer
Automated Ticket Machine - Context Level DFD
Automatic Ticket System

1 ATM Calculate ticket price
Level
1 DFD
User
ticket_request price
price D1 Ticket prices
ticket_ details ticket_&_change money 2
ATM
Issue ticket
ticket_details
3 ATM Record travel statistics
travel_stats D2 Travel Statistics weekly_statistics
Main Computer
weekly_statistics
4 ATM Transfer travel statistics
DFD Automated Ticket Machine - Level 1
57

Kabarak University Department of Computer Science.: Inte 313 Object-Oriented Analysis and Design

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Kabarak University Department of Computer Science.: Inte 313 Object-Oriented Analysis and Design

Hochgeladen von

Copyright:

Verfügbare Formate

INTE 313

OBJECT-ORIENTED ANALYSIS AND DESIGN