CTIS 359 Principles of Software Engineering System Models

CTIS 359 Principles of Software Engineering System Models

Today s objectives To explain DFDs for requirements capturing and modeling. To explain Use-Cases for requirements capturing and modeling.

Data Flow Diagrams (DFDs) Notation for writing semi-formal operational specifications Graphical notation Well-suited for analyzing/specifying traditional information-systems problems System modeled as collection of data, which are manipulated by functions Data can be persistent (stored in data repositories) Data can flow between/among functions Each function can be systematically decomposed into a more refined DFD

DFDs Created by Top-Down Analysis Create a narrative: description of system Create a Context Diagram that contains a single process ( the system ) and all entities which share data with the system Explode the parent context diagram to produce a Diagram 0 ( child ) DFD Create Diagram 1, 2,, n DFDs that represent explosions of Diagram 0, 1,, n-1 DFDs until a diagram has only primitive processes Create process descriptions to be implemented by application programs: queries, macros, reports, programming languages Narrative Context Diagram Diagram 0 DFD Diagram 1 DFDs Diagram n DFDs E-R Diagram Process Descriptions

DFDs Created by Top-Down Analysis (Cont.) CONTEXT DIAGRAM Level 1.2 DFD 2.1 2.2 2.3 Process Specification for Data Flow Diagram 2.3 Process Spec for Level 2.3 Level 0 DFD 1 2 3 4 kahgdkljhckldsajcaljscaljljakdclnh kljclkjcl;kjcl;asjca;sjcjc;kkdj;jsa;k ckjal;kjcalkjcal;jcaljcal;kjckljcakj if kjc = mjclakj then do ldclscknlskld else jhalkscjl lnhclsncdslnc end - specification

External Agents (Entity) External agent an outside person, organization unit, system, or organization that interacts with a system. Also called an external entity. External agents define the boundary or scope of a system being modeled. As scope changes, external agents can become processes, and vice versa. Almost always one of the following: Office, department, division. An external organization or agency. Another business or another information system. One of your system s end-users or managers Named with descriptive, singular noun

Data Stores (Sink) Data store stored data intended for later use. Synonyms are file and database. Frequently implemented as a file or database. A data store is data at rest compared to a data flow that is data in motion. Almost always one of the following: Persons (or groups of persons) Places Objects Events (about which data is captured) Concepts (about which data is important) Data stores depicted on a DFD store all instances of data entities (depicted on an ERD) Named with plural noun

Data Flows Data flow A data flow is data in motion. A data flow may also be used to represent the creation, reading, deletion, or updating of data in a file or database. Represent the transfer of data over time from one place (entity, process, data store) to another Examples: New Student Information New Student Information

Process Concepts Process work performed by a system in response to incoming data flows or conditions. A synonym is transform.

Common Process Errors on DFDs

Data Flow Packet Concept

Composite and Elementary Data Flows

Data Flows to and from Data Stores

Illegal Data Flows

Diverging and Converging Data Flows Diverging data flow a data flow that splits into multiple data flows. Indicates data that starts out naturally as one flow, but is routed to different destinations. Also useful to indicate multiple copies of the same output going to different destinations. Converging data flow the merger of multiple data flows into a single packet. Indicates data from multiple sources that can (must) come together as a single packet for subsequent processing.

Diverging and Converging Data Flows

CASE for DFDs (Sample Screen) from System Architect 2001

Sample Data to Process CRUD Matrix

Sample Process to Location Association Matrix

Our consulting firm has just been hired by Knights Pies to develop a system to record orders for pizza and buffalo wings. When regular customers call Knights Pies on the phone, they are asked their phone number. When the number is typed into a computer, the name, address, and last order date is automatically brought up on the screen. If the customer is new, then they are added to the system. Once the order is taken, the total, including tax and delivery, is calculated. Then the order is given to the cook. A receipt is printed. Occasionally, special offers (coupons) are printed so the customer can get a discount. Drivers who make deliveries give customers a copy of the receipt and a coupon (if any). Weekly totals are kept for comparison with last year s performance. You have the following tasks: 1. Draw the logical context level (Level 0) DFD for Knights Pies. 2. Explode the logical context level DFD for Knights Pies, creating the Level 1 DFD.

