Introduction to Computer Science - PowerPoint PPT Presentation

Loading...

PPT – Introduction to Computer Science PowerPoint presentation | free to download - id: 83f935-OGZkM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction to Computer Science

Description:

Title: Introduction to Computer Science Author: John Torquato Last modified by: user Created Date: 8/5/2004 4:05:47 PM Document presentation format – PowerPoint PPT presentation

Number of Views:29
Avg rating:3.0/5.0
Slides: 56
Provided by: JohnT290
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introduction to Computer Science


1
(No Transcript)
2
Objectives
  • Explain how events can be used to identify use
    cases that define requirements
  • Identify and analyze events and resulting use
    cases
  • Explain how the concept of problem domain classes
    also defines requirements
  • Identify and analyze domain classes needed in the
    system

3
Objectives (continued)
  • Read, interpret, and create a Unified Modeling
    Language (UML) domain model class diagram and
    design class diagram
  • Use a CRUD matrix to study the relationships
    between use cases and problem domain classes

4
Overview
  • Objective refine information gathered
  • Identify use cases and problem domain classes
  • Model problem domain classes with UML notation
  • Introduce use case modeling

5
Events and Use Cases
  • Use case
  • Activity the system carries out
  • Entry point into the modeling process
  • Event decomposition help identify use cases
  • Elementary business processes (EBPs)
  • Basic unit of analysis
  • Initiated by event occurring at specific time and
    place
  • Discrete system response that adds business value

6
Figure 5-1 Identifying Use Cases by Focusing on
Users and their Goals
7
Event Decomposition
  • Event decomposition
  • Develops use cases based on system response to
    events
  • Perceives system as black box interfacing with
    external environment
  • Keeps focus on EBPs and business requirements
  • Analysts delegated particular events to decompose
  • Result of the decomposition
  • List of use cases triggered by business events
  • Use cases at the right level of analysis

8
Figure 5-2 Events Affecting a Charge Account
Processing System that Lead to Use Cases
9
Types of Events
  • External Events
  • Occur outside the system
  • Usually caused by external agent
  • Temporal Events
  • Occurs when system reaches a point (deadline) in
    time
  • State Events
  • Asynchronous events responding to system trigger

10
Figure 5-3 External Event Checklist
11
Figure 5-4 Temporal Event Checklist
12
Identifying Events
  • Three rules of thumb
  • Distinguish events from prior conditions
  • Can the transaction complete without
    interruption?
  • Is the system waiting for next transaction?
  • Trace sequence of events initiated by external
    agent
  • Isolate events that actually touch the system

13
Figure 5-5 Temporal Event Checklist
14
Figure 5-6 The Sequence of Transactions for One
Specific Customer Resulting in Many Events
15
Identifying Events (continued)
  • Identify technology dependent events
  • Example logon depending on system controls
  • Defer specifying technology dependent events
  • Perfect technology assumption
  • Separates technology dependent events from
    functional requirements
  • Unlimited processing and storage capacity
  • Equipment does not malfunction
  • Users have ideal skill sets

16
Figure 5-7 Events Deferred until Later Iterations
17
Events in the Rocky Mountain Outfitters Case
  • Developing list of external events
  • Identify all people and organizational units that
    want something from the system
  • Developing list of temporal events
  • Identify regular reports and statements that
    system must produce at certain times

18
Figure 5-8 External Events for the RMO Customer
Support System
19
Figure 5-9 Temporal Events for the RMO Customer
Support System
20
Looking At Each Event and the Resulting Use Case
  • Enter use cases in an event table
  • Event table includes rows and columns
  • Each row is a record linking an event to a use
    case
  • Columns represent key information  
  • RMO event table anatomizes customer support
    system

21
Figure 5-10 Information about each Event and the
Resulting Use Case in an Event Table
22
Figure 5-11 The Complete Event Table for the RMO
Customer Support System
23
Problem Domain Classes
  • Problem domain
  • Set of work-related things in system component
  • Things have data representation within system
  • Examples products, orders, invoices, customers
  • OO approach to things in problem domain
  • Objects that interact in the system
  • Identify and understand things in problem domain
  • Key initial steps in defining requirements

24
Types of Things
  • Things can be identified with methodology
  • Separate the tangible from the intangible
  • Include information from all types of users
  • Ask important questions about nature of event
  • What actions upon things should be acknowledged
    and recorded by the system?
  • Example case customer placing an order

25
Figure 5-12 Types of Things
26
Procedure for Developing an Initial List of Things
  • List nouns users mention when discussing system
  • Event table as source of potential things
  • Use cases, external agents, triggers, response  
  • Select nouns with questions concerning relevance
  • Further research may be needed

27
Figure 5-13a Partial List of Things Based on
Nouns for RMO
28
Figure 5-13b Partial List of Things Based on
Nouns for RMO
29
Figure 5-13c Partial List of Things Based on
Nouns for RMO
30
 Associations among Things
  • Analyst document entity associations (
    relationships)
  • Example Is placed by and works in
  • Associations apply in two directions
  • Customer places an order
  • An order is placed by a customer
  • Multiplicity the number of associations
  • One to one or one to many 
  • The associations between types of things
  • Unary (recursive), binary, n-ary

