Object Oriented Analysis and Design in Software Development

1
Object Oriented Analysis and Design in Software
Development

• State University of Campinas
• UNICAMP - Brazil

Ricardo Gudwin
2
Developing using UMLThe main Phases

• Requirements Specification
• Proposing a problem
• Analysis
• Investigation of the problem
• Design
• Logical Solution
• Construction
• Building code

3
Requirements Specification Phase

• State University of Campinas
• UNICAMP - Brazil

Ricardo Gudwin
4
Developing using UMLRequirements Specification

• Requirements - description of needs or desires
  for a product
• Primary goal - identify and document what is
  really needed in the system
• Challenge - define requirements unambiguously
• First Steps
• Understand and Characterize the Problem
• Propose how can a software system solve the
  problem
• Main Result - Requirements Specification Report

5
Requirements Specification Report

• Document with the following chapters
• Problem Comprehension - verbal description of the
  domain problem
• Software solution proposal - verbal description
  proposing how a software system can be envisioned
  to solve the problem
• assertion of goals
• Logistic Plan
• Working Teams - people involved in the project
• Affected Groups - groups affected by the current
  project
• Assumptions - things assumed to be true
• Risks - things which can lead to failure or delay
  - potential consequences of failure or delay
• Dependencies - other parties, systems and
  products that the project depends upon for
  completion

6
Requirements Specification Report

• List of System Functions
• what a system is supposed to do
• List of System Attributes
• what a system is supposed to be
• List of Use Cases
• Narrative of possible interactions between the
  users (including external users - other systems)
  and the system
• Use Case Diagrams
• UML diagram for capturing use cases
• Glossary of Terms
• List of main terms being used to describe system
  functions, attributes and use cases

7
Problem Comprehension

• Examples
• 1-) We want to build a new electronic product
  (e.g. a cellular phone), with a full set of
  features (e.g. fast dialing, mnemonic memory,
  emergency dialing, embedded pager, etc).
• 2-) We have a large set of data (customers,
  suppliers, products, parts, etc), and want to
  find a good way to organize, access and update
  all this information.
• 3-) We have a process that we want to model and
  analyze in order to make predictions of its
  behavior and test the impact of different
  decisions on the results we are going to obtain.
• 4-) We have a business, with all its logistics
  and methods, and want to improve its efficiency,
  reliability and cost-effectiveness.
• 5-) We want to produce some sort of goods in an
  efficient, reliable and automatic way, using
  automatic machines.

8
Software Solution Proposal

• Examples
• 1-) Use of microprocessors or micro-controllers
  within the product, with an embedded software to
  provide the desired features
• 2-) Use of a database system to manage the data.
• 3-) Development of a simulator to simulate the
  process and provide the statistics for decision
  analysis
• 4-) Use of productivity tools (e.g. office tools,
  e-mail, web-sites), and special purpose software
  applications in order to automate parts of the
  business process.
• 5-) Development of a control system software in
  order to control the machines involved in good
  productions.

9
List of System Functions

• Example Cellular Phone System Software

10
List of System Attributes

• Example Cellular Phone System Software

11
Use Case

• Use Case Dial Phone Number
• Actors User
• Purpose Describe the process of dialing a
  number
• Overview The User informs the device he wants
  to dial a phone number, enter a sequence of 1 to
  n digits, informs the system he ended entering
  the number and the system start dialing
• Type Primary and essential
• Cross Reference Functions F1.1 Attributes A1.3

12
Types of Use Cases

• Primary, Secondary and Optional
• Primary represent major common processes - e.g.
  Dial Phone Number
• Secondary represent minor or rare processes -
  e.g. Program Number in Memory
• Optional processes that may not be tackled -
  e.g. Get Program Version Number
• Essential versus Real
• Essential are expressed in an ideal form that
  remains relatively free of technology and
  implementation details
• Real concretely describes the process in terms
  of its real current design, committed to specific
  input and output technologies and so on (NOT USED
  IN REQUIREMENTS PHASE)

