Object Oriented Analysis and Design using UML

by Sandeep Desai (http://www.thedesai.net/)

Book reference:

UML Distilled 3rd Edition by Martin Folwer

Applying UML and Patterns by Craig Larman

The process of software development primarily involves requirement gathering, designing and developing.

The two models of software development are

· Waterfall Development, where each phase is completed before the next phase is begun. This approach has led to a lot of project failures due to the rigidness of the process.

· Iterative Development, where design and development is started before all the requirements are gathered. This approach handles changes in requirements better and provides quicker feedback from customers

One suggested approach for doing Iterative Analysis and Design is to have multi step process as described below

• Capture 20% requirements and do 2% of software development
• Capture 30% requirements and do 5% of software development
• Capture 50% requirements and do 8% of software development
• Capture 90% requirements and do 10% of software development
• Capture 90% requirements and do 20% of software development

The goal at the end of this process to have understood and implemented the risky party of the project. In UP (Rational Unified Process) terms it is called the elaboration phase

The Agile Development Manifesto recommends an iterative development approach where changes to the projects are accepted late. It emphasizes simplicity, lightness, communication and self-organizing teams.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

SCRUM is another agile methodology that recommends daily meetings, self-organizing teams.

Extreme Programming method includes programming in pairs and test driven development

The goal of Agile modeling is to understand not to document. It does not imply that modeling should be avoided. It recommends white board sketching over modeling using a UML tool. Don’t model alone, model in pairs. Use good-enough UML notation. Know that all models maybe inaccurate. Developers should do the OO design

RUP (Rational Unified Process) phases, they do not imply waterfall development. Everything is optional in UP

• Inception - defining project, setting project scope (not detailed level requirements)
• Elaboration - requirements, iterative development, core architecture, resolution of high risks
• Construction - iterative implementation of lower risk and easier elements
• Transition - beta tests, deployment

UP Disciplines

• Business modeling – The Domain model artifact, to visualize noteworthy concepts in the application domain

• Requirements – Use Case Model and Supplementary Specification artifacts
• Design - Design Model artifact, to design the software
• Implementation
• Test
• Deployment
• Configuration and Change Management
• Project Management
• Environment

UP Inception phase

• Artifacts that maybe partially completed are
• Vision and Business Case
• Use-Case Model (use cases listed and 10% analyzed in detail)
• Supplementary Specification
• Glossary, domain terminology and data dictionary
• Risk List & Risk Management Plan
• Prototypes and proof of concepts using the 10% of use cases
• Iteration Plan, Describe what to do in the first iteration phase
• Phase Plan and Software Development Plan
• Development Case

Gathering Requirements

FURPS model

• Functional – features, security
• Usability – UI, help documentation
• Reliability- uptime requirements
• Performance - response time, resource usage
• Supportability – maintainability, internationalization, configurability

Other FURPS+

• Implementation – resource limitation languages and tools, hardware
• Interface – constraints imposed by external systems
• Operations – system management
• Packaging – physical packaging
• Legal - licensing

Relationship between disciplines and phases

In each iteration, phase the relative effort for each discipline varies. Initial phases focus more on requirements and the later more on design

Requirements Organization in UP artifacts

They are information text only and can be stored as Web pages or Wiki

• Use-Case Model -
• Supplementary specification -
• Glossary – Defines noteworthy terms, (Data Dictionary)
• Vision – High level requirements, Short executive overview
• Business Rules (Domain Rules) – rules that transcend one software project e.g. tax laws

Use Cases

They are text stories. It is a contract of how system will behave.

Focus on use cases that are Elementary Business Process (EBP) i.e. a task performed by one person in one place at one time in response to a business event, which adds measurable business value and leaves the data in a consistent state

Actor: Something with behavior such as person, computer system or organization (e.g. cashier)

Scenario is a specific sequence of actions and interactions between actors and the system; it is also called as a use case instance

Kinds of Actor: Primary, Supporting (external) e.g. authorization, Offstage e.g. external audit

Use Case formats:

• Brief – terse one paragraph summary
• Casual – Information paragraph format
• Fully dressed – All steps and variations written in detail

Use case template from alistair.cockburn.us

Use Case Selection	Comment
Use Case Name	Start with verb
Scope	The system under design
Level	User-goal or subfunction
Primary Actor	Calls on system to deliver services
Stakeholder and Interests	Who cars about this use case and why
Preconditions
Success guarantee	Post-condition
Main Success Scenario	A typical, unconditional happy path scenario of success
Extensions	Alternate scenarios of success or failure
Special Requirements	Related non-functional requirements
Technology and Data Variations list	I/O methods, data formats
Frequency of Occurrence	Influences investigation, testing and timing of implementation
Miscellaneous	Open issues etc

UML Use Case Diagram Example

Elaboration UP phase

Artifacts that may be started in Elaboration Phase

Domain Model

Design Model – describes logical design, software class diagrams, object interaction diagrams and package diagrams

Software Architecture Document – key architecture issues, summary of outstanding design issues

Data Model – database schema and object relation mapping (ORM) strategy

Use-Case Storyboards, UI prototypes

Domain Model

Domain represents real world not software. Use UML Class diagram for domain model, do not show software objects or classes or data model

Domain Model diagram dos and don’t

• domain objects or conceptual classes
• associations between conceptual classes
• attributes of conceptual classes
• do not show operations (methods)
• avoid too many associations (relationshships)
• do not show data flow

Domain Model diagram Example

How to find conceptual classes

• Reuse or modify existing models See book Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay, Data Model Resource Book by Len Silverston Vol 1 & 2
• Use a category list
• Identify noun phrases

Category list for conceptual classes

• Business transactions e.g. sale payment, reservation
• Transaction line items e.g. Sales line item
• Product or service related to transaction e.g. Item
• Where is the transaction recorded
• Roles of people or organizations
• Place of transaction; place of service
• Noteworthy events
• Physical objects e.g. Airplane
• Description of things e.g. FlightDescription
• Catalogs e.g. ProductCatalog
• Container of things (physical or information) e.g. Airplane
• Things in a container e.g. Passenger
• Other collaborating systems e.g. CreditAuthorizingSystem
• Records of finance, work, contracts, legal matters
• Financial instruments
• Schedules, manuals

Common Association List

• A is a transaction related to another transaction e.g. Cancellation-Reservation
• A is a line item of a transaction B
• A is product or service for a transaction (or line item) B e.g. Flight – Reservation
• A is a role related to a transaction B e.g. Passenger – Ticket
• A is a physical or logical part of B e.g. Seat – Airplane
• A is physically or logically contained in/on B e.g. Passenger – Airplane
• A is a descriptor for B e.g. FlightDescription – Flight
• A is known/logged/recorded/reported/captured in B e.g. Reservation – FlightManifest
• A is a member of B e.g. Pilot – Airline
• A is an organizational subunit of B (Maintenance – Airline)
• A user or manages or owns B (Pilot – Airplane)
• A is next to B (City-City)

System Sequence diagram

Use UML Sequence diagram

SSD shows events for one scenario of use case
Captures system events

Create SSD for main success story.

Abstract instead of physical

UML

The Unified Modeling language (UML) is a family of graphical notations, backed by a single meta-model, that help in describing and designing software systems.

• UML Use Case Diagram Example
• UML Class Diagram Example
• UML Activity Diagram Example

Books

Agile Modeling by Scott Ambler

Agile Software Development with SCRUM

Extreme Programming Explained by Kent Beck

UML Modeling Software

Free

• Argo UML
• Eclipse UML
• Oracle Jdeveloper create class, activity and use case diagrams and sequence diagram. Free download and use

Commercial

• IBM Rational
• MagicDraw UML can download free community edition for creating class diagrams
• Poseidon by Gentleware Free Community edition allows you to create Class, Use Case, Deployment Diagram

UML Resources

OMG UML

Martin Fowler

Craig Larman

Agile Modeling by Scott Ambler

UML Diagrams by Scott Ambler

Rational Unified Process Wiki

Brad App

Agile Alliance