Systems Analysis II Review

1
Systems Analysis IIReview

• INFO 355
• Glenn Booker

2
OOAD

• This has been a summary of object-oriented
  analysis and design (OOAD), expressed using the
  Unified Modeling Language (UML)
• The current version is UML 1.5, but the text is
  based on the draft UML 2.0 specification

3
Classes Objects

• Classes are templates which define a set of
  characteristics
• Objects are instantiated from (created based on)
  classes
• Classes (and their resulting objects) may have
  data (attributes), functions (methods), and are
  limited whether they see each other

4
OOAD

• The objective of OOAD is to
• Define what classes need to exist
• Define the characteristics of those classes
  (attributes or data fields)
• Define the methods each class must have
• Define which classes need to see each other
  (associations)

5
The UML Diagrams

• Use Case Diagram (not OO)
• Class Diagram
• Sequence Diagram
• Collaboration (Communication) Diagram
• Object Diagram
• Package Diagram
• Deployment Diagram

6
The UML Diagrams

• State Diagram
• Screen Flow Diagram (not UML)
• Activity Diagram
• Component Diagram
• Composite Structures and Collaborations (refine
  Class Diagram)
• Interaction Overview Diagram
• Timing Diagram

7
The UML Diagrams

• The UML diagrams capture a range of information
  about a system
• The time scope of a diagram may be
• Any possible time (class diagram)
• One use case (most other diagrams)
• A set of related use cases (activity)
• The entire system at one moment (object)

8
Use Case Diagram

• The functional requirements of a system can be
  captured by describing use cases all possible
  scenarios which some user (actor) interacts with
  the system
• The use case diagram shows the use cases for the
  system, the actors, and external systems

9
Use Case Diagram

• Hence the use case diagram is slightly more
  informative than a context diagram
• The real information is in the documentation for
  each use case
• Various levels of formality may be used for
  documentation, depending on the complexity of the
  use case

10
Use Case Diagram

• The use case documentation describes the dialog
  between the user and the system, and describes
  what the system is doing that the user may not be
  able to perceive
• Use cases which are called by two or more other
  use cases can be shown as included use cases

11
Classes

• Classes may perform one or more of the following
  functions
• Manage data
• Control how a process is followed
• Serve as the user interface
• The data classes are typically discovered first,
  then control classes to manage one (or more) use
  cases, then finally the interface classes

12
Class Diagram

• The class diagram arises from capturing key
  concepts which appear in the use case
  descriptions
• Each class is defined by
• Its class name
• Its attributes and their data types
• Its methods

13
Class Diagram

• The class diagram applies to all use cases at all
  times it shows what is possible
• Classes see each other through associations,
  which
• Can show directionality
• Are labeled with a verb phrase
• Show multiplicity
• Can have end labels

14
Class Diagram Refinements

• Classes can be
• Abstract classes
• Interface classes (either provide or require an
  interface)
• Association classes
• Superclasses and subclasses
• The superclass has the general, shared traits
  the subclass has specific or unique traits
• Active classes

15
Class Diagram Refinements

• Associations can show
• Aggregation
• Composition
• Qualified association
• Attributes can be derived, or come from
  non-primitive data types
• A separate class defines non-primitive data types

16
Visibility

• Classes, methods, and attributes have the trait
  of visibility
• Public is shown with a prefix
• Private is shown with a prefix
• Protected is shown with a prefix
• By default, attributes are private classes and
  methods are public

17
Interaction Diagrams

• Sequence and collaboration (communication)
  diagrams are interaction diagrams
• They show how classes interact to perform a use
  case
• They define the need for methods and determine
  which classes are responsible for implementing
  them

18
Sequence Diagram

• A sequence diagram follows the use case
  description
• It only shows classes which participate in the
  use case
• It defines the messages which need to be passes
  from class to class
• It mandates definition of interface classes, with
  which the actor(s) communicate with the system

19
Collaboration Diagram

• The collaboration diagram shows the same
  information as a sequence diagram, but looks more
  like a class diagram
