Information Systems Analysis and Design Midterm #3
Associations Among Things
Association— a naturally occurring relationship between classes (UML term)
Identifying Use Cases
There are several ways to approach use case identification 1) Identify the actors, the users of the system Establish how they use the system, what they use to achieve it (e.g., Annie's main job is to issue bikes, so that will be one of the use cases) 2) Identify use cases from scenarios. A scenario describes a specific sequence of events (e.g., what happened when Annie successfully issued a bike to a customer)
Functionality of the Use Case
Use cases define functional requirements A use case diagram lists the main things (functions) that the system does. Each use case is linked by a line to an actor.
Generalization and Inheritance
Used for modeling the "is a" and "is like" relationships.
Minimum and Maximum Multiplicity
l Associations have minimum and maximum constraints l minimum is zero, the association is optional l If minimum is at least one, the association is mandatory
Brainstorming Technique
Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded?
Examine List
Attributes l Sometimes it is clear that a noun is an attribute (e.g., bike number, type, size, make, model, daily charge rate, deposit l Some nouns may sound like an attribute l Specialist bike sounds like an object. Would it have attributes and behaviors on its own Redundant l Sometimes the same concept appears in the text using different words Too vague l Too tied up with physical inputs and outputs (e.g., receipts) l Associations - general rule is that if there is data associated with the relationship between objects, then we probably want to model it l Outside the scope of the system l Represent the whole system - reject Wheels system l Leaves us with the candidate objects: l bike, customer, hire transaction, specialist bikes
Details About Domain Classes
Attribute— describes one piece of information about each instance of the class l Customer has first name, last name, phone number l Identifier or key l One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer l Compound attribute l Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute.
Use Cases as Means of Communication
Customers Designers Users The use case should stimulate a discussion about what the system should do, mainly with people who are outside of the development team.
Use Case Diagrams
Draw for each subsystem
Identifying Actors
External objects that produce/consume data: -Must be external to the system -They interact with the system and receive some benefit from it -Must serve as sources and destinations for data (Humans, machines, external systems, sensors, organizational units, NOT databases, printer) Who is involved in major system processes (e.g., issuing a bike)? Who will use the system? Who supplies information to the system? Who will receive output from the system? Each actor can represent several different people and several different job titles (roles) The Administrator uses the system to maintain lists of customers and bikes. The Administrator can be the shop manager (Annie), the head mechanic (Naresh), the owner (Mike).
Identifying Use Cases (cont.)
1) User goal technique The user goal technique asks users to describe their goals for using the new or updated system. 2) Event decomposition technique The event decomposition technique begins by identifying all the business events that will cause the information system to respond, and each event leads to a use case.
Brainstorming Technique: Steps
1. Identify a user and a set of use cases 2. Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? 4. Continue to work with all types of users and stakeholders to expand the brainstorming list 5. Merge the results, eliminate any duplicates, and compile an initial list
Noun Analysis
1. Pick out all the nouns and noun phrases and underline them 2. This provides a long list of possible objects (or candidates 3. Reject unsuitable candidates 4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further. 5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.
User Story vs. Use Case
A User Story expresses one very specific need that a user has, written in the language of the users -Any user should be able to read a user story and immediately understand what it means A Use Case is the interaction between an actor and the system. -Scenarios (from user stories) can inform a use case, as can other techniques
What is a class?
A class is a group of objects with the same set of attributes, the same relationships and the same behavior. l When we study a problem domain, we start by finding the objects in it. l Then we work out what the classes will need (e.g., we have 600 bikes objects to represent, so then we agree upon the set of attributes those bikes have in common) l Then we need to work out what we want our bike objects to be able to do (behavior)
Scenarios
A scenario describes a series of interactions between the user and the system in order to achieve a specified goal. A scenario describes a sequence of events A careful study of scenarios depicting both typical and exceptional uses of the system is a very good way to understand what the system does and how it is used. It's a bottom up approach to understanding a system.
The Noun Technique
A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents Popular technique. Systematic. Does end up with long lists and many nouns that are not things that need to be stored by the system Difficulty identifying things that are really attributes Good place to start when there are no users available to help brainstorm
Include
An <<include>> or <<uses>> relationship is useful when you find behavior that is common to several use cases Rather than repeat a description of that behavior, the common behavior can be split off into a separate use case which is then linked to all relevant use cases with an <<include>> relationship Identifying functionality common to several use cases permits developers from wasting effort -It can be modeled once then reused as required The base use case explicitly incorporates the behavior of another use case.
Advantages of OO
Autonomous - i.e., did not depend heavily on other modules, Cohesive with a single, well-defined purpose, Easy to understand, Easily adapted to accommodate new or changed requirements, Based on data
Things in the Problem Domain Two Techniques for Identifying them
Brainstorming Technique l Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type Noun Technique l Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember
Use Cases and Brief Use Case Descriptions
Brief use case description is often a one sentence description showing the main steps in a use case
Use Cases and CRUD Technique
CRUD is Create, Read/Report, Update, and Delete (archive) Often introduced in database context Technique to validate, refine or cross-check use cases NOT for primarily identifying use cases For Customer domain class, verify that there are use cases that create, read/report, update, and delete (archive) the domain class
Just to Clarify
Called association on class diagram in UML l Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many l We are emphasizing UML in this text l Associations and Relationships apply in two directions l Read them separately each way l A customer places an order l An order is placed by a customer
Attributes and Values
Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute
Use Case Relationships
Communication association, <<include>> and <<extend>> In a use case diagram, the line linking the actor to the use case is called a communication association Both <<include>> and <<extend>> are relationships between use cases
Composition ("strong aggregation")
Composition— a whole part relationship where the parts can no longer be removed (filled in diamond symbol)
Perfect Technology Assumptions
Defer specifying technology dependent events Example: logon depending on system controls Perfect technology assumption: Separates technology dependent events from functional requirements Unlimited processing and storage capacity Equipment does not malfunction Users have ideal skill sets
Functional Decomposition
Developers decomposed and then constructed the system according to the main areas of activity • The subsystems corresponded directly to tasks that the system had to carry out • There was a clear separation between data and process
Learning Objectives
Explain why identifying use cases is the key to defining functional requirements Describe the two techniques for identifying use cases Apply the user goal technique to identify use cases Apply the event decomposition technique to identify use cases Describe the notation and purpose for the use case diagram Draw use case diagrams by actor and by subsystem
Types of Events
External Event an event that occurs outside the system, usually initiated by an external agent or actor Temporal Event an event that occurs as a result of reaching a point in time State Event an event that occurs when something happens inside the system that triggers some process reorder point is reached for inventory item
External Event Checklist
External agent or actor wants something resulting in a transaction Customer buys a product External agent or actor wants some information -Customer wants to know product details External data changed and needs to be updated -Customer has new address and phone Management wants some information -Sales manager wants update on production plans
More Complex Issues about Classes: Generalization/Specialization Relationships
Generalization/Specialization l A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy l Superclass l the superior or more general class in a generalization/ specialization hierarchy l Subclass l the subordinate or more specialized class in a generalization/ specialization hierarchy l Inheritance l the concept that subclasses classes inherit characteristics of the more general superclass
A Simple Example of the Wheels Case
Here are the UML symbols for the use case using the Wheels case example.
Temporal Event Checklist
Internal outputs needed at points in time -Management reports (summary or exception) -Operational reports (detailed transactions) -Internal statements and documents (including payroll) External outputs needed at points of time -Statements, status reports, bills, reminders
All Objects Belong to Classes
It is the class that determines the structure and behavior of its objects, A class is used like a template for creating objects in its form, Objects are sometimes called instances of classes, The process of creating a new object belonging to a class is called instantiation
Event Decomposition Technique
More Comprehensive and Complete Technique -Identify the events that occur to which the system must respond. -For each event, name a use case (verb-noun) that describes what the system does when the event occurs Event- something that occurs at a specific time and place, can be described, and should be remembered by the system
Objects Form Class Diagram
Noun analysis gives us a good start, but it is only a starting point Iterations and further modeling will uncover other classes or reject some classes
An Easier way to derive Classes
People (e.g., customers, employees, students, librarians) Organizations (e.g., companies, universities, libraries) Physical things (e.g., books, bikes, products) Conceptual things (e.g., book loans, customer orders)
Background
RECALL: The software development methodology didn't emerge until the 1960s. l The systems development life cycle (SDLC) in the form of the waterfall model is likely the oldest formalized methodology for building information systems. l The main idea of the SDLC has been "to pursue the development of information systems in a very deliberate, structured and methodical way, to be carried out rigidly and sequentially." l The main target of this methodology in the 1960s has been to develop large scale functional business systems
Domain Classes - Chapter 4
Recognize some of the problems associated with traditional ways of developing software systems Explain how O-O approach addresses these problems Describe the main features of an object and why it is effective as a software construct Identify the objects and classes in a system and their attributes Explain how the concept of "things" in the problem domain also define requirements Conduct a Noun Analysis Identify and analyze data entities and domain classes needed in the system Read, interpret, and create a domain model class diagram
Testing
Software systems based on functional decomposition were still being delivered with errors in the code l They were perceived as unreliable and not sufficiently tested l This was partly because units of code were too interdependent.
Events and Use Cases
Some events that are important to a retail store's charge account processing system are shown in here. (This was also covered in some detail in the video on "identifying use cases." The functional requirements are defined by use cases based on six events. A customer triggers three events: "customer pays a bill," "customer makes a charge," and "customer changes address." The system responds with three use cases: Record a payment, Process a charge, or Maintain customer data. Three other events are triggered inside the system by reaching a point in time. Again, this is covered in some detail in the Ch. 3 video.
Example: Renting a Bike
Stephanie arrives at the shop at 9am and orders a women's mountain bike Annie sees that its number is 468 Annie enters the number into the system The system confirms that this is a women's mountain bike and displays the daily rate ($25) and the deposit ($75) Stephanie wants to rent the bike for the week Annie enters this and the system displays the total cost, $175+$75= $250 Stephanie agrees to this Annie records this on the system and the system prints out a receipt Stephanie agrees to bring the bike back by 9am on the following Saturday
Coding Maintenance
Structured software designed using functional decomposition brought with it big maintenance problems. Changes to the code created new problems ‣ introduced new bugs: a change in one place caused unexpected side-effects elsewhere ‣ the infamous "ripple effect" - software developers became aware that data in the system was accessible to all parts of the code • To prevent this, data needed to be encapsulated (protected from unauthorized access)
Extend Used as a way of specifying alternative behavior (if, then statements)
The <<extend>> relationship is used as a way of specifying significant alternative behavior in a use case It usually documents functionality that the user can opt to use over and above the norm, i.e., it documents important variations from the normal course of events Use an <<extend>> relationship if you want to describe: Behavior done only under certain circumstances (e.g., printing an extra receipt if the whole deposit is not returned) Note the direction of the arrow. The base use case does not know which use case extends it.
Behavior
The concept of objects is similar to ER diagrams l But unlike entities, objects don't just store information; they have behavior l A bike object knows (stores) its type, hire rate, and deposit. l When we design the bike object, we decide what it is able to do l An object is a bundle of data items and processes that manipulate them. l These processes are called operations.
An Event Table
The steps involved in the event decomposition described in the book are best shown in this diagram. First, consider the external events in the system environment that require a response from the system, i.e., the event that causes the system to do something. What triggers the event? The source is the external agent as the source of the data entering the system. If no data enters the system (as in temporal events), there may not be a source. This table helps to identify the use case by asking what the system does when the event occurs, and then output of that (if any) in the response. Finally, what external agent gets the output produced?
Function v Data
The structured approach built systems based on their functionality - what the system had to do, the tasks it had to carry out. The functionality of a system is much more volatile and subject to change than the data Example: Assigning Patients to Beds in a Hospital ‣ The way patients are assigned, and the way nurse rotations are carried out may change ‣ Reports and documentation may change ‣ No matter what the changes, the system will still have patients, beds, nurses, stations - the data remains the same • Thus, a system based on data would be more robust
Use Cases
The use case model consists of a use case diagram, a set of use case descriptions, a set of actor descriptions and a set of scenarios. The use case diagram models the problem domain graphically using four concepts: the use case, the actor, the relationship link and the boundary.
Summary on UML Relationships
There are four types of relationships in class diagrams l Association Relationships l Simple uni-directional or bi-directional l Whole Part Relationships l One class is a component or part of another class l Aggregation ("weak") and Composite ("strong") l Generalizations/Specialization Relationships l Inheritance
Chapter 3: Use Cases
This chapter focuses on identifying and modeling the key aspect of functional requirements- use cases In the RMO Tradeshow System from Chapter 1, some use cases are Look up supplier, Enter/update product information, Enter/Update contact information In this chapter's opening case Waiters on Call, examples of use cases are Record an order, Record delivery, Update an order, Sign in driver, Reconcile driver receipts, Produce end of day deposit slip, and Produce weekly sales reports
User Goal Technique
This technique is the most common in industry Simple and effective Interview and ask different categories of users to describe the tasks the computer can help them with Probe further to refine the tasks into specific user goals, "I need to Ship items, Track a shipment, Create a return"
What is an Object?
l At its simplest, an object is a representation of something in the application area about which we need to store data to enable the system to what the users want l For example, in the Wheels system we will want to store data about bikes l Bikes would be an object in our model and eventually in the code l The data we need to store about bikes (e.g., type, rental rate, deposit) are the attributes of the bike object
The Domain Model Class Diagram
l Class l A category of classification used to describe a collection of objects l Domain Class l Classes that describe objects in the problem domain l Class Diagram l A UML diagram that shows classes with attributes and associations (plus methods if it models software classes) l Domain Model Class Diagram l A class diagram that only includes classes from the problem domain, not software classes so no methods
Domain Class Notation
l Domain class has no methods l Class name is always capitalized l Attribute names are not capitalized and use camelback notation (words run together and second word is capitalized)
Associations
l In addition to generalization, objects are often associated with, or related to, other objects l In a domain class diagram, an association is a relationship between two classes whose instances (objects) are involved in the relationship l They can be uni-directional with an arrow at one end (à) or bi-directional (−) l They may have other properties, such as name/label, role and multiplicity
Things in the Problem Domain
l Problem domain—the specific area (or domain) of the users' business need that is within the scope of the new system. l "Things" are those items users work with when accomplishing tasks that need to be remembered l Examples of "Things" are products, sales, shippers, customers, invoices, payments, etc. l These "Things" are modeled as domain classes or data entities l In this course, we will call them domain classes. In database class you call them data entities
Domain Model Class Diagram for course enrollment at a university
l Where is each student's grade remembered in this model? l Each section has many grades and each grade is association with a student l Each student has many grades and each grade is association with a section
Aggregation Association
l Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class l Aggregation— a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol, next slide)
