ISA Test 2

  1. Activity Diagram
    • Used for any type of process modeling activity
    • Example is a business process
  2. Process Models
    • 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
  3. Use Case
    • 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
  4. Logical Models
    • Activity Diagrams and Use Cases
    • Describe the business domain activities withou suggesting how they are conductd
    • AKA Problem domain models
  5. Physical Models
    Physical details are defined during design when logical models are refined into physical models
  6. Activities and Actions
    • Should start with a verb
    • Actions represent single
    • Activities can be decoposed further into set of activities or actions
  7. Object Node
    • Model objects that activiteis and actions modify or transform
    • Rectangles
    • Represent flow of info from one activity to another
  8. Swimlanes
    Break up into lanes so that the activity performed by that system/person is in their lane
  9. 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
  10. 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
  11. Relationships
    • 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
  12. 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
  13. Flow of Events
    • 1) Normal Flow
    • 2) Sub flows
    • 3) Alternate or exceptional flows
  14. Normal Flows
    Include only those steps that normalla re executed ina use case
  15. Sub Flows
    When normal flow decompsed in to sup flows tokeep the normal flow of event as siple as possible 
  16. Alternal/Exceptional flows
    • 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
  17. Actors
    • 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
  18. Association
    • Links actor with use casex it interacts with
    • Represents two way communication between them 
    • Filled in arrow head is one way communication
  19. Include relationship
    • 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
  20. Extend Relationshp
    • Represntes the extension of the use case to include optional behavior
    • Arrow drawn fromt eh extension use case to the base use case
  21. Generalization Relationship
    • Represents a specialized use case to more generalized one
    • Has arrow drwon from the specialied use case to the base use case
  22. 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
  23. 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
  24. 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
  25. Confirm the major use cases
    • 1) Carfully revie the current set of use cases revise as needed
    • 2) start from top again
  26. 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
  27. Structural Model
    • 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
  28. Class
    • General template that we use to creat specific instances, or objects in the problem domain
    • Two Kinds: concrete and abstract
  29. Concrete classes
    • Used to create objects
    • WHen analyst escribes applicaton domain classes
  30. Abstract Class
    • 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
  31. Attribute
    • Represnts a piece of information that is relevant to the description of the class
    • Infomration the analysis or user feels teh sytem should store
  32. Operation
    • Behavior of an analysis class
    • The actiosn to which the instancess of the class are capable of responding
    • Like methods 
  33. Generalization Relationship
    • Create classses that inherit attribues and operations of other clases
    • Uses super and subclasses
    • a-kind-of
  34. Aggregation Relationships
    • Relates parts to wholes or parts to assemblies
    • A-part-of or has-parts
    • Flip side is decompositional
  35. Association Relationships
    • Generally waker form of the agggregations relationship
    • Associations between instances of classes
    • A hybrid between the other two relationships
  36. Knowing Responsiblity
    • Those things that an instance of a class must be capable of knowing.
    • Typically knows the values of it attributes and its relationships.
  37. Doing Responsiblity
    • 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
  38. Collaboration
    • Use cases involve set of serval classes which form this
    • Allow analyst to think in terms of clients servers and contracts
  39. Client
    Object in an instance of a classs that send a request to an instance of another class for an operation to be executed
  40. Server Object
    The instance that receives the request from the client object.
  41. Contract
    Formalizes the interactions between the client and server objects
  42. Class Diagram
    • 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
  43. Derived Attributes
    • Attributes that can be calculated or derived.
    • They are denoted by placing a / before the attributes name
  44. 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
  45. Operations
    • 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.
  46. 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.
  47. Generalizaiotn Association
    • 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.
  48. Aggregation Association
    • 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
  49. Logically aggracatoin
    • 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) 
  50. Composition
    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.
  51. Object Diagram
    • 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).
Card Set
ISA Test 2
ISA Test 2