Systems Analysis II Overview

1
Systems Analysis IIOverview

• INFO 355
• Glenn Booker

2
Syllabus

• This course is about understanding and applying
  Object-Oriented Analysis and Design (OOAD),
  expressed using the Unified Modeling Language
  (UML)
• Main text is UML Distilled, 3E, by Martin Fowler
• Much easier to read than the 736-page UML
  standard!

3
Your Background

• Who are you?
• How much experience do you have with
• Programming?
• Object oriented programming?
• If any, what programming languages are you most
  comfortable using?

4
More than Software a Reminder

• The course is primarily focused on software
  analysis and design
• Remember that your system will probably
  ultimately involve other things, such as
• Hardware
• Users
• Training
• Documentation, etc.

5
A Little History

• While object oriented programming has existed
  since at least 1980 (Smalltalk), there were many
  ways to describe and diagram an object oriented
  system
• Everybody had their own notation Booch,
  Rumbaugh, Jacobson, etc.
• Finally unified in 1997 with UML

6
Whats UML?

• UML, the Unified Modeling Language, is
  essentially a drawing convention to express
  object oriented software structure and
  functionality
• Just like architects use blueprints to express
  different aspects of a building (e.g. plumbing
  vs. exterior), UML has different types of drawings

7
UML Standard

• UML is defined by a standard from the Object
  Management Group (OMG!)
• Current version is 1.5, dated March 1, 2003
• Our texts objective is to extract the most often
  useful parts of UML
• English has 600,000 words, but you dont need to
  know all of them

8
Two Ways to Use UML

• UML can be used in two ways
• Sketch UML can be used to outline the purpose
  and structure of a system, and leave the small
  details to the developers discretion and
  creativity
• Blueprint UML can create a detailed blueprint
  to specify every aspect of a system, leaving
  nothing to chance
• Well use the sketch approach

9
A Future Third Way to Use UML

• Eventually, it will be possible to use UML as a
  programming language
• Diagrams are converted directly to code
  automatically
• Model Driven Architecture (MDA) is one method to
  use UML this way
• Another variant on this idea is Executable UML,
  which uses MDA

10
The Object Concept

• Before we go too far, lets define the core
  concepts
• Object
• Class

11
What is an Object?

• An entity with a well-defined boundary and
  identity that encapsulates state and behavior.
  State is represented by attributes and
  relationships, behavior is represented by
  operations, methods, and state machines. An
  object is an instance of a class. (UML 1.5
  spec)

12
Huh?

• Attributes are the data contained by an object,
  if any
• Relationships describe which objects are allowed
  to talk to each other
• The operations and methods describe the ways
  objects can interact with each other
• So objects are a set of data which can only be
  acted on in certain prescribed ways

13
What is a Class?

• A description of a set of objects that share the
  same attributes, operations, methods,
  relationships, and semantics. A class may use a
  set of interfaces to specify collections of
  operations it provides to its environment. (UML
  1.5 spec)
• Hence a class is a group of similar objects

14
The Other Way to do AD

• Earlier analysis methods were focused on process
  (such as a Data Flow Diagram, or DFD) or data
  (e.g. using an Entity Relationship Diagram, or
  ERD)
• Traditional design creates entities (data
  tables), and changes them using scripts,
  procedures, macros, or other techniques

15
What is Object Oriented?

• Object oriented (OO) methods blend data and
  process into objects, and focuses on how those
  objects interact using methods (passing messages)
• OOAD creates objects from classes, and applies
  them using their methods or operations

16
What is Object Oriented?

• The methods isolate the data, so that it cant be
  manipulated directly
• Only the methods can create, read, modify, or
  delete data
• Why is this good?

Image from Apple, Object-Oriented Programming
and the Objective-C Language
17
What is Object Oriented?

• So the purpose of object oriented analysis and
  design 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 (kind
  of like entity relationships)

18
OO Languages

• Common object-oriented languages include the
  cousins C, Java, and C (C sharp)
• Lesser known OO languages include
• Smalltalk (first OO language, 1980)
• Ada 95 (highly reliable, real-time systems)
• Objective-C (Macintosh)
• And many, even more obscure languages

19
UML Diagrams

• (See my UML Summary too)
• There are around a dozen official UML diagrams
• The core one is the Class diagram
• Each box represents a class
• Lines between boxes represent associations what
  classes can see each other

20
UML Diagrams

• Requirements are summarized in the Use Case
  diagram
• Each bubble represents a use case
• Stick people or boxes represent actors or
  external systems who interact with the system
• Lines between them represent who can use or call
  them

21
UML Diagrams

• The way classes are grouped, either logically or
  physically, are in
• Package diagram, for the smallest logical
  grouping of classes
• Component diagram, for logical structure of
  packages
• Deployment diagram, for physical location of
  classes in nodes

22
UML Diagrams

• The ways classes or objects interact to perform a
  given use case are shown by
• Activity diagram, a process flow chart
• Communication (collaboration) diagram, to show
  messages passed between objects
• Sequence diagram, also to show messages passed
  between objects

23
UML Diagrams

• More interaction diagrams
• State machine or state transition diagrams, to
  show how events change the state of objects
• Timing diagram, to show interaction between
  objects along a timeline
• Interaction Overview, a blend of the sequence and
  activity diagrams