13
Use Case Diagram
User
Program Number in Memory
Delete Number in Memory
ltltextendsgtgt
ltltextendsgtgt
Search Memory
Dial Confidential Phone Number
Dial Number in Memory
Dial Phone Number
Check Password
ltltincludegtgt
Validate User
Voice Validation
14
Requirement Analysis Phase

• State University of Campinas
• UNICAMP - Brazil

Ricardo Gudwin
15
Developing using UMLAnalysis

• Requirement Analysis employing a deep
  investigation and enhancement of requirement
  specifications
• Objectives
• Complement description of essential Use Cases
• Identify concepts in order to create an initial
  Conceptual Model
• Detail processes, creating an initial Behavioral
  Model
• Main challenge maintain an abstract level of
  investigation, without entering within design
  questions
• Main result
• Requirement Analysis Report

16
Requirement Analysis Report

• Document with the following chapters
• Analysis Summary describing how the analysis
  steps were performed (sequence of activities),
  and the main artifacts to appear
• Initial Conceptual Model capture the main
  concepts used in specifications, and start
  defining the terminology used to describe the
  future system components
• Conceptual Class Diagram
• Initial Behavioral Model details the description
  of use cases given in specifications, preparing
  the room for design
• Sequence Diagrams
• Contracts

17
Building a Conceptual Model

• Conceptual Model
• illustrates meaningful concepts in a problem
  domain - the things we should be aware of
• it is the most important artifact to create
  during object-oriented analysis
• represents real-world things, NOT software
  components
• Contents
• Concepts
• Associations between concepts
• Attributes of concepts

18
Building a Conceptual Model

• Concept
• informally - an idea, thing or object
• formally - defined by its symbol, intension and
  extension
• symbol - words or images representing a concept
• intension - the definition of a concept
• extension - the set of examples to which the
  concept applies
• Structured Analysis x Object-Oriented Analysis
• Structured Analysis focus on processes or
  functions
• Object Oriented Analysis focus on concepts
• Strategy to Identify Concepts
• Searching the Use Cases description overview
• Speculating on additional related concepts

19
Building a Conceptual Model

• Concept Category List

• physical or tangible objects
• specifications, designs or descriptions of things
• places
• transactions
• transaction line items
• roles of people
• containers of other things
• things in a container
• other computer or system external to our system

• Abstract noun concepts
• organizations
• events
• processes (often not represented as a concept)
• rules and policies
• catalogs
• records or finance, work, contracts, legal
  matters
• financial instruments and services
• manual, books

20
Building a Conceptual Model

• Conceptual Modeling Guidelines
• List the candidate concepts using the noun phrase
  identification and the Concept Category List
• Draw them in a Conceptual Class Diagram
• Add the associations necessary to record
  relationships
• Add the attributes necessary to fulfill
  information requirements
• Avoiding Irrelevant features
• use names of things that do exist exclude
  irrelevant features do not add things that are
  not there
• Concepts or Attributes ?
• If we do not think of some concept X as a number
  or a text in the real world, X is probably a
  concept, not an attribute
• If in doubt, make it a separate concept

21
Building a Conceptual Model

• Specification or Description Concepts
• abstract concepts used to specificate or describe
  other concepts
• When are they needed ? Add a specification or
  description concept when
• deleting instances of things they describe (e.g.
  Item) results in a loss of information that needs
  to be maintained, due to the incorrect
  association of information with the deleted thing
• it reduces redundant or duplicated information
• Examples
• Product, ProductSpecification
• Item, ItemDescription

22
Starting the Conceptual Class Diagram
23
Conceptual ModelAdding Associations

• Association relationship between concepts that
  indicates some meaningful and interesting
  connection
• Criteria for useful Associations
• Associations for which knowledge of the
  relationship needs to be preserved for some
  duration (need-to-know associations)
• Associations derived from the Common Associations
  List

24
Conceptual ModelAdding Associations
25
Common Associations List

• A is a physical part of B
• A is a logical part of B
• A is physically contained in/on B
• A is logically contained in B
• A is a description for B
• A is a line item of a transaction or report B
• A is known/logged/recorded/ reported/captured in
  B
• A is a member of B

• A is an organizational sub-unit of B
• A uses or manages B
• A communicates with B
• A is related to a transaction B
• A is a transaction related to another transaction
  B
