System Development: Use Cases and Business Events

• Many new system development approaches start with requirements modelling using use cases
• A use case is an activity performed by the system in response to a user's request
• The term "use case" began with the object-oriented approach
• It is now also used for modelling functional requirements in the traditional approach
• In the traditional approach, a use case is the same as an activity or process

Business Events and Use Cases

• Each use case happens as a response to a business event
• An event occurs at a specific time and place
• Events can be described and should be remembered by the system
• Events drive or trigger all processing that a system does
• Listing and analysing events is useful when defining system requirements by identifying use cases

External Events

• External events occur outside the system, usually started by an external agent or actor
• An external agent (or actor) is a person or organizational unit supplying or receiving data from the system
• To identify external events, analysts identify external agents that might interact with the system
• A customer is a classic example of an external agent
• A customer may want to place an order for one or more products

Domain Classes

• System development includes identifying and modelling domain classes or data entities to define functional requirements
• Domain classes or data entities are what end users deal with
• Examples domain classes include products, sales, shippers, shipments, and customers
• These are referred to as "things" in the context of a system's problem domain
• The problem domain is the specific area of the user's business within the scope of the new system
• The new system involves working with and remembering "things"
• Some information systems store information about entities like customers and products
• It is important to identify essential information about these entities
• "Things" relate to people who interact with the system or other stakeholders
• For example, the system needs to store data about the thing "customer", and how they interact with other entities in the domain

UML Class Diagrams

• The UML class diagram is used to show classes of objects for a system
• A domain model class diagram shows the things in the users' problem domain
• A design class diagram is another type of UML class diagram
• A design class diagram is used when designing software classes
• On a class diagram, rectangles represent classes
• Lines connecting the rectangles show the associations among classes
• A domain class symbol is a rectangle with two sections
• The top section contains the name of the class
• The bottom section lists the attributes of the class
• The design class symbol includes a third section at the bottom for listing methods of the class, methods do not apply to problem domain classes
• Class names and attribute names use camelback (camelcase) notation, where words run together without a space or underscore
• Class names start with a capital letter
• Attribute names start with a lowercase letter
• Class diagrams use classes and associations among them
• Association relationship, generalization/specialization relationships, and whole-part relationships are relationship types found in class diagrams

Generalization/Specialization Relationships

• Generalization/specialization relationships classify things in terms of similarities and differences
• Generalizations group similar types of things
• Motor vehicles are a general class including cars, trucks, and tractors
• Specializations group different types of things
• Cars include sports cars, sedans, SUVs
• A sports car is a special type of car
• A generalization/specialization relationship structures things from the more general to the more special
• Each class might have a more general class above it, known as a superclass
• A class can have a specialized class below it, called a subclass
• Inheritance allows subclasses to share characteristics of their superclass
• Specialization classes inherit characteristics of the generalization class
• An abstract class only exists so subclasses can inherit from it
• A concrete class has actual objects
• A superclass can be abstract or concrete

Whole-Part Relationships

• People structure information by defining things in terms of their parts
• For example: a computer consists of parts; processor, main memory, keyboard, disk storage, and monitor
• A keyboard is not a special type of computer; it is part of a computer and also something separate
• Whole-part relationships show an association between one class and other classes that are parts of that class
• The whole acts as a container for the parts
• These relationships are shown on a class diagram by a line with a diamond on one end
• Aggregation is a whole-part relationship where the component parts also exist as individual objects apart from the aggregate
• Aggregation is often described as a “has a” relationship
• Composition is a whole-part relationship where the component parts cannot exist as individual objects apart from the total composition
• A whole/part relationship in which the whole has a responsibility for the part is a stronger relationship, and is usually shown with a filled-in diamond
• If the whole is deleted, all parts are deleted

Attribute Visibility

• Visibility denotes whether other objects can directly access the attribute
• A + sign indicates a visible, or public, attribute
• A – sign means that it is not visible, or private

Explore system development approaches centered around use cases, activities performed in response to user requests. Learn how business events trigger system processing. Understand the role of external events and agents in initiating system actions.