• The difference is that the connections between
  classes are labeled with message names, not
  association labels
• Messages are numbered to indicate their time
  sequence

20
Object Diagram

• The class diagram represents all classes which
  could exist in your system
• If you draw the class diagram at one moment, and
  only show the objects which exist at that moment,
  you have an object diagram

21
Package Diagram

• The package diagram shows packages
• Packages are the smallest logical grouping of
  classes
• Packages look like manila folders
• Packages can also contain other packages

22
Package Diagram

• Packages can show the classes within them, such
  as an excerpt from the class diagram
• Defining packages helps clarify the modularity of
  the system
• Dependencies between packages are shown with
  arrows
• Packages also have visibility /-/

23
Deployment Diagram

• The deployment diagram is the only diagram which
  shows the physical location of software
• The deployment diagram consists of nodes, which
  are shown by 3-D boxes

24
Deployment Diagram

• A node can represent hardware (a server) or an
  operating system (Solaris 6.7)
• Nodes contain the artifact files (exe, dll, jar,
  scripts, data, HTML)
• Nodes are connected by communication paths, which
  show the protocol and type of network
  (http/Internet)

25
State Diagram

• A state diagram shows how a single type of object
  changes during one or more use cases
• A state is a mode or setting which affects how
  the system will respond to the next input
• Inputs could come from an actor or external system

26
State Diagram

• We want to use a state diagram if the
  interpretation of user actions depends on the
  history of previous actions
• Rounded rectangles show states, and between them
  are the possible transitions
• Transitions typically show the action which is
  needed for a transition to occur other
  conditions may be added

27
Screen Flow Diagram

• Not a UML diagram, the screen flow diagram is
  used to show the primary paths of navigation
  available to the user
• It looks like a state diagram, but now the shapes
  represent user interface screens, and the lines
  represent possible navigation paths

28
Activity Diagram

• The activity diagram is a process flowchart
• It could represent one use case, or show
  connection among several use cases
• Notation also looks like a state diagram, but
  here, shapes are processes, and the lines show
  process flow

29
Activity Diagram

• Decisions are shown with diamond shapes
• The process flow can be split with a fork, and
  reconnected with a join when all the inputs
  have been reunited
• A join specification can be added
• Partitions can be used to create a swimlane
  diagram

30
Activity Diagram

• A time signal can be used to indicate when a
  process waits for a certain period to pass, or
  a certain time to arrive
• A send signal initiates some timed event
• A receive signal ends the timed event

31
Composite Structures

• Composite structures are a way to show the
  internal details of a class
• Essentially, this is breaking a class into
  logical subsystems or components
• They are run-time groupings, as opposed to the
  packages, which are compile-time groupings

32
Component Diagram

• A component is a modular, deployable, and
  replaceable part of the system
• Typically has more than one class in it
• Is defined by its behavior interfaces
• It may be implemented by one or more artifacts
• Mostly a marketing concept

33
Collaborations

• A collaboration is a process which is performed
  using a defined set of classes
• A collaboration is typically a process which
  doesnt have unique data or methods which would
  make it a class
• Its shown on the class diagram with an oval, and
  dashed lines connecting it to its classes

34
Interaction Overview Diagram

• An Interaction Overview diagram is a blend of the
  activity diagram with two or more interaction
  diagrams (typically sequence diagrams)
• Start with an activity diagram, then replace the
  activity boxes with really big boxes which
  contain an interaction diagram for each
  significant activity

35
Timing Diagram

• Timing diagrams are another type of interaction
  diagram, with time constraints on most
  transitions
• This diagram works better for tracking several
  simple objects, versus one complex object for a
  state diagram
• Shows several objects, their possible states, and
  what events and time constraints are put on
  transitions between those states

36
Thats It!

• Those are the UML diagrams to capture the results
  of OOAD
• The nearly mandatory ones are
• Use case diagram
• Class diagram
• Sequence diagram (for complex use cases)
• The rest are used as needed