• A is next to B
• A is owned by B

26
Conceptual ModelAdding Associations

• How Detailed Should Associations Be ?
• Common pitfall spend too much time during
  investigation trying to discover associations
• Finding concepts is much more important than
  finding associations. Spend more time in finding
  concepts than finding associations
• Association Guidelines
• Too many associations tend to confuse a
  conceptual model rather than to illuminate it.
  Their discovery can be time-consuming with
  marginal benefit
• Avoid showing redundant or derivable associations
• Declare association names, roles and multiplicity
  only when necessary

27
Conceptual ModelAdding Attributes

• Attribute logical data value of an object
• It is necessary to identify those attributes of
  concepts that are needed to satisfy the
  information requirements of the current use cases
  under development
• Conceptual Model representation of real world
  things, not software components - attributes for
  read things.
• Attributes to include
• those for which the requirements suggest or imply
  a need to remember information
• Valid Attribute Types
• Boolean, Date, Number, String, Time, Color,
  Geometrics (Point, Rectangle, ), etc.

28
Conceptual ModelAdding Attributes

• Attributes generally are Pure Data Values
• those for which unique identity is not meaningful
• e.g. separate instances of the Number 5, of the
  String start,etc.
• Modeling Attribute Quantities and Units
• use a separate concept unit associated to given
  amounts
• Avoid Foreign Keys current values of attributes
  of associated concepts

29
Building a Behavioral ModelSystem Sequence
Diagrams

• System Behavior what a system does, NOT how it
  does it
• Behavioral Model
• System Sequence Diagrams for each Use Case in
  specifications, there should be ONE OR MORE
  sequence diagram. Multiple sequence diagrams are
  used to illustrate different courses of action on
  a same scenario.
• Contracts for each message appearing within an
  earlier sequence diagram, there should be a
  contract ruling it.
• Sequence of Actions
• Use Cases -gt Sequence Diagrams -gt Contracts

30
Example of a System Sequence Diagram

• Use Case DialPhoneNumber

System
User
1 ServiceRequest(DialingRequest)
2 enterItem(Digit)
Repeat until
complete
Phone Number
3 Dial()
31
Behavioral ModelContracts

• Contracts
• describe the effect of operations upon the
  system, in terms of what a systems state changes
  are when the operations are invoked.
• describes WHAT a system does, without explaining
  HOW it does it.
• For each operation appearing in a system sequence
  diagram, there should be a corresponding contract
• Contract Sessions
• The contract is divided into sections.
• Each section provides information about a
  specific part of the contract

32
Contracts

• Name
• name of operation, and parameters
• Responsibilities
• An informal description of the responsibilities
  this operation must fulfill
• Type
• Name of type (concept, software class, interface)
• Cross References
• System function reference numbers, use cases,
  etc.
• Notes
• Design notes, algorithms, and so on.

33
Contract

• Exceptions
• Exceptional cases
• Output
• Non-UI (User Interface) outputs, such as messages
  or records that are sent outside of the system
• Pre-Conditions
• Assumptions about the state of the system before
  execution of the operation
• Post-Conditions
• The state of the system after completion of the
  operation

34
Contracts

• How to Make a Contract
• Identify the system operations from the system
  sequence diagrams
• For each system operation, construct a contract
• Start by writing the Responsibilities section,
  informally describing the purpose of the
  operation
• Then complete the Post-conditions section,
  declaratively describing the state changes that
  occur to objects in the conceptual model
• To describe the post-conditions, use the
  following categories
• Instance creation and deletion
• Attribute modification
• Associations formed and broken

35
Contracts

• Notes
• The Post-Conditions are the most important part
  of a contract
• Do not confuse Outputs with Post-Conditions
• Post-conditions are not actions to be performed
  during the operation, but declarations about the
  system state after the operation is performed
• Post-conditions are related to the conceptual
  model
• what instances can be created ? Those from the
  conceptual model
• what associations can be formed ? Those in the
  conceptual model
• During the creation of contracts, it is normal to
  discover the need for new concepts, attributes or
  associations not within the conceptual model.
  These should be included into the conceptual
  model.

36
Contracts