Context Diagram

Level-1 DFD

OBJECT-ORIENTED (OO) SYSTEM Object-Oriented System is composed of objects. An Object is any person, thing, or event about which we wish to store data or whose behavior we wish to capture. An Object has certain attributes and behaviours.

OBJECT-ORIENTED (OO) SYSTEM Object-Oriented Analysis (OOA) Consider the problem domain from the perspective of objects. Object-Oriented Design (OOD) Define the solution as a collection of software objects. Object-Oriented Programming (OOP) Implement the objects using OO languages.

What is UML? The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. Source: UML Reference Manual, By James Rumbaugh, Ivar Jacobson, Grady Booch.

UML Diagrams Use-Case diagram Class diagram Object diagram State diagram Sequence diagram Collaboration diagram Activity diagram Component diagram Deployment diagram

UNIFIED MODELING LANGUAGE (UML) UML is the industry standard language for specifiying, visualizing, constructing, and documenting the artifacts of OO systems. UML embodies a set of 9 unique object modeling and diagramming tools to define and model an OO System. UML is NOT a development methodolgy. UML replaces older techniques such as DFDs and ERDs.

UML DYNAMIC DIAGRAMS Use-Case Diagram Shows what a system does from an external observer Sequence Diagram Shows interactions that details how operations are carried out Collaboration Diagram Shows interactions also, but focuses on object roles instead of times that messages are sent Activity Diagram Shows flow of activities in a single process Statechart Diagram Shows the possible states of the object and the transition that causes a change in state

UML STATIC DIAGRAMS Class Diagram Shows system s classes and relationships Object Diagram Shows instances of classes Component Diagram Shows code module Deployment Diagram Shows the physical deployments.

USE CASE DIAGRAM Although each of the nine diagramming techniques in the UML is important, the central building block of the UML is the Use-Case diagram. It provides a high-level description of what the system must do. A Use-Case diagram is created for each major function of the system during the requirements gathering process. A Use-Case diagram is concerned with interactions between a user (human or another system) and the system.

USE CASE DIAGRAM BENEFITS They are regarded as an excellent technique for capturing the functional requirements. They serve as a basis for identifiying the relevant objects. They do not use special language. They allow to tell stories. Test cases can be directly drived from them. They can be used for estimating and scheduling effort.

USE CASE DIAGRAM LIMITATIONS They cannot capture non-functional requirements. They are not well-suited for safetycritical and real-time systems where greater degree of precision is required. Some customers find it hard to understand.

USE CASE DIAGRAM COMPONENTS Use-Case diagrams consists of 3 components. Actors - Any person, organization, or computer system that is external but interacting with it. An actor does not represent a specific end user, but rather represents a role that an end user can play while interacting with the system. Illustrated as stick figures. Use-Cases They are scenarios and A use-case represents a sequence of steps that define the completion of a single business task. Illustrated as ovals. Relationships Associations between an actor and use-case.

BUILDING A USE CASE DIAGRAM PROCESS Identify system boundry with actors. Identify each actor s goals when interacting with the system. Express these goals with use-cases.

IDENTIFY ACTORS Human Actors Who uses system? Who provides events and data to the system? Who gets information from the system? Non-Human Interface Points What other systems use this system? What other devices use this system? What other external event trigger system response?

Example Application - ATM Software will be developed for a bank s ATM. ATM will allow withdrawing money from accounts, depositing money to accounts, and transfering money between accounts of customers who have a bank card. ATM will get information about the customer or customer accounts from the central bank system when required. The central bank system will get a summary of the operations performed in a day from the ATM at the end of that day.

ATM Application - Actors Question: Who/what are the users of ATM application? Bank Customer Central Bank System

Example - Small Changes If the application to be developed is a branch application with the following requirement: The bank customer tells the bank clerk the operation that s/he wants to perform. Who are the actors of that system? Actor, because Bank Clerk directly intracts with the system Bank Customer Bank Clerk Branch Application

