Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design






Analysis: develop models around what system is to do
Requirements: individual statements that define what a system needs to do
Use cases: scenarios and diagrams that define what system does from user's point of view
High-level classes diagrams: objects which need to be represented to faithfully represent the problem. Very little detail.
Sequence Diagrams: diagrams that defines what takes place and when (in terms of domainlevel objects)
Users very involved with the process
 Design: developing a solution: how to solve the problem
 Detailed class model: making the set of classes concrete to the level that someone could implement the attributes and methods of each class.
 Detailed sequence diagram: tracing operations through the system
 State models: following the state changes of critical objects
 The user is minimally involved with the process




Process: o "If you can't describe what you're doing as a process, you don't know what you're o doing"- William Edwards Deming, 1931
Steps or guide to follow to improve the chances of delivering a successful system.


Must be repeatable
Must be formalized – not just a collection of emails or unorganized notes. o If no process: success depends on few dedicated heroes: not sustainable/doesn’t scale up.
Requirements: determining what the system is supposed to do
Requirements analysis: digging into the details, are they valid, are they good requirements, . . .
Diagrams: o Code is too detailed and hard to write o Need a notation that allows us to talk about system without having to write code
 Answer: draw pictures! o o
Pictures allow us to capture important concepts without getting embroiled in details
But which pictures
©2011 Mike Rowe
4:46 AM
Page 1 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design

 o
 An abstract model of a system. It’s easier to debug and discuss a model than completed code
 Need rules for interpreting the diagrams to avoid ambiguity
 In the early 1990s there was not a single universal method of modeling pictures.
Define Classes and their interactions at various levels
Evaluation: o Do we have a good set of requirements, o o
Do we have Classes that satisfies requirements,
Do the Classes exhibit high cohesion, low coupling, efficient, …
Patterns: solutions to common problems
1.4.1
Traditional:
 Waterfall model: requirements analysis, design, code, test – no backtracking of phases o o
"Big bang" approach: release everything all at once
Depends on being able to freeze requirements, but we have found that this is hard to do o in practice.
Sometimes used for very large, fixed-price development contracts
 This type of contract uses Waterfall process as very little opportunity for change and the necessity to do very detailed planning and specification early to make sure that everything comes together.
Problems with the Waterfall: o Generally, customers always want changes
 In a Classic Waterfall process, changes require restart or a great deal of redo. o
Most Waterfall methods follow an evolved waterfall method that does tolerate some change.
Big Bang does not give customers exposure to interim progress, thus they have little opportunity for feedback and midcourse corrections.
1.4.2
Iterative



A partial system is often better than nothing at all, if that system contains the right pieces
Is a logical evolution of Waterfall method
Iterations: o Identify sets of use cases or requirements and build releases around these sets o o
Successively add to the functionality of releases by successfully adding more use cases.
Why are use cases a good choice for iteration planning?
1.4.3
Spiral model:
 Spiral is a kind of Iterative model.
 Analyze risks, plan/requirements analysis for cycle: plan, design, implement, test/evaluate
 Each spiral adds to previous functionality
©2011 Mike Rowe
4:46 AM
Page 2 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design



Supports iterative development: implementing piecewise
Makes risk analysis explicit
At the end of each spiral the test and evaluate results will help us decide what to do in the next iteration: o Add new functionality. o o o
Halt and declare the project complete
Halt and declare the project hopeless and not worth further investment
Redo the previous iteration to make it work better or differently.
1.4.4
Numerous other models have been developed
 Good processes: include "best practices" including o Iterative development (Fowler: “only avoid iterative development if you want project to o fail”)
Manage requirements o o o o
Visually model software (e.g.: UML)
Continuously verify software quality: all team members involved at all phases
Control changes to software
Use component-based architecture and COTS


Nontrivial piece of reusable software (module, package, subsystem)
Fulfills clear functionality




Has clear boundaries
Can be integrated into a well-defined architecture
Shifts development away from one-line-at-a-time programming to composing software out of components
Generally very solid / bug free / efficient
1.4.5
Agile-based Methods
 Agile methods are adaptive rather than predictive. o Traditional engineering methods tend to try to plan out a large part of the o o development in great detail for a long span of time, this works well for traditional engineering work like bridges, buildings, etc.
So traditional engineering methods try to resist change.
But, with software we expect change and change will happen! The agile methods welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves. http://www.martinfowler.com/articles/newMethodology.html#FromNothingToMonu mentalToAgile
 From: http://en.wikipedia.org/wiki/Agile_software_development (with some editing by
Rowe) o Most agile methods attempt to minimize risk by developing software in short timeboxes called iterations, which typically last from one to four weeks.
©2011 Mike Rowe
4:46 AM
Page 3 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design o o o o o o
Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation.
 While with a typical non-Agile development processes, an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration.