• How Complete Should Post-conditions be ?
• Generating a complete and accurate set of
  post-conditions for a system operation is not
  likely - or even necessary - during the analysis
  phase
• Fine details will be discovered during the design
  phase.
• Pre-conditions
• define assumptions about the state of the system
  required before the operation is performed
• Examples
• Things that are important to test at some point
  of the operation
• Things that will not be tested, but upon which
  the success of the operation hinges - important
  because document them to future readers of the
  contract, highlighting their importance in future
  phases.

37
Contracts

• Advice on Writing Contracts
• After filling in the operation name, fill in the
  Responsibilities section first, Post-conditions
  section next, Pre-conditions last.
• If a developer finds no use in filling a
  particular section, its OK.
• Use the Notes section to discuss any design
  details, such as algorithms or the high-level
  sequential steps
• Use the Exceptions section to discuss the
  reaction to exceptional situations
• State the post-conditions in a declarative,
  passive tense form (was ) to emphasize the
  declaration of a state change rather than of an
  action.
• Dont forget to include the forming of
  associations when new instances are created

38
Example of Contract

• Name ServiceRequest(service)
• Responsibilities Send a service request to the
  system
• Type concept
• Cross References UC DialPhoneNumber, F1.1
• Notes (none)
• Exceptions Dialer not available
• Output
• Pre-ConditionsSystem is on-line, Dialer not busy
• Post-Conditions
• System is aware of the desired service
• The right server to provide the service is
  created
• The server is initialized to start the service

39
Design Phase

• State University of Campinas
• UNICAMP - Brazil

Ricardo Gudwin
40
Developing using UMLDesign

• Analysis Phase emphasizes an understanding of
  the requirements, concepts and operations related
  to a system - WHAT are the processes, concepts,
  etc.
• Design Phase starts the development of a logical
  solution based upon object-oriented paradigm -
  HOW are the processes, concepts, etc. implemented
• Basic Issues
• architectural design
• development of real use-cases
• creation of interaction diagrams
• assigning responsibilities
• design patterns

41
Developing using UMLDesign

• Software Systems
• Monolythic Applications
• Multi-Threaded Applications
• Client-Server Systems
• Component Based Systems

42
Developing using UMLDesign

• Three-Tier Architecture
• User Interface
• Application Logic
• Storage

Process Data
Collect Data
Generate Statistics
43
Developing using UMLArchitectural Design

• Multi-Tiered Object-Oriented Architectures
• includes the separation of responsibilities
• Decomposing the Application Logic Tier into finer
  layers
• Domain concepts
• Services
• A logical three-tier architecture may be
  physically deployed in various configurations.
• Example 1 (Fat Client)
• User Interface Application Logic -gt Client
  computer
• Storage -gt Server computer

44
Developing using UMLArchitectural Design

• Example 2 (Fat Server)
• User Interface -gt Client computer
• Application Logic Storage -gt Server computer
• Example 3 (Distributed system)
• User Interface -gt Client computer
• Application Logic -gt Distributed over multiple
  server computers
• Storage -gt Distributed over multiple server
  computers
• Logical solution Package diagrams
• Physical solution Deployment diagrams

45
Developing using UMLArchitectural Design

• Package Diagram
• packages can be hierarchically nested
• each package comprises a domain of functionally
  related classes and objects
• packages can be developed within a design cycle
  or re-utilized from existing components

46
Developing using UMLArchitectural Design

• Deployment Diagram
• At this point, the physical solution is
  envisioned, in order to evaluate how different
  parts of the system are going to be developed
• The configuration may change during design

47
Developing using UMLDesign Main Trail

• After the primary definition of an architecture
• Real Use Cases
• Design Class Diagram
• Interaction Diagram
• The above diagrams are designed interactively
• From essential use-cases derived in the Analysis
  phase, we develop now Real Use Cases, where
  aspects regarding User Interface and Storage are
  explicitly considered.
• As soon as we define each real use case, we use
  the information within it to feed the Design
  Class Diagrams.
• Design Class Diagrams are distributed within the
  packages showed at the Package Diagram

48
Developing using UMLDesign Main Trail