Example - Small Changes If the application to be developed is an Internet banking application: Who is the actor of that system? Bank Customer Internet Application Actor, because Bank Customer directly intracts with the system

ATM Application Use Cases Question: What do the actors identified want to accomplish by using the ATM? Actor: Bank customer Withdraw money Deposit money Transfer between accounts Actor: Central bank system Taking daily summary In addition, it will take roles in all of the use cases above

ATM Application Short Descriptions Actor: Bank customer Is the person who has a bank card and who is allowed to perform operations on ATM with his/her card Use Case:Withdraw money Defines how a bank customer withdraws money from his/her account. The bank customer should select the amount to withdraw and the customer s funds should meet the stated amount.

ATM Application Use Case Model Withdraw money Central Bank System Bank Customer Deposit money Taking daily summary Transfer between accounts

Use Case Model Dynamics of a use case may be specified by statechart diagrams sequence diagrams collaboration diagrams informal text Use-Cases diagrams accompanied by a textual documents. The combination of two is called Use- Case model.

ATM Application Withdraw Money Use Case 1. The bank customer inserts his card 2. The ATM reads the card and requests the password 3. The bank customer enters his password 4. The ATM shows the types of transactions 5. The bank customer selects withdraw money transaction 6. The ATM displays cash amounts to withdraw 7. The bank customer selects the cash amount to withdraw 8. The central bank system checks for sufficient funds 9. The central bank system debits the account 10. The ATM dispenses the cash 11. The ATM ejects the card

Use Case No 1 Use Case Name Withdraw Money Defined By Ali Veli Last Updated By Ali Veli Defined On DD/MM/ YY YY Last Updated On DD/MM/YYYY Actors: Descriptions Pre-conditions Post-conditions Priority 1 Frequency of Use Bank customer, Central Bank System Defines how a bank customer withdraws money from his/her account The central bank is online; ATM holds the amount of money withdrawn The bank customer takes the cash dispensed and the card ejected by the ATM Very Frequent ATM Application Withdraw Money Use Case Definition

Basic Flow Alternative Flows Referenced Use Cases The bank customer inserts his card 1. The ATM reads the card and requests the password 2. The bank customer enters his password 3. The ATM shows the types of transactions 4. The bank customer selects withdraw money transaction 5. The ATM displays cash amounts to withdraw 6. The bank customer selects the cash amount to withdraw 7. The central bank system checks for sufficient funds 8. The central bank system debits the account 9. The ATM dispenses the cash 10. The ATM ejects the card A1.1 The bank customer cannot insert his/her card right A1.2 ATM returns the card A1.3 Continue with Step 1 in the basic flow A2.1 The customer enters wrong password A2.2 ATM invokes the bank customer A2.3 Continue with Step 3 in the basic flow A9.1 The central bank determines the fund are not sufficient A9.2 ATM invokes the bank customer A9.3 Continue with Step 7 in the basic flow ATM Application Withdraw Money Use Case Definition Special Requirements Assumptions For withdraw money transaction type to be active, the ATM should hold the minimum cash amount displayed by the ATM for witdrawal Notes:

Some other Features of Use Case Models

<<include>> An include relationship can be used to when a particular use case is included in other use cases because it encapsulates some functionality that is used at several points in the system. This avoids having to define the same sequence of actions in multiple use cases. The including use case will continue up to the point where it includes the base use case, the full sequence of activities in the base use case will be carried out, and the including use case will carry on at the point where it left off. Source: UML- Schaum s Outline Series 2nd Edition P.29

<<include>> Factor out subfuction use cases and use the <<include>> relationship when They are duplicated in the other use cases A use case is very complex and long, and separating it into subunits aids comprehension To describe the handling of an asynchronous event such as when a user able to, at any time, select a particular window, function, etc.. Source: Larman P. 497

<<extend>> There are occasions where one use case may OPTIONALLY be extended by the functionality in another use case. This relationship is called extend.

<<extend>> Note that <<extend>> use case is triggered by some condition.

LAB You will create a use case model for a given example.

End Any questions/suggestions?