Modelling Concepts in Systems Analysis

1. IMS1805Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)

2. Agenda • Aim: To introduce modelling concepts which developed as part of O-O perspectives on systems analysis • To give a basic introduction to: • Use case diagrams • Object class diagrams • Sequence diagrams

3. 1. Use Case Modelling • Initially developed for O-O modelling, but is not inherently O-O in nature; is now used quite widely as part of many analytical approaches • Used to identify actors (stakeholders) in a system, and how they interact with system processes • Consist of: • Use case diagrams • Use case documentation • See example given in class

4. Key elements of use case models: Actors • Actors - people who use or interact with the system (like ‘stakeholders’ in soft systems terminology) • ‘Actors’ can also extend to include non-human things which interface with the system - other systems, devices, etc • Some possible variations in types of actors: • Primary vs secondary • Direct vs indirect • Abstract vs concrete • Actor definitions

5. Key elements of use case models: Use cases • Use case: Describes some aspect of what a system does (compare with functions/ processes/actions) • Logical, not physical (ie what is done, not how it is done) • Also records which actors interact with the function/activity described by the use case • Represent diagrammatically as ellipses; textually as table descriptions

6. Key elements of use case models: Associations • Association: shows which actors/objects are involved in the function/activity described by the use case • Triggers: events which cause an actor to become involved in a use case • Can also show relationships between activities/processes between use cases • ‘Extend’ relationship • ‘Include’ relationship • ‘Depends on’ relationship

7. How does a use case help systems analysis? • Similar in general intent/purpose to a DFD • Includes better descriptive detail about each process and how it is triggered, etc • Includes better information about who is involved with system processes; helps highlight stakeholders in each process (use case)

8. 2. Class Diagrams • Developed as an essential element of object modelling • Used to show the object classes and the relationships they have to each other in a system • Can be thought of as the O-O equivalent of an entity-relationship diagram, but also include attribute and behaviour information • See example shown in class

9. Key elements of a class diagram: object classes • Class = a grouping of objects defined by certain specified characteristics [Note distinction between classes and objects (eg ‘Unit’ = class; ‘IMS1805’ = object; ‘Lecturer’ = class; ‘Martin Atchison’ = object)] • Class notation: • Name (similar rules as for entities in E-R) • Attributes (similar rules as for entity attributes in E-R) • Operations (behaviours the object can perform)

10. Key elements of a class diagram: Class relationships • Inheritance: • One object class is a particular type of another object class • The lower-level class inherits the properties of its ‘parent’ • Association: • One object class uses another object class • Usually 2-way; relationship is loose, in that each object class can exist without the other • Aggregation: • A special close form of association in which one object class contains or is made up of another object class • Usually 1-way; relationship is ‘tight’ in that one object class would not exist without the other

11. Key elements of a class diagram: Class documentation • Used to record the defining characteristics of an object class and some features of inter-object relationships • Similar to the definitions of entities and their relationships in E-R modelling • For example: • Attribute visibility • Relationship multiplicities

12. How does a class diagram help systems analysis? • Similar strengths to a data model such as an E-R diagram • Enables an analyst to capture and record everything about every object class in a system, and define inter-object relationships • Direct connection to creation of class templates for coding in O-O languages • Use full class diagram features when modelling at implementation end; use only basic entity class features when modelling at business analyst end

13. 3. Sequence Diagrams • Developed initially as a part of use case diagrams to show a ‘scenario’ - a single path of processing in a use case • Then developed in their own right to show a system function as a sequence of actor or object behaviours triggered by messages coming from other actors and objects • Focus on actor/object behaviours • See example shown in class

14. Key elements of a sequence diagram: Actors/objects • As for previous diagrams. Actors and objects are system components which have certain specified attributes and behaviours • A sequence diagram aims to show behavioural interactions between actors and objects

15. Key elements of a class diagram: Operations and messages • Every system function can be defined as a series of events in which actors/objects perform some of the operations which are defined by their behaviours • Each operation in a system function is triggered by a message received from some other actor/object; in turn it initiates a message to another actor/object • Sequence diagrams identify the operations and messages which are involved in a given system function

16. Key elements of a class diagram: Timelines • A system function requires its component operations to be performed in a given sequence • The sequence is driven by the exchange of messages between operations • The timeline in a sequence diagram shows the order in which these messages are passed • (Note contrast with DFD, which shows no information about sequence of processing)

17. Other possible elements of sequence diagrams • Focus of control (execution occurrence) • Lifelines • Object creation and destruction

18. How does a sequence diagram help systems analysis? • Helps analyst to see the a system function as a narrative - storyboard showing what happens and what causes it to happen • Links operations to the actors/objects which perform them and the messages they generate

19. Cross-model analysis • Note the consistent use of model elements across the different diagram types (contrast with data vs process models) • Cross-checking for compatibility between models • Further cross-connections with other UML model types

20. Summary • Use case models, object class models and sequence models each offer different perspectives of systems • Linked with O-O thinking, but not entirely O-O based • Integrated through UML