• Instances of objects from classes on the Design
  Class Diagrams have their interaction described
  through Interaction Diagrams
• Collaboration Diagrams (mainly)
• Sequence Diagrams (in some cases)
• The assignment of responsibilities in order to
  create the objects and classes implementing the
  real use cases, that are represented by
  interaction diagrams, may be due the use of GRASP
  Design Patterns (General Responsibility
  Assignment Software Patterns)
• The messages appearing in each interaction
  diagram are further regulated by means of
  software contracts.
• Detailed description of real use cases may
  require the use of State diagrams and/or Activity
  diagrams

49
Developing using UMLDesign Main Trail

• Notes
• Design Class Diagrams are not a simple evolution
  of Conceptual Class diagrams. There should be
  some resemblance between them, but Design Class
  Diagrams can be potentially different from
  Conceptual Class diagrams developed in analysis
  phase.
• Main differences will be due to the inclusion of
  objects for creating and managing the user
  interface and storage.
• The development of real use cases include the
  design of the windows comprising the user
  interface
• The conceptual object System appearing in
  System Sequence Diagrams will now be replaced by
  the creation of new objects that will interact
  with the user and with each other.

50
Developing using UMLCollaboration Diagrams

• Example of Collaboration Diagrams

51
Developing using UMLGrasp Patterns

• Assigning Responsibilities
• great variability in the potential quality of
  object interaction design and responsibility
  assignment
• poor choices lead to systems and components which
  are fragile and hard to maintain, understand,
  reuse or extend
• skillful implementation is founded on the
  cardinal principles of good object-oriented
  design
• the amount of time and effort spent on their
  generation,and the careful consideration of
  responsibility assignment should absorb a
  significant percentage of the design phase of a
  project
• codified patterns and principles can be applied
  to improve the quality of their design

52
Developing using UMLGrasp Patterns

• Responsibility
• contract or obligation of a type or class
• assigned to objects during object-oriented design
• Two basic types
• knowing
• knowing about private encapsulated data
• knowing about related objects
• knowing about things it can derive or calculate
• doing
• doing something itself
• initiating action in other objects
• controlling and coordinating activities in other
  objects

53
Developing using UMLGrasp Patterns

• Patterns
• experienced object-oriented developers build up a
  repertoire of both general principles and
  solutions that guide them in the creation of
  software
• named problem/solution pair that can be applied
  in new contexts, with advice on how to be applied
• codify existing knowledge and principles on how
  to solve problems that appear over and over
• patterns have suggestive names incorporate the
  pattern concept into our understanding and
  memory, and facilitates communication

54
Developing using UMLGrasp Patterns

• GRASP - Patterns of General Principles in
  Assigning Responsibilities
• the skillful assignment of responsibilities is
  extremely important in object-oriented design
• determining the assignment of responsibilities
  often occurs during the creation of interaction
  diagrams
• GRASP patterns describe fundamental principles of
  assigning responsibilities to objects, expressed
  as patterns
• understanding and being able to apply these
  principles during the creation of interaction
  diagrams is important because a software
  developer new to object technology needs to
  master these basic principles as quickly as
  possible
• Main Grasp Patterns Expert, Creator, High
  Cohesion, Low Coupling, Controller

55
Developing using UMLGrasp Patterns

• Expert
• Problem Who should be responsible for providing
  some sort of information ?
• Solution Assign the responsibility to the
  information expert - the class that has the
  information necessary to fulfill the
  responsibility, either by knowing it or by
  knowing how to calculate it.
• Benefits
• encapsulation is maintained, since objects use
  their own information to fulfill tasks. This
  supports low coupling, which leads to more robust
  and maintainable systems
• behavior is distributed across the classes that
  have the required information, thus encouraging
  more cohesive lightweight class definitions
  that are easier to understand and maintain. High
  cohesion is supported

56
Developing using UMLGrasp Patterns

• Creator
• Problem Who should be responsible for creating a
  new instance of some class ?
• Solution Assign class B the responsibility to
  create an instance of class A if one of the
  following is true
• B aggregates A objects
• B contains A objects
• B records instances of A objects
• B closely uses A objects
• B has the initializing data that will be passed
  to A when it is created.
