Vocabulary Flashcards
Actors
Classes that define roles that objects external to a system may play
Use Case
Classes that define a sequence of interactions (units of functionality) between the actor and the system.
Class
A set of objects with the same characteristics or a common implementation.
Object
Well-defined representational constructs of concrete or conceptual entities that provide an understanding of the real world
Attribute
A data value, or structural characteristic, held by an object in a cass
Operation
The specification of a function performed by an object; a behavioral characteristic of an object
Use Case modeling
An approach for describing the functional requirements of a system
Software Requirements
Describe the functionality that the system must provide for the users.
Requirements Specification
The document that needs to be agreed on by the requirements analysis and the users.
Functional requirement
Describes the functionality a system must be capable of providing in order to fulfill the purpose of the system
Nonfunctional requirement
a.k.a Quality Attribute: refers to a quality of service goal that the system must fufill
Three examples of nonfunctional requirements:
performance requirement, availability requirement, security requirement
Quality Attributes of Software Requirements Specification (SRS)
- Correct
- Complete
- Unambiguous
- Consistent
- Verifiable
- Understandable by a non-computer specialist
- Modifiable
- Traceable
Use Case Model
Describes the functional requirements of the system in terms of actors and use cases. The system is a black box. It only matters what the system does not how the system does it.
Actors that are not human include:
external systems, I/O devices, timers
Primary Actor
The actor that initiates the use case, usually the actor that gains value from the use case
Secondary Actor
An actor other than the primary actor that participates in the use case.
Five Types of Actors
- Human
- External System Actor
- Input Device Actor
- Input/Output Device Actor (typically a sensor)
- Timer Actor
Senario
Each complete sequence through the use case
Main Sequence
The most common sequence of interactions between the actor and the system
Use Case Description Sections
Use Case Name Summary Dependency Actors Preconditions Description of the Main Sequence Description of alternative Sequences Nonfunctional requirements Postcondition Outstanding Questions
Alternative Sequence
Other situations that occur less frequently
Inclusion Use Case
Functionality that is common to more than one use case, usually cannot be executed on its own. The inclusion use case is reusable.
The include relationship
The relationship between the base use case and the inclusion use case. The included use case is pointed to from the base use case by a dotted line and denoted as a relationship with the > notation.
The extend Relationship
Used to model alternative paths that a use case may take; used to show a conditional part of the vase use case that is executed only under certain circumstances; used to model complex or alternative paths.
Extension points
Used to specify the precise location in a base case where extensions can be added. (is given a name) contains a condition to select the extension use case. Only one condition can be true (Mutually exclusive)
Use Case Package
Group of related use cases that represent high-level requirements that address major subsets of the functionality of the system
Activity Diagram
Diagram that depicts the flow of control and sequence of activities, decision nodes, loops and concurrent activities; ;represents the sequential steps of a use case
Activity node
depicts one or more steps in the use case description
Decision Node
Depicts a situation in which, based on the decision, an alternative sequence could branch off of the main sequence.
Static Model
defines the classes in the system, the attributes of the classes and the relationships between the classes
Static Modeling
Refers to the modeling process and the UML class diagram notation that is used to depict the static model
Three types of relationships between classes
- Aggregation/Composition (whole/part)
- Association
- Generalization/specialization (inheritance)
Association
A static structural relationship between classes. Usually a verb. Associations are inherently bidirectional.
Multiplicity of Associations
specifies how many instances of one class relate to a single instance of another class.
Associations (UML book)
Descriptions of a set of links with common structural features, behavioral features, relationships and semantics. They are used to model a set of relationships that relate to concepts where relationships have common characteristics.
Association Class
a class that models an association between two or more classes. Most often occurs in a many to many relationship.
Compositions
Are used to model parts that exist or live and die with their associated owner; a relationship among instances.
A composite class often involves…
a physical relationship between the whole and the parts
Rank composition, aggregation and associations by strength of relationship
Composition, aggregation, association
Aggregation
Part instances can be added and removed from the aggregate whole: likely to model conceptual classes rather than physical classes.
Generalization/Specialization
Common attributes are abstracted into generalized class
Is a relationship
Generalization
Is part of relationship
Composition/Aggregation
software system context diagram
a diagram that explicitly shows the boundry between the software system and the external environment
«external input device»__________ «software system»
Inputs to
«software system» _______ «external output device»
Outputs to
«external user» ___________ «software system»
Interacts with
«external system» _______________ «software system»
Communicates with
«external timer» _________ «software system»
Signals
Four main object and class structuring models
- Entity Object
- Boundary Object
- Control Object
- Application Logic Object
Entity Object
A software object which encapsulates information (business model) including rules, relationships, data and persistence behavior.
Boundary Object
Objects that interact with the external environment.
The types of Boundary Objects
- User Interaction Object
- Proxy Object
- Device I/O Object
User Interaction Object
Software object that interacts with an communicates with a human user
Proxy Object
Object that interfaces to and communicates with an external system or subsystem
Device I/O Boundary Object
Object that receives input from and/or outputs to a hardware I/O Device
Control Object
Object that provides the overall coordination for a collection of objects.
Control Object Types
Coordinator objects, state-dependent, timer
Application logic object
Object that contains the details of the application logic
Types of application logic objects
Business logic, algorithm objects, service objects
Software system context class diagram
shows all external classes that interface to and communicate with the system
Entity Object
object that stores information. Typically persistent
Control Object
provides the overall coordination of the objects that realized a use case
Coordinator object
decision making object that determines the overall sequencing for a collection of related objects. NOT state dependent
State-dependent control objects
an object whose behavior varies in each of its states.
Timer object
a control object that is activated by an external timer, performs some action itself or activates another object to perform the desired action
Business logic object
defines the business specific application for processing a client request. goal to separate logic from entities. Prime responsibility is to encapsulate and execute the business rules
Algorithm Object
Encapsulate and execute the algorithm
Service Object
Provides a service for other objects, never initiates a request. Might encapsulate the data it needs to service client requests or access another entity object.
Dynamic Modeling
A view of the system in which control and sequencing are considered within or between objects
