- Used for any type of process modeling activity
- Example is a business process
- Depict how a business system operates
- Processes or activities that are performed and how objects (data) move amoung them
- Can be used to document current or new system being developed
- Formal way of represetnting the way in which a business system interacts with it's environment
- Illustrates the activities performed byt the users of the system
- External or functional view of a business process
- Shows how the users view the process rather than the internal mechanisms of operation
- Activity Diagrams and Use Cases
- Describe the business domain activities withou suggesting how they are conductd
- AKA Problem domain models
Physical details are defined during design when logical models are refined into physical models
Activities and Actions
- Should start with a verb
- Actions represent single
- Activities can be decoposed further into set of activities or actions
- Model objects that activiteis and actions modify or transform
- Represent flow of info from one activity to another
Break up into lanes so that the activity performed by that system/person is in their lane
Use Case Details
- Simple descritions of a system functions from the birds eye view of the users and portray the basic functions of the system
- Each use case describes one and only one function in which users interact with the system
- Each execution path throught the use case is refrred to as a scenarior
- Gather info through JAD, observation, interviews
Types of Use Cases
- Overview use case: have analysis and user agree on hig level overviewo f the requirments/basic info
- Detail use Case: documents as far as possible all the info needed for the use case
- Essential use case: describes ony the minimum esssential issues necessary to understand the requried functionality
- Real use case: Goes futhor and describes a specific set of steps
- Association: documents the communicate that takes place between the use case and the actors
- Extend: represents the extension of the functionality of the use case to incorporate option behavior
- Include: represents the mandatory inclusion of another use case it enables functional decomposition which is the breaking up of a complex use case into several similar ones
- Generalization: allows use cases to support inheritance The common or generalized behavior that both the name new patient appointment and name old patient appointment use case contain would be placed in the generalized make appointment use case
The common or generalized behavior that both the name new patient appointment and name old patient appointment use case contain would be placed in the generalized make appointment use case
Flow of Events
- 1) Normal Flow
- 2) Sub flows
- 3) Alternate or exceptional flows
Include only those steps that normalla re executed ina use case
When normal flow decompsed in to sup flows tokeep the normal flow of event as siple as possible
- Do happen but not considered to be the norm
- Must be documeted
- These will be seperate use cases that can be intgergrated via extend relationship
- Labeled stick figures
- Not a specific user but instead a role that a user can play while interacting with the system
- Actors represent the principal elements in the environemtn in which the system operates
- Links actor with use casex it interacts with
- Represents two way communication between them
- Filled in arrow head is one way communication
- Represnte the inclusion of the functionality of one use casex within another
- Has an arrow drawn from the abase use case to the used use case
- Represntes the extension of the use case to include optional behavior
- Arrow drawn fromt eh extension use case to the base use case
- Represents a specialized use case to more generalized one
- Has arrow drwon from the specialied use case to the base use case
Creating Diagrams steps
- 1) Identify Major use cases
- 2) Expand the major use cases
- 3) Confirm the major use cases
- 4) Create the use case diagram
Indetify the major use cases
- 1) Reveiw the actifty diagram
- 2) Find the subjects boundaires (scope)
- 3) Identify primary actor and their goals
- 4) Identify and wirte the overviwo f the major use cases for the above
- 5) Carefully revie the current use case and revise if needed
Expand the major use cases
- 1) Choose one of the use cases to expand
- 2) Start filling in the detail of the chosen use case
- 3) Write ten normal flows of events of the use case
- 4) If the normal flow of event to the use case
- 5) If the normal flow of events is too complex or long decompose into sub flows
- 6) List the possible alternate or exceptional flows
- 7) For each alternate or exceptional flow list how the actor system should react
Confirm the major use cases
- 1) Carfully revie the current set of use cases revise as needed
- 2) start from top again
Create teh use case diagram
- 1) Draw the subject boundary
- 2) Place the use case on the diagram
- 3) Place the actor
- 4) Draw the associations
- Formal way represnting objects used and created by business system
- Illustrates peaople, places or things and how they relate
- Represent the things, ides or concepts (which are the objects) in the domain of the problem
- Represent the relationships, collaboratoin between then and each of their responsibliblites
- General template that we use to creat specific instances, or objects in the problem domain
- Two Kinds: concrete and abstract
- Used to create objects
- WHen analyst escribes applicaton domain classes
- Don't exist in real world
- Usefull abstractions
- Ex: If we had employee and customer, we may make a generalized class with both called person
- Represnts a piece of information that is relevant to the description of the class
- Infomration the analysis or user feels teh sytem should store
- Behavior of an analysis class
- The actiosn to which the instancess of the class are capable of responding
- Like methods
- Create classses that inherit attribues and operations of other clases
- Uses super and subclasses
- Relates parts to wholes or parts to assemblies
- A-part-of or has-parts
- Flip side is decompositional
- Generally waker form of the agggregations relationship
- Associations between instances of classes
- A hybrid between the other two relationships
- Those things that an instance of a class must be capable of knowing.
- Typically knows the values of it attributes and its relationships.
- Those things that an instance of a class must be capable of doing.
- An instance of a class can execute its operations or it can request a second instance to execute its operations on behalf of the first instance
- Use cases involve set of serval classes which form this
- Allow analyst to think in terms of clients servers and contracts
Object in an instance of a classs that send a request to an instance of another class for an operation to be executed
The instance that receives the request from the client object.
Formalizes the interactions between the client and server objects
- Static model that shows the classes and the relationships among classes that remain constant in the system over time.
- Depicts classes, which include both behavior and states, with the relationships between the classes
- Attributes that can be calculated or derived.
- They are denoted by placing a / before the attributes name
Visibility of Attribute
- Level of information hiding to be enforced for the attribute.
- It can be public (+), protectee (#), or private (-).
- Public: not hidden from an other object
- Protected: hidden from all other classes except it’s immediate subclasses
- Private: hidden from all other cla
- Actions or functions that a class can perform.
- Those functions available to all classes are not explicitly shown.
- The visibility of an operation can be designated public, protected, or private as well.
Three Types of Operations
- Constructor: Create a new instance of a class
- Query: Makes information about the state of an object available to other objects but doesn’t alter object in any way
- Update: Changes the value of some or all the objects attributes which may result in a change in the objects state.
- Shows that one class (subclass) inherits from another class (superclass)
- meaning that the properties and operations of the superclass are also valid for object of the subclass.
- This is shown with a solid line from teh subclass to the superclass and a hollow arrow pointing at the superclass.
- Aggregations association is used when classes actually comprise other classes.
- Typically can identify these kinds of associations when you need to use words like is a part of or is made up of to describe the relationship
- Logical aggregation and composition
- Represtented by (hollow white diamond)
- means it is possible for a part be associated with multiple wholes or that is relatively simple for the aprt to be removed from the whole (use Is a part of)
Composition is used to portray a physical part of relationships and is shown by a black diamond. It implies that the part can be assocaited with only a single whole.
- Object Diagram is a type of static structure diagram.
- It is essentially an instantiation of all or part of a class diagram. Can be useful when trying to uncover details of a class.
- Generally it is easier to think of concrete objects (which are these instances) rather than abstractions of objects (classes).