24
UML Diagrams

• And finally, to show what particular objects
  exist at any particular time, we have
• Object diagrams, which is similar to the class
  diagram, but at one moment in time
• Composite structure diagram, which shows the
  decomposition of a class

25
Exist at any particular time?

• Yes, another key difference between OO and
  relational systems
• Entities are essentially permanent they just
  have data added to or removed from them
• Objects are created and destroyed during use of
  an OO system
• A popup window to display an error message is an
  object
• A report can be an object created before it is
  either saved as a file, or deleted

26
Other Diagrams

• Keep in mind that describing a system might want
  to include other, non-UML diagram types, such as
• Screen flow diagram, to show navigation in the
  user interface
• Decision table, to show business process rules

27
Objects and Classes

• A Class is just a template which describes what
  an object will be like when it is created
  (instantiated) based on that class
• A class is like a publisher knowing what a given
  book contains
• The object is one copy of the actual printed book

28
Iterative versus Waterfall

• We need to use a life cycle model in order to
  approach developing a system easily, and be able
  to track progress
• The waterfall life cycle is supposed to be very
  linear
• Complete each task before starting the next
  requirements, design, code, test

29
Iterative versus Waterfall

• The iterative life cycle breaks down the
  requirements into stages or subsets
• Then development focuses on completely developing
  one stage, releasing it, then adding the next
  stage
• Also called evolutionary or incremental
  development

30
Iterative Development

• This helps get critical functionality to the
  customer much faster
• Iterative development also makes it clear sooner
  if somethings wrong
• Note the spiral life cycle is a different
  animal its used for resolution of critical
  risks

31
Time Boxing

• A technique to help stay focused during
  development is to schedule using time boxing
• Short periods of time (e.g. 1-4 weeks) are
  allocated for each iteration this makes it
  clearer if your development time expectations
  are unrealistic

32
Time Boxing

• To help keep on schedule, some techniques might
  help
• Automated regression tests, such as using JUnit
  or WinRunner
• Continuous integration, using an automated build
  process with automated testing to do daily (or
  more frequent) testing
• These are also advocated by Extreme Programming
  (XP)

33
Predictive vs. Adaptive Planning

• Predictive planning for a project develops a
  plan, and measures progress against meeting that
  plan
• Adaptive planning creates a plan, but uses it
  mostly to assess the impact of changes on the
  overall schedule

34
Agile Processes

• Agile processes, such as Extreme Programming,
  generally
• Are very adaptive in nature
• Use time boxing
• Use UML as a sketching tool
• Agile processes are lightweight they have
  little documentation and few control points

35
Rational Unified Process (RUP)

• System is defined by use cases
• A use case is a major way of using the system,
  or a major type of functionality
• High level planning needs to
• Define what are the major use cases and in what
  order they will be done
• Estimate development time for each use case (as
  in time boxing)

36
RUP Iterative Development

• Each iteration implements one or more use cases
• Includes the entire life cycle (requirements
  analysis, design, implementation, and testing)
• Results in some clearly defined end product
• Is planned with a fixed time to completion

37
RUP Phases

• RUP has four phases
• Inception
• Elaboration
• Construction
• Transition

38
Inception Phase

• Conduct feasibility study
• Define approximate vision, business cases, and
  scope for project
• Develop vague estimates (size, cost, and schedule)

39
Elaboration Phase

• Refine vision
• Identify most requirements and scope
• Do iterative implementation of the systems core
  architecture
• Resolve high risks

40
Construction Phase

• Do iterative implementation of the systems
  easier and lower risk elements
• Prepare for deployment

41
Transition Phase

• Conduct beta tests
• Conduct user training
• Deploy system

42
Tailoring Processes for a Project

• The level of documentation, design detail, and
  control points used in managing a project depends
  on many things, including
• Need for customer visibility
• Level of technology, cost, and schedule risks
• Level of developer experience
• Amount of flexibility on requirements

43
Tailoring Processes for a Project

• Processes for a project can evolve
• To help assess them, plan for reviewing each
  iteration
• Called an iteration retrospective, or more
  generally lessons learned session, or a
  post-mortem
• Determine what processes worked, what didnt, and
  what will change

44
Patterns

• Gamma et al summarized 23 key patterns for OO
  software design
• Each pattern is designed to solve a common design
  problem, ranging from very low level (module
  design) to high level (architectural design)
• Patterns are not always the right answer, but
  always worth considering
• Highly recommended!

45
UML for Requirements Analysis

• During requirements analysis, you might want to
  use
• Use case diagram and the corresponding use case
  descriptions
• High level, or conceptual class diagram
• Activity or state diagrams, to understand how key
  processes work

46
UML for Design

• As the design is developed may use
• A more detailed Design Class Diagram
• Sequence and communication diagrams for key use
  cases
• Package and deployment diagrams to capture
  logical and physical structure

47
UML for Documentation

• UML can be used for various levels of
  documentation, from whiteboard sketches to
  detailed design
• Do NOT need to diagram every use case only
  complex or critical ones
• Generate software documentation from the code,
  e.g. Javadoc

48
Document the Why

• A critical element of documentation is to include
  alternatives and rationale for your decision
• What other possible solutions or designs did you
  consider?
• Why did you choose the solution you did?
• What constraints or limitations influenced your
  decision?