• Benefits
• Low coupling is supported, which implies lower
  maintenance dependencies and higher opportunities
  for reuse

57
Developing using UMLGrasp Patterns

• Low Coupling
• Problem How to support low dependency and
  increased reuse?
• Solution Assign a responsibility so that
  coupling remains low.
• Coupling
• is a measure of how strongly one class is
  connected to, has knowledge of, or relies upon
  other classes. A class with low coupling is not
  dependent on too many other classes. A class with
  high coupling relies upon many other classes.
  Such classes are undesirable because
• changes in related classes force local changes
• harder to understand in isolation
• harder to reuse because its use requires the
  additional presence of the classes it is
  dependent upon

58
Developing using UMLGrasp Patterns

• Observations
• Low coupling is a principle to keep in mind
  during all design decisions. It is an underlying
  goal to continually consider.
• It is an evaluative pattern which a designer
  applies while evaluating all design decisions
• LC supports the design of classes that are more
  independent, and more reusable. It can not be
  considered, though, in isolation from other
  patters, but should be included as one of several
  design principles.
• Benefits
• not affected by changes in other components
• simple to understand in isolation
• convenient to reuse

59
Developing using UMLGrasp Patterns

• High Cohesion
• Problem How to keep complexity manageable ?
• Solution Assign a responsibility so that
  cohesion remains high.
• Cohesion
• is a measure of how strongly related and focused
  the responsibilities of a class are.
• A class with highly related responsibilities and
  which does not do a tremendous amount of work,
  has high cohesion
• A class with low cohesion does many unrelated
  things or does too much work. Such classes are
  undesirable because
• hard to comprehend
• hard to reuse
• hard to maintain
• delicate constantly affected by change

60
Developing using UMLGrasp Patterns

• Observations
• like Low Coupling, High cohesion is a principle
  to keep in mind during all design decisions
• The delegation of responsibilities to created
  classes helps increasing the cohesion, at the
  same time as making the coupling lower
• Benefits
• clarity and ease of comprehension of the design
  is increased
• maintenance an enhancements are simplified
• Low coupling is often supported
• The fine grain of highly related functionality
  supports increased reuse potential because a
  highly cohesive class can be used for a very
  specific purpose

61
Developing using UMLGrasp Patterns

• Controller
• Problem Who should be responsible for handling a
  system event ?
• Solution Assign the responsibility to a class
  representing one of the following choices
• represents the overall system (facade controller)
• represents the overall business or organization
  (facade controller)
• represents something in the real world that is
  active (for example, the role of a person) that
  might be involved in the task (role controller)
• represents an artificial handler of all system
  events of a use case, usually named
  ltUseCaseNamegtHandler (use case controller)
• Use the same controller class for all the system
  events in the same use case

62
Developing using UMLGrasp Patterns

• System Events
• external input events generated by an external
  actor
• associated with system operations
• During Analysis
• system operations are assigned to the type System
• At design these operations should be assigned to
  controllers.
• Benefits
• increased potential for reusable components
• ability to manage the state of the use case

63
Developing using UMLGrasp Patterns

• Bloated Controllers
• poorly designed, a controller class will have low
  cohesion - unfocused and handling too may areas
  of responsibility
• e.g. there is only a single controller class
  receiving all system events in the system, and
  there are many of them (happens sometimes if
  facade or role controller are chosen)
• e.g. the controller itself performs many of the
  tasks necessary to fulfill the system event,
  without delegating the work
• e.g. a controller has many attributes and
  maintains significant information about the
  system or domain, which should have been
  distributed to other objects
• Solutions
• add more controllers
• delegate operations to other objects

64
Developing using UMLGrasp Patterns

• Other patterns
• Command - in a message-handling system, each
  message may be represented and handled by a
  separate command object
• Facade - choosing an object representing the
  entire system or organization to be a controller
• Forward-Recover - Siemens pattern useful for
  message-handling systems
• Layers - Siemens pattern. Placing domain logic in
  the domain layer rather than the presentation
  layer is part of the Layer pattern
• Pure Fabrication - is an artificial class, not a
  domain concept. A use-case controller is a kind
  of a Pure Fabrication