Lab # 1. Structuring System Requirements: Diagrams

Transcription

1 Lab # 1 Structuring System Requirements: Diagrams

2 Objectives 1. Use Case diagrams 2. Class Objects (CO) diagrams 3. Context Data Flow Diagrams (Context DFDs) 4. Level-0 Data Flow Diagrams (Level-0 DFDs) 5. Entity-Relationship Diagrams (ERD)

3 Structuring Systems Requirements 1) OLD STYLE: a written document with detailed identifies technical specifications, 2) MODERN (VERY PROFESSIONAL) STYLE: a set of graphical models diagrams, 3) (INTRO STYLE) a collection of usage scenarios (use cases), 4) (AGILE STYLE) a prototype, etc.

4 Use Case diagrams

5 Use-Cases and Use-Case Scenarios USE CASE is a collection of user scenarios that describe the thread of usage of a system how different users use an old software system or how they will would like to use a new one. Each SINGLE USECASE SCENARIO is described from the point-of-view of an actor a person or device that interacts with the software in some way Each SINGLE scenario answers the following questions: Who is the primary actor (user), the secondary actor (s)? What are the actor s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What variations in the actor s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

6 Use Case Diagram in UML Diagram format It is easy to mix up the definitions of use case and use case scenario. A use case (as a class) represents ALL actions that are required to enable or abandon a goal. A use case has multiple paths that can be taken by any user at any one time. A use case scenario is a single path through the use case. How to create Use-Cases (an algorithm): 1) Identify all USERS of a new system (human beings, non-human beings, other SW applications, online databases, etc.) 2) Identify all FUNCTIONES (FEATURES) of a new system 3) Identify RELATIONS between USERS and FUNCTIONS. Source:

7 Possible Use Case Diagram for a new Webster ++ System How to create Use-Case (an algorithm): 1) Identify all USERS of a new system (human beings, non-human beings, other SW applications, online databases, etc.) 2) Identify all FUNCTIONES (FEATURES) of a new system 3) Identify RELATIONS between USERS and FUNCTIONS.

8 Use Case Diagram: an example

9 Class Object (CO) diagrams

10 Data Object / Class Object Modeling A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object Class Object Name: Student Class Object Attributes: firsrt_name last_name year_of_admission major courses_taken credits_obtained home_address phone_number address etc. Class Object Functions/Methods: register for a course pay for a course get individual course schedule etc.

11 Data Objects: examples external entities things occurrences or events roles organizational units places data structures (printer, user, sensor) (e.g, reports, displays, signals) (e.g., interrupt, alarm) (e.g., manager, engineer, salesperson) (e.g., division, team) (e.g., manufacturing floor) (e.g., employee record, file, etc.)

12 Class Diagram Represent: 1) objects system manipulates 2) operations applied to objects, and 3) collaborations occurring between classes Elements of class model include: 1) data objects 2) attributes 3) operations 4) collaboration diagrams, etc. Examine the problem statement and try to find nouns that fit the following categories and produce or consume information (i.e. grammatical parse) External entities (systems, devices, people) Things (e.g. reports, displays, letters, signals) Events occurring during system operation Roles (e.g. manager, engineer, salesperson) Organizational units (e.g. division, group, team) Places Structures (e.g. sensors, vehicles, computers)

13 Class Diagram Class Objects Attributes Operations Associations: enrolled, on waiting list, etc. Source:

14 Class Diagram: an example

15 Class Diagram: an example

16 Data Flow Diagrams (DFDs)

17 Types of DFDs Context Diagram The highest level DFD is called a context diagram. Context Diagram represents the system as a single process, with all the related entities and the data flows in and out of the system. Since the data stores of the system are conceptually inside the one process, no data stores appear on a context diagram. Level-0 Diagram, Level-1 Diagram, Level-N Diagram The next level diagram, called a level 0, decomposes the one process from the context diagram into two to nine high level processes. Each process in a level 0 diagram can be decomposed if necessary. Each resulting diagram is called a level 1. Should processes in a level 1 diagram be decomposed, each resulting diagram would be called a level 2 diagram. Each one of these processes would be decomposed on a level 3 diagram, and so on.

18 DFD Levels Context DFD Overview of the organizational system Level-0 DFD Representation of system s major processes at highest level of abstraction Level-1 DFD Results from decomposition of Level 0 diagram Level-n DFD Results from decomposition of Level n-1 diagram

19 Multi-Level DFD: Webster-Plus system example Context DFD (a fragment) Main processing unit: to register for courses Level-0 DFD (a fragment) to add a course - to pay for a course - to display schedule Level-1 DFD (a fragment) to pay with credit card - to pay with cache - to pay with transfer of money Level-2 DFD (a fragment) to enter CC number - to enter FIrstName and LastName - to confirm amount to be paid

20 Context Data Flow Diagrams (DFDs)

21 Context DFD: an example Context DFD shows the system boundaries, external entities that interact with the system, and major information flows between entities and the system. NOTE: - only one process symbol, and - no data stores shown.

22 Context Diagram: An example of the University of Missouri St. Louis Student Registration System A single processing unit No data storage units Multiple data sources (providers of data, receivers of data)

23 Context DFD: an example

24 Level-0 Data Flow Diagrams (DFDs)

25 Level-0 DFD: an example Level-0 DFD shows the system s major processes, data flows, and data stores at a high level of abstraction (O after 1 st decimal point) Processes are labeled 1.0, 2.0, etc. (with 0 at the end). These will be decomposed into more primitive (lower-level) DFDs.

26 Level-0 DFD: An example Main (single) processing unit is divided into sub-units (level-0 processing units) Use of data storage units Still multiple data sources (providers of data, receivers of data) they are the same as at Context DFD

27 Level-0 DFD: An example

28 Level-n Data Flow Diagrams (DFDs)

29 Level-1 DFD: an example Level-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD. This is a Level-1 DFD for Process 4.0. (1 digit after 1 st decimal point). Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary.

30 Level-n DFD Level-n DFD shows the subprocesses of one of the processes in the Level n-1 DFD. This is a Level-2 DFD for Process 4.3. (2 digits after 1 st decimal point) Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest level of the hierarchy, it is called a primitive DFD.

31 Entity-Relations (ERD) diagrams

32 Entity-Relationship (E-R) Modeling Entity-Relationship (E-R) Diagram A detailed, logical representation of the entities, associations and data elements for an organization or business Notation uses 3 main constructs (see corresponding graphic symbols below): Data entities Relationships Attributes

33 Degree of Relationship Degree: number of entity types that participate in a relationship Three cases Unary: between two instances of one entity type Binary: between the instances of two entity types Ternary: among the instances of three entity types

34 In-classroom practice: Bradley University campus: examples of 1) 1-to-1, 1-to-many, and many-to-many relationships?

35 Cardinality Cardinality: the number of instances of entity B that can or must be associated with each instance of entity A Minimum Cardinality The minimum number of instances of entity B that may be associated with each instance of entity A Maximum Cardinality The maximum number of instances of entity B that may be associated with each instance of entity A Mandatory vs. Optional Cardinalities Specifies whether an instance must exist or can be absent in the relationship

36 An Example of ERD

37 An example of ERD

38 ERD (E-R Diagram): university-related examples

39 Unary Relationship Example Examples of Unary Relationship (Bradley University campus)

40 Example 1: Mandatory Cardinalities Example 2: One optional, One Mandatory Cardinalities