Agile processes expect change to happen. So, each iteration designs and implements
only the minimum amount to satisfy the needs for that release. This means that previously completed design and code will need to adjust as iterations continue. This adaptation is an optimization process is called refactoring.
At the end of each iteration the team reevaluates project priorities.
Agile methods emphasize real-time communication, preferably face-to-face, and minimize the formality of written documents.
Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers"
(customers are the people who define the product; they may be product managers, business analysts, or actual customers). The bullpen may also include testers, interaction designers, technical writers, and managers.
Agile methods also emphasize working software as the primary measure of progress.
Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
©2011 Mike Rowe
4:46 AM
Page 4 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Figure 1. The Agile SDLC. From http://www.ambysoft.com/essays/agileLifecycle.html
©2011 Mike Rowe Page 5 04/15/2020 4:46 AM

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Figure 2: The Agile Model Driven Development (AMDD) Lifecycle.
©2011 Mike Rowe Page 6 04/15/2020 4:46 AM

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
An object is a thing. Generally, a physical, real-world thing, but it can be a virtual entity.
 An object has an identity (name) which differentiates it from other similar objects o It generally has some lifespan
 o Its behavior/response to a message will generally depend on its state.
State is based on the data, which is maintained by the object. o o
These data are generally called attributes.
Attributes can change value
 o Examples:
 Robots have position, identification, voltage level, … data.
 A Car can be running or not running, moving or not moving, out of gas, at a location, …. All of these attributes make up its state.
It responds or behaves to messages through an interface based on its state. o The number of messages is generally small o o
Object behavior is based on the content of the message and the state of the object
Examples:
 Turn ignition key of a car (message) will start the car if the car is not already running, has gas, ...
2.1.1
Example
 Identity: MyClock
 Messages: reportTime, resetTimeTo( newTime )
 Behavior: good objects encapsulates the how it implements its behavior. Could be a Sun dial, Hour glass, atomic clock, pendulum, water clock, …
2.1.2
Messages
Selector: each message has a key word (selector is a name of a method/function), which indicates which interface is being used.
 A selector is generally associated with specific number(s) of arguments and their type(s) –
Syntax
2.1.3
Interfaces
Public interfaces define the set of messages to which an object unconditionally responds.
Private interfaces are a set of messages that only a selected set of functions can use. This narrows the fan out/in of message flows and makes the system more manageable.
 Interfaces should avoid strong connection to attributes. This helps limit coupling.
©2011 Mike Rowe
4:46 AM
Page 7 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.1.4
Classes
“A class describes a set of objects with equivalent roles in the system.”
 Most OO languages are class based.
 Classes serve two purposes: o They are convenient ways of describing a common set of objects. This saves a great deal of code that is NOT needed to create each individual object from scratch.

 o The consistency increases the amount of automatic error checking that can be done by the compiler.
Classes define interfaces, attributes, and methods.
Methods are pieces of code that implement operations/behaviors/…

 o Strive to have methods hidden (private) to avoid coupling problems with other classes.
Traditionally, UML private interfaces, attributes and methods routinely use ‘-’ to denote that they are private. Public interface, attributes and methods use ‘+‘. Protected interfaces are accessible only by subclasses or Friends ‘#’ octathorpe. Newer systems may include fancy icons, such as open and closed locks or keys, …
Instantiation is the process of creating an object from a class. o New instances have unique identity and their own set of attribute values o The creation process general involves initializing an objects attributes
2.1.5
High Cohesion
 See counterexample below
©2011 Mike Rowe
4:46 AM
Page 8 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design

Figure 1: http://www.eweek.com/slideshow_viewer/0,1205,l=&s=25060&a=176336&po=17,00.asp



Interfaces, public and private, tend to reduce coupling; and thus, increase maintainability, increase reliability, increase reuse, etc.
Classes and objects tend to model real-world domain object. o Domain based objects tend to be stable, are easily understood, and are consistent o with the users’ model of the world.
We strive for our system to match the users’ model of the world, so we can


Capture requirements more easily
Follow changes to requirements more easily (due to straighter mapping of
 software to users’ model).
Allows more natural user interaction with the system.
Some refer to the above objects as Domain objects. Differentiated from Solution (space)
objects which help support the solution, but are not directly mappable to the domain (for example linked lists).
Allows the derivation of a class from another.
 Subclasses or child or derived classes start out with all of the methods and attributes of the parent or super or base class.
©2011 Mike Rowe
4:46 AM
Page 9 04/15/2020

Notes: 003 Analysis and Design
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design





The subclass may override some of the inherited methods
The subclass may also add new methods and attributes. o Example: Military platform base class – robot, UAV, soldier, tank, airplane, etc. child classes.
Specialization – a subclass that inherits from a base class and has additional specification.
Elevator button is a kind of button, but not all buttons are elevator buttons. Elevator button is a specialized button.
Generalization – the opposite of specialization.
Inheritance increase reuse, and thus reduces the total volume of code needed – less to write, test, document, etc.
Polymorphism – “many forms”;
 A polymorphic function can take arguments of different types and yet perform a similar operation. A function may handle different classes or data types.
 This saves a great deal of coding and makes the code easier to follow as we can have one name for a general operation even though that operation operates on different data types.
Dynamic (Late) Binding – selection of which function to execute at run time v. compile time based on the type of the object(s) being used/operated on.
 Performance can suffer as processing time is needed to determine which method.
 In C++ we use virtual methods in conjunction with inheritance to make use of dynamic binding.
©2011 Mike Rowe
04/15/2020 4:46 AM
Page 10