31
Figure 5-14 Associations Naturally Occur between
Things
32
Figure 5-15 Multiplicity of Relationships
33
Attributes of Things
  • Specific details of things are called attributes
  • Analyst should identify attributes of things
  • Identifier (key) attribute uniquely identifying
    thing
  • Examples Social Security number, vehicle ID
    number, or product ID number
  • Compound attribute is a set of related attributes
  • Example multiple names for the same customer

34
Figure 5-16 Attributes and Values
35
Classes and Objects
  • Domain model class diagram as UML class
  • OOA applies domain model class diagram to things
  • Problem domain objects have attributes
  • Software objects encapsulate attributes and
    behaviors
  • Behavior action that the object processes itself
  • Software objects communicate with messages
  • Information system is a set of interacting objects

36
Figure 5-17 Objects Encapsulate Attributes and
Methods
37
Domain Model Class Diagram Notation
  • Class diagram key
  • General class symbol rectangle with three
    sections
  • Sections convey name, attributes, and behaviors
  • Methods (behaviors) not shown in domain model
    class diagram
  • Lines connecting rectangles show associations
  • Multiplicity reflected above connecting lines
  • Domain class objects reflect business concern,
    policies, and constraints

38
Figure 5-21 An Expanded Domain Model Class
Diagram Showing Attributes
39
Figure 5-24 A Refined University Course
Enrollment Domain Model Class Diagram With an
Association Class
40
Hierarchies in Class Diagram Notation
  • Generalization/specialization notation
  • Inheritance hierarchy
  • Rank things the more general to the more special
  • Motor vehicle class includes trucks, cars, buses
  • Classification means of defining classes of
    things
  • Superclass generalization of a class
  • Subclass specialization of a class

41
Figure 5-25 A Generalization/Specialization
Hierarchy Notation for Motor Vehicles
42
Hierarchies in Class Diagram Notation (continued)
  • Whole-part Hierarchy Notation
  • The whole is equal to the sum of the parts
  • Two types of whole-part hierarchies
  • Aggregation association with independent parts
  • Example keyboard is part of computer system
  • Composition association with dependent part
  • Example CRT and monitor
  • Multiplicity applies to whole-part relationships

43
Figure 5-27 Whole-part (Aggregation) Associations
Between a Computer and Its Parts
44
Hierarchies in Class Diagram Notation (continued)
  • Design Class Diagrams
  • Models classes into precise software analogs
  • Includes domain class information plus methods
  • Triangle symbol between classes indicates
    inheritance
  • Properties of attributes are shown with curly
    braces
  • Class fundamentals
  • Instances of a class (objects) manage their own
    data
  • Abstract classes are not instantiated (created)
  • Subclasses inherit attributes/behaviors from
    superclass

45
Figure 5-29 University Course Enrollment Design
Class Diagram (With Methods)
46
The Rocky Mountain Outfitters Domain Class
Diagram
  • Derives from noun list developed in Figure 5-13
  • RMO domain class diagram shows attribute
  • Models do not show methods
  • Problem domain classes reflect high-level view of
    RMO use cases

47
Figure 5-31 Rocky Mountain Outfitters Domain
Model Class Diagram
48
Locations and the Crud Matrix
  • Location diagrams store data for future reference
  • Shows need for network connections
  • Creates awareness of geographic reach
  • Use caselocation matrix shows where use cases
    are performed
  • Use casedomain class matrix highlights access
    requirements 
  • Example The RMO CRUD (create, read, update, and
    delete)

49
Figure 5-32 Rocky Mountain Outfitters Location
Diagram
50
Figure 5-33a Use Caselocation Matrix for the
Rocky Mountain Outfitters Customer Support System
51
Figure 5-33b Use Caselocation Matrix for the
Rocky Mountain Outfitters Customer Support System
52
Use Cases, the Domain Model, and Iteration
Planning
  • Select use cases for further development
  • Identify risks to determine priority
  • Core architecture typically selected/implemented
    first
  • Transition into elaboration phase
  • Converting use cases into software
  • Iteratively integrate software components into
    more complex systems
  • Begin testing of software

53
Summary
  • Requirements discipline defines business
    functions
  • Key concepts use cases and problem domain
    classes
  • Use cases derive from elementary business
    processes (EBPs)
  • Three event types external, temporal, and state
  • Problem domain class category based on OOA

54
Summary (continued)
  • Multiple associations among classes
  • Attributes specific information about a thing
  • Actual software classes include behaviors
    (methods) and attributes
  • UML class diagrams show classes, attributes,
    methods, and associations
  • Domain model class diagram show domain classes in
    the users work environment

55
Summary (continued)
  • Design class diagram models software classes  
  • Generalization/specialization hierarchies allow
    inheritance from a superclass to a subclass
  • Whole-part hierarchies allow a collection of
    objects to be associated as a whole and its parts
  • Requirements are also defined with location
    diagrams, and matrices
About PowerShow.com