1 of 141

Two days workshop on�“Design thinking -OOMD Star-UML “

10.00 am to 05.00 pm daily

Organized by

IIC-IQAC & AI&DS Department

06^th & 7^th Jan 2026

IIC Id- IC202218599

2 of 141

Workshop Overview

Two-day hands-on workshop
Focus on problem-solving and software design
Integration of Design Thinking with OOMD
Practical modeling using StarUML

3 of 141

Workshop Objectives

• Understand Design Thinking methodology

• Apply Object-Oriented Modeling & Design concepts

• Develop UML diagrams using StarUML

• Enhance industry-ready design skills

4 of 141

Contents -

Revise Design thinking & SDLC
Formulate a realistic problem statement using SDLC.
Models

Use-case model
Design model (Class diagram)

Diagrams

Use-case diagram and activity diagram
Sequence diagram and Collaboration diagram
Class diagram
Component & Deployment Diagram

How many diagrams need to be created?

5 of 141

Design Thinking

• Human-centered problem-solving approach
• Focuses on innovation and creativity
• Used in product design and software engineering

6 of 141

Stages of Design Thinking

• Empathize
• Define
• Ideate
• Prototype
• Test

7 of 141

What Is a Model?

A model is “a complete description of a system from a particular perspective.” A model is a simplification of reality.

8 of 141

Why Model?

Modeling achieves four aims:

Helps you to visualize a system as you want it to be.
Permits you to specify the structure or behavior of a system.
Gives you a template that guides you in constructing a system.
Documents the decisions you have made.

You build models of complex systems because you cannot comprehend such a system in its entirety.
You build models to better understand the system you are developing.

According to Booch in The Unified Modeling Language User Guide, modeling achieves four aims:

1. Models help you to visualize a system, as you want it to be. A model helps the software team communicate the vision for the system being developed. It is difficult for a software team to have a unified vision of a system that is described only in specification and requirement documents. Models bring about understanding of the system.

2. Models permit you to specify the structure of behavior of a system. A model allows how to document system behavior and structure before coding the system.

3. Models give a template that guide you in constructing a system. A model is an invaluable tool during construction. It serves as a road map for a developer. Have you experienced a situation where a developer coded incorrect behavior because he or she was confused over the wording in a requirements document? Modeling helps alleviate that situation.

4. Models document the decisions you’ve made. Models are valuable tools in the long term because they give “hard” information on design decisions. You don’t need to rely on someone’s memory.

9 of 141

10 of 141

11 of 141

What Is the UML?

The UML is a language for

Visualizing
Specifying
Constructing
Documenting

the artifacts of a software-intensive system.

The Unified Modelling Language (UML) is an industry standard for object oriented design notation, supported by the Object Management Group (OMG).

12 of 141

The UML Is a Language for Visualizing

Communicating conceptual models to others is prone to error unless everyone involved speaks the same language.
There are things about a software system you can’t understand unless you build models.
An explicit model facilitates communication.

Typically, projects and organizations develop their own language for modeling systems, making it difficult for outsiders and new team members to understand what is going on.

Communicating these conceptual models to others is prone to error unless everyone involved speaks the same language. The UML offers a set of symbols that represents well-defined semantics. One developer can write a model in the UML, and another developer can interpret that model unambiguously.

There are things about a software system you can’t understand unless you build models that transcend the textual programming language. For example, the meaning of a class hierarchy can be inferred, but not directly grasped, by staring at the code for all the classes in the hierarchy. The UML is a graphical language that addresses this problem.

If the developer who cut the code never wrote down the models, the information would be lost forever. At best, the information would only be partially recoverable from the implementation after the developer has moved on. Writing models in the UML addresses this issue. An explicit model facilitates communication. (The Unified Modeling Language User Guide, Booch, 1999.)

13 of 141

The UML Is a Language for Specifying

The UML builds models that are precise, unambiguous, and complete.

14 of 141

The UML Is a Language for Constructing

UML models can be directly connected to a variety of programming languages.

Maps to Java, C++, Visual Basic, and so on
Tables in a RDBMS or persistent store in an OODBMS
Permits forward engineering
Permits reverse engineering

15 of 141

The UML Is a Language for Documenting

The UML addresses documentation of system architecture, requirements, tests, project planning, and release management.

Use Case Diagram

Actor A

Use Case 1

Use Case 2

Use Case 3

Actor B

Class Diagram

GrpFile

read( )

open( )

create( )

fillFile( )

rep

Repository

name : char * = 0

readDoc( )

readFile( )

(from Persistence)

FileMgr

fetchDoc( )

sortByName( )

DocumentList

add( )

delete( )

Document

name : int

docid : int

numField : int

get( )

open( )

close( )

read( )

sortFileList( )

create( )

fillDocument( )

fList

1

FileList

add( )

delete( )

1

File

read( )

read() fill the

code..

Sequence Diagram

user

mainWnd

fileMgr :

FileMgr

repository

document :

Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦

»ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

ÈÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â

¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼

°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È¸é °´Ã¼´Â ÀÐ¾îµéÀÎ

°´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î

Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡

º¸¿©ÁØ´Ù.

Deployment Diagram

Window95

¹®¼°ü¸®

Å¬¶óÀÌ¾ðÆ®.EXE

Windows

NT

¹®¼°ü¸® ¿£Áø.EXE

Windows

NT

Windows95

Solaris

ÀÀ¿ë¼¹ö.EXE

Alpha

UNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼¹ö

Windows95

¹®¼°ü¸® ¾ÖÇÃ¸´

ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ®

- À©µµ¿ì NT: ÀÀ¿ë¼¹ö

- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö

- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö

Project artifacts are critical in controlling, measuring, and communicating about a system during its development and after its deployment.

The UML addresses the documentation of a system’s architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management. (The Unified Modeling Language User Guide, Booch, 1999.)

This slide does not represent all the diagrams defined in the UML specification. For example, there is no graphic presented here for a composite structure diagram or a timing diagram. Composite structure is a more advanced modeling concept that is not covered in this course. The timing diagram is new to UML2 and will be introduced in a later module.

16 of 141

History of the UML

UML 1.0

(Jan. ‘97)

UML 1.1

(Sept. ‘97)

UML 1.5

(March, ‘03)

UML 2.0

(2004)

Other

Methods

Booch ‘91

OMT - 1

OOSE

Booch ’93

OMT - 2

Public

Feedback

Unified Method 0.8

(OOPSLA ’95)

UML 0.9

(June ‘96)

UML 0.91

(Oct. ‘96)

and

The UML 2.0 is defined by two complementary specifications, the Infrastructure and the Superstructure. The UML infrastructure defines foundational concepts that can be used in part or entirely by other specifications. The UML superstructure defines the complete UML. The superstructure specification is self contained and you won’t have to read the infrastructure specification unless you are concerned about configuring other specifications in parallel to UML.

The UML metamodel (a description of a model) is divided into two main packages, structure and behavior with two supporting packages, auxiliary elements and profiles.

• The structure package defines the static structure of the UML.

The behavior package defines the dynamic structure of the UML.

Each package is described by a chapter in the superstructure specification document.

17 of 141

Diagrams

Diagrams graphically depict a view of a part of your model.
Different diagrams represent different views of the system that you are developing.
A model element will appear on one or more diagrams.

18 of 141

19 of 141

UML Diagrams in Software Architecture

Behavioral Diagrams

Structural Diagrams

Activity

Diagrams

Sequence

Diagrams

Communication

Diagrams

State Machine

Diagrams

Deployment

Diagrams

Component

Diagrams

Composite

Structure

Diagrams

Class

Diagrams

Use-Case

Diagrams

Model

Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models, including the following key diagrams:

Use-Case diagrams to illustrate user interactions with the system
Class diagrams to illustrate logical structure
Composite Structure diagrams to show the internal structure of a class or component at runtime
Component diagrams to illustrate the organization and dependencies among modular parts of the system
Deployment diagrams to show the mapping of software to hardware configurations
Activity diagrams to illustrate flows of events
State Machine diagrams to illustrate the series of states an object can have
Communication diagrams to illustrate behavior in terms of how objects interact
Sequence diagrams to illustrate behavior in terms of the sequence of interactions between objects

20 of 141

Software Architecture: The “4+1 View” Model

Process View

Deployment View

Logical View

Use-Case View

Implementation View

End-user

Functionality

Programmers

Software management

Performance

Scalability

Throughput

System integrators

System topology

Delivery, installation

communication

System engineering

Analysts/Designers

Structure

The above diagram shows the model Rational uses to describe the software architecture.

Architecture is many things to many different interested parties. On a particular project, there are usually multiple stakeholders, each with their own concerns and view of the system to be developed. The goal is to provide each of these stakeholders with a view of the system that addresses their concerns, and suppresses the other details.

To address these different needs, Rational has defined the “4+1 view” architecture model. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. Views are “slices” of models.

Not all systems require all views (e.g., single processor: drop deployment view; single process: drop process view; small program: drop implementation view, etc.). A project may document all of these views or additional views. The number of views is dependent on the system you’re building.

Each of these views, and the UML notation used to represent them, will be discussed in subsequent modules.

21 of 141

Visual Modeling Using UML Diagrams

Actor A

Use Case 1

Use Case 2

Actor B

user : Clerk

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repository

document : Document

gFile : GrpFile

9: sortByName ( )

L

1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼°ü¸®

Å¬¶óÀÌ¾ðÆ®.EXE

Windows

NT

¹®¼°ü¸® ¿£Áø.EXE

Windows

NT

Windows95

Solaris

ÀÀ¿ë¼¹ö.EXE

Alpha

UNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼¹ö

Windows95

¹®¼°ü¸® ¾ÖÇÃ¸´

Document

FileManager

GraphicFile

File

Repository

DocumentList

FileList

user

mainWnd

fileMgr :

FileMgr

repository

document :

Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦

»ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

ÈÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â

¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼

°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È¸é °´Ã¼´Â ÀÐ¾îµéÀÎ

°´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î

Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡

º¸¿©ÁØ´Ù.

Forward and Reverse Engineering

Target

System

Use Case 3

Use-case�diagram

Class diagram

Collaboration diagram

Sequence �diagram

Component �diagram

Statechart�diagram

GrpFile

read( )

open( )

create( )

fillFile( )

rep

Repository

name : char * = 0

readDoc( )

readFile( )

(from Persistence)

FileMgr

fetchDoc( )

sortByName( )

DocumentList

add( )

delete( )

Document

name : int

docid : int

numField : int

get( )

open( )

close( )

read( )

sortFileList( )

create( )

fillDocument( )

fList

1

FileList

add( )

delete( )

1

File

read( )

read() fill the

code..

Deployment �diagram

Visual modeling with the UML makes an application’s architecture tangible, permitting us to assess it in multiple dimensions. How portable is it? Can it exploit expected advances in parallel processing? How might we modify it to support a family of applications? We’ve discussed the importance of architectural resilience and quality. The UML enables us to evaluate these key characteristics during early iterations -- at a point when design defects can be corrected before threatening project success.

Advances in forward and reverse engineering techniques permit changes to an application’s model to be automatically reflected in its source code, and changes to its source code to be automatically reflected in its model. This is critical when using an iterative process, where we expect such changes with each iteration.

22 of 141

23 of 141

UML v 2 Diagrams :

Behavior Diagrams

1.Use Case Diagram 2.Activity Diagram

3.State Machine Diagram.

Interaction Diagrams,

4. Sequence D 6. Interaction Overview D

5. Communication D 7.Timing Diagram

Structure Diagrams

8.Class Diagram 11. Object Diagram

9. Component D 12.Composite Structure

10. Package D 13.Deployment D

24 of 141

Key Diagrams in UML

Requirements

System Structure

System Behaviour

Use Case Diagrams

Interaction Diagrams

Activity Diagrams

State Charts

Class Diagrams

Collaboration Diagrams

This part of the course will give you an introduction to key elements of the UMLnotation - it is not a blow by blow account of all the standard notation - the latter would be neither particularly helpful nor interesting! Like many standards there is much more in it than you will ever really want to know - but it is important to know that it exists.

The lectures we will cover do not tell you all there is to know about UML - all we are trying to do here is give you a way into the notation and gain some insight in what it has to offer.

The above slide summarises the parts of the UML that we will explore through the two sessions. There is also something called CRC cards that we will mention. The CRC cards are *not* part of the UML - but they are a useful technique to know about for reasons that we will discuss later. As a post-sessions exercise, if you search for CRC cards on the Internet you will see that they are a fairly common topic when developing and testing OO designs using the UML.

25 of 141

Different diagrams of system for different people

Process View

Deployment View

Logical View

Use-Case View

Implementation View

End-user

Functionality

Programmers

Software management

Performance, scalability, throughput

System integrators

System topology, delivery,

installation, communication

System engineering

Analysts/Designers

Structure

26 of 141

What is a Use-Case Model?

A use-case model:

Is a model of a system’s intended functions and its environment
Serves as a contract between the customer and the developers
Contains the following diagrams:

Use case: Shows a set of use cases and actors and their relationships
Activity: Shows the flow of events within a use case
Sequence: Shows how a use case will be implemented in terms of collaborating objects

27 of 141

Use-Case Diagram (Example)

View Report Card

Student

Register for Courses

Login

Select Courses to

Teach

Submit Grades

Professor

Registrar

Billing System

Maintain Professor

Information

Maintain Student

Information

Close Registration

Course Catalog

28 of 141

Activity Diagram

Action

A step in the flow of events

Decision

Flows split based on a guard

condition

Flow

Show the sequence of

activities

Fork

Beginning of concurrent flows

Join

End of concurrent flow

29 of 141

Activity Diagram (Example)

Synchronization

Bar (Fork)

Guard

Condition

Synchronization

Bar (Join)

Decision

Concurrent Threads

Transition

Select Course

[ add course ]

Check

Schedule

Check

Pre-requisites

Assign to

Course

Resolve

Conflicts

Update

Schedule

Delete Course

[ checks completed ]

[ checks failed ]

[ delete course ]

Activity/Action

30 of 141

What is a Design Model?

A design model:

Describes the realization of use cases in terms of design elements
Describes the design of the application
Contains the following diagrams:

Class: Shows UML classes and relationships
Component: Shows the structure of elements in the implementation model
Communication and Sequence: Show how objects and classes interact
State Machine: Shows event-driven behavior

The design model may include the following diagrams:

Class diagrams: Show the classes, their internal structure, and their relationships to other classes. May also show the package structure of the design model (package diagram).
Composite Structure diagrams: Show the runtime decomposition of a class.
Component diagrams: Used, in the design model, to show the high-level structure of the implementation model.
State Machine diagrams: Used to model the event-driven aspects of an object’s behavior.
Interaction diagrams: Used, in the design model, in use-case realizations to show how behavior is assigned to classes in the design model. The two interaction diagrams are semantically equivalent, so in Software Architect you can generate a sequence diagram under an interaction automatically from the interaction’s Collaboration diagrams or vice versa.

31 of 141

Class Diagram (Design Model)��Class diagrams show the static structure of the model, in particular, its classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information.

Class

A description of a set �of objects

Attribute�Named property of �a class

Aggregation�Represents a part-whole �relationship

Operation

Class behavior

Generalization�Shows an inheritance �relationship

32 of 141

Sequence Diagram �used to show how objects interact to perform the behavior of all or part of a use case as part of a use-case realization.

Lifeline

Shows the life of the object

Object/Class

Shows the object/class involved in the interaction

Messages

Show data exchanged�between objects

Execution Occurrence

Shows object executing

33 of 141

Sequence Diagram (Example)

Activity/Action

1: create schedule( )

2: get course offerings( )

3: get course offerings(for Semester)

4: get course offerings( )

6: display blank schedule( )

:RegisterForCoursesForm

:RegistrationController

SWTSU Catalog :

CourseCatalogSystem

: Student

: Course Catalog

5: display course offerings( )

Select Offerings

ref

34 of 141

Sequence Diagram: Combined Fragments

Interaction Use (ref)

References another interaction

Optional Fragment (opt)

Executed if guard condition evaluates to true

Loop (loop)

Executed as long as the first guard condition�evaluates to true

To help with the modeling of, for example, multiple flows of events, which in the past always meant creating many interaction diagrams with only slight differences among them, you can use combined fragment notation—new with UML 2.0 and supported in Software Architect—which allows you to embed multiple paths through an interaction inside the same interaction diagram.

A combined fragment in a sequence diagram has an operator and one or more subinteractions in a nested region of the diagram. Gates may be defined on the combined fragment so that messages can be sent from the combined fragment to other parts of the main interaction.

Combined fragments have a keyword associated with them, shown on the frame surrounding the combined fragment. The more common combined fragment types include:

loop: The loop fragment contains one subfragment that executes as long as a Boolean guard condition evaluates to true.
ref: The combined fragment references another sequence diagram. In Software Architect, adding the ref operator from the toolbox automatically generates a new interaction instance in the model.
opt: The opt fragment type contains one subfragment that executes only when the guard condition evaluates to true.

See Software Architect Help for discussion of other keywords.

35 of 141

Communication (Collaboration) Diagram ��provide another way to show how objects interact to perform the behavior of a particular use case or a part of a use case. Where sequence diagrams emphasize the interactions of objects over time, communication diagrams are designed to emphasize the relationships between objects.

Object/Class

Shows the object/class involved in the interaction

Message

Shows data �exchanged�between objects

Communication diagrams provide another way to show how objects interact to perform the behavior of a particular use case or a part of a use case. Where sequence diagrams emphasize the interactions of objects over time, communication diagrams are designed to emphasize the relationships between objects.

Objects: Objects show the name of the object and its class, separated by a colon:

objectname : classname

Links: Links are relationships among objects across which messages can be sent, shown as a solid line between two objects. A link can be an instance of an association, or it can be anonymous, meaning that its association is unspecified. Message flows are attached to links.

The diagram shown in the slide is based on the example sequence diagram from the previous slide. Two other elements that may appear in a Collaboration diagrams but do not appear in the example are:

Actors: Actor instances show the invoker of the interaction.
Messages: A message is a communication between objects that conveys information with the expectation that activity will ensue.

36 of 141

Communication Diagram (Example)

: Student

: RegisterForCoursesForm

: RegistrationController

: CourseCatalogSystem

5: display course offerings( )

6: display blank schedule( )

: Course Catalog

1: create schedule( )

2: get course offerings( )

3: get course offerings(forSemester)

4: get course offerings( )

Links

Messages

37 of 141

Component Diagram

Component

Modular parts of the system

Class

Included to show implementation�relationships.

It shows the runtime structure of the system at the level of software components. Components are the modular parts of the system and are made up of groups of related objects that are hidden behind an external interface.

38 of 141

Deployment Diagram

Artifact

Represents a physical file

Node

Represents a �physical machine

Owned Element �Relationship

Shows another way of �showing nested elements

Deployment diagrams show the deployment architecture of the system, that is, which of the system’s software artifacts reside on which pieces of hardware.

39 of 141

How Many Diagrams Need to be Created?

Depends:

You use diagrams to visualize the system from different perspectives.
No complex system can be understood in its entirety from one perspective.
Diagrams are used for communication

Model elements will appear on one or more diagrams.

For example, a class may appear on one or more class diagrams, be represented in a state machine diagram, and have instances appear on a sequence diagram.
Each diagram will provide a different perspective.

40 of 141

References

Rational Unified Process® course
Essentials of Rational Unified Process®

Essentials of Rational® RequisitePro®

Web-based or Instructor-led training

Mastering Business Modeling with the UML

Web sites

Rational’s corporate site: www.rational.com
Rational Developer Network^SM: www.rational.net

Books and articles about requirements management

There are many other sources of information about requirements management, including the sources listed here. Students who want more information about related topics should consider attending courses about the Rational Unified Process, Business Modeling, or RequisitePro.

Students who want to learn more about how to realize a use-case model and requirements in an object-oriented design should consider taking the Essentials of Visual Modeling with the UML or the Mastering Object-Oriented Analysis and Design courses.

Students who want to learn more about making reports that draw from the RequisitePro and Rational Rose repositories should consider taking a course in Rational SoDA® (Software Documentation Automation).

Students who want to learn more about quality testing from the beginning should consider taking Principles of Software Testing for Testers. Rational also offers courses on our automated testing tools that cover functional, performance, and embedded software testing.

Kurt Bittner and Ian Spence have written an excellent book that truly captures the essence of developing use cases. This book is a “must have” for anyone developing use cases. The book details are: Use Case Modeling, Kurt Bittner and Ian Spence, Addison Wesley, 2002, ISBN: 0-201-70913-9.

Dean Leffingwell and Don Widrig have written an excellent book on requirements management. The book details are: Managing Software Requirements a Unified Approach, D. Leffingwell and D. Widrig, Addison Wesley, 1999, ISBN: 0-201-61593-2.

Visit www.omg.org to learn more information about the UML.

41 of 141

Objectives:

Understand the basic Requirements concepts and how they affect Analysis and Design
Understand how to read and interpret the artifacts of Requirements that are used as a starting point for Analysis and Design

42 of 141

Requirements in Context

Management

Environment

Test

Analysis & Design

Preliminary �Iteration(s)

Iter.�#1

Iter.�#2

Iter.�#n

Iter.�#n+1

Iter.�#n+2

Iter.�#m

Iter.�#m+1

Configuration & Change Mgmt

Requirements

Elaboration

Transition

Inception

Construction

The purpose of Requirements is:

To establish and maintain agreement with the customers and other stakeholders on what the system should do.
To give system developers a better understanding of the requirements of the system.
To delimit the system.
To provide a basis for planning the technical contents of the iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user interface of the system.

43 of 141

What Are the Benefits of a Use-Case Model?

Used to communicate with the end users and domain experts

Provides buy-in at an early stage of system development
Insures a mutual understanding of the requirements

Used to identify

Who interacts with the system and what the system should do
The interfaces the system should have

Used to verify

All requirements have been captured
The development team understands the requirements

44 of 141

Relevant Requirements Artifacts

Supplementary

Specification

Glossary

Use-Case Specifications

...

Use-Case Model

Actors

Use Cases

45 of 141

Case Study: Course Registration Problem Statement

Review the problem statement provided in the Course Registration Requirements Document

46 of 141

Major Concepts in Use-Case Modeling

An actor represents anything external that interacts with the system.
A use case is a set of sequence of actions a system performs that yields an observable result of value to a particular actor.

Use Case

Actor

47 of 141

Problem Analysis Steps

Identify stakeholders.
Understand the root causes.
Gain agreement on the problem definition.
Identify constraints on the system or project.
Identify and validate the solution against the root causes.
Define the solution system boundary.

Above is a list of activities that you go through when performing a problem analysis. Start by identifying stakeholders for the problem. These stakeholders are people who are affected by the problem. Next, understand the root causes for the problem (the real problem behind the problem). Once the real problem (root cause) has been identified, get all your stakeholders to agree to a description of the problem.

Armed with a description of the problem, identify any constraints that may be imposed on any solution. These constraints typically limit the solution you may provide.

Next, identify possible solutions for the problem. It is important that you identify more than one possible solution. By doing this, you can then compare and contrast the solutions to find the best possible solution.

An additional step not described above is to expand the set of stakeholders to include those affected by the specific solution you have identified.

The final step is to define the boundary of the solution. This is used to limit the scope during Understand Stakeholder’s Needs.

48 of 141

Problem Analysis Roadmap

Elicit Requirements

Expand stakeholder list for solution.

Choose the best solution(s) to meet the goals.

Best solution identified

Problem validated/adjusted

Business problem defined

Actual problem identified

and defined

Identify stakeholders for problem.

Root cause analysis.

Reassess that the solution idea is the best solution.

Understand the problem in the context of the business goals.

Business

Problem

Solution idea or Opportunity

This slide shows the two typical approaches to defining a system. One approach is where someone has an idea or recognizes a need and develops a product to solve that problem. The other stems from the realization that there is some problem that needs solving. In the case of the former, an analysis of the business problem is often implied or thought out informally.

No matter which perspective you start from, it is important to understand where the system fits in the context of the goals of the organization. Failing to do this could mean you develop a system that adds little or no business value. In fact, it is possible that the wrong system could impede an organization from achieving its business goals.

Note: The Standish Group uses the term Business Objectives. The Rational Unified Process uses the term Business Goals. They are the same thing.

A common reason for project failure is that people start with a solution idea and head straight to development. When the project starts to fail, they almost always back track through this workflow.

49 of 141

Stakeholders: Definitions

Stakeholder

An individual who is materially affected by the outcome of the system or the project(s) producing the system.

Stakeholder Representative

A stakeholder representative represents one or more stakeholders. They are directly involved in the steering, shaping, and scoping of the project.

There are many sources of requirements. Requirements may come from anyone with an interest in the outcome of a project. It is important to determine who those sources are early in your analysis. End users are the most obvious group to consider, but there are many others that should be included: for instance, who will maintain the system; who has an economic interest in the outcome; who will develop, test, and support the product.

Failure to consider some of these stakeholders can lead to unexpected project costs and failures.

For example, you might release your project and have the Helpdesk manager saying: “The system is too complicated. We’re losing money on support because our customers cannot use the system.”

A Manager of Installations: “It takes too long to install, so we’re losing money with each installation; we can’t bill for the extra time.”

You have to consider the input of these stakeholders as part of the early evaluation process.

To keep the size of your stakeholder list manageable, it is important that you identify one or two people to represent each stakeholder type. The stakeholder representative should be a domain expert and have the authority to speak on behalf of the group they represent.

Some example stakeholders are:

Sponsors: Business managers, financiers, shareholders, champions, sellers, marketers, steering committee members, investors.

Authorities: Legislative authorities, standards organizations, organizational governance departments, external and internal regulatory bodies, domain experts, technology experts.

50 of 141

Identify the Stakeholders

Each group of stakeholders needs a representative.
Not all stakeholder groups need to be consulted.

Some will provide requirements.

Customers, users, system administrators

Some may not provide requirements.

Shareholders

Who are some of the stakeholders for your projects?

Part of analyzing the problem is understanding who has the problem. You need to understand the real stakeholders in your project, in addition to the customer who is paying the bill.

Make sure you consider all those affected by the outcome of the system, including stock shareholders, system maintainers, and developers. It is important to consider which stakeholders are sources of requirements. While we must identify all our stakeholders, it is important to focus your efforts where you receive the best return. Some of your stakeholders will not provide you with many or any requirements (for example, shareholders). While these interests certainly need to be considered and represented, you should focus your efforts accordingly. For example, if a system is mission critical, then a shareholder is certainly a stakeholder, but will they have any meaningful requests of the system? Generally, they will not.

Who are possible stakeholders for your own projects?

51 of 141

Describe Stakeholders in the Vision Document

Stakeholder	Registrar
Representative	Kelly Hansen
Description	User
Type	The Registrar is typically a college-educated professional with full computer skills. The Registrar is trained and experienced with the use of the current batch-oriented registration .
Responsibilities	The Registrar is responsible for administering course registration for each school term. This includes supervising administrative and data entry personnel.
Success Criteria	The registrar’s primary responsibility will be maintaining student and professor databases, and opening/closing courses to registration. The registrar’s office will also be required to perform ….
Involvement	The registrar’s primary responsibility will be maintaining student and professor databases, and opening/closing courses to registration. The registrar’s office will also be required to perform…..
Deliverables	Management reviewer – especially related to functionality and usability of features required by the Registrar staff.
Comments/ Concerns	None

52 of 141

What Is the Problem Behind the Problem?

Fishbone Diagram Techniques

List contributing causes to the identified problem.�Keep asking “Why?” (expand each rib).

The perceived business problem.

No Banking at night

Too much waiting

Want Privacy

when banking

Customers are dissatisfied with our service.

Banking in airports

Want more banking

locations

Queues in the

branches are too long

“Customers are dissatisfied with our service.” Is this really the true problem?

The fishbone diagram is one method for finding the “root cause” of a problem.

The spines are contributing causes to the problem.

Once the root causes have been defined, focus on the ones that contribute most to the problem. You can then further explore the most important root causes to reveal contributing factors to these causes: expand each rib by building spines branching off the rib, or do a separate second-level fishbone diagram with a first-level root cause as “the problem.”

What you often discover is that there may be more than one simple problem involved. Instead, there may be many dimensions to and perceptions of what the problem really is. You may need to help the customer focus on the dimensions of the problem that they most need to solve.

You help the customer focus on the problem that really needs to be solved.

Once you have a list of problems, you then need to perform a little analysis to identify the best solution to the biggest contributors to the problem. This step comes after you have all agreed to the main contributing problems.

53 of 141

Problem Analysis – Validating a Solution

List the reasons why the solution is the right solution.�Keep asking “Why?” (expand each rib).

No Banking at night

Too much waiting

Customers are dissatisfied with

our service

We need ATMs.

Banking in airports

Want more banking

locations

Queues in the

branches are too long

The perceived solution to some ill-defined problem.

This technique can also be used to validate a solution. Many of our customers come to us with a request for a solution before they understand what problem they are really solving. For example, “We need automatic teller machines.” If we simply implement their solution without first analyzing the problem, we risk solving the wrong problem. After their own solution is delivered, the customer might find the delivered system useless for solving the real problem.

When you are presented with a solution like this, the customer has probably already done some informal problem analysis (usually in their head). The fishbone diagram can be used to validate that the solution really will solve the right problem.

Once the root causes have been defined, focus on the ones that contribute most to the problem. You can then further explore the most important root causes to reveal contributing factors to these causes: expand each rib by building spines branching off the rib, or do a separate second-level fishbone diagram with a first-level root cause as “the problem.”

What you often discover is that there may be more than one simple problem involved. Instead, there may be many dimensions to and perceptions of what the problem really is. You may need to help the customer focus on the dimensions of the problem that they most need to solve.

Once you have a list of problems, look at the solution you are proposing and assess whether it is the best solution to the main contributing problems. This step comes after you have all agreed to the main contributing problems.

54 of 141

Focus on Largest Contributors - Pareto’s Law

Benefit

Effort

20%

80%

Rank in order. Use the 80-20 Rule to focus on the top contributing causes to address the greatest portion of the problem.

20% of the effort yields 80% of the benefit.

One way of focusing on the most important root causes is the Pareto Principle, or “80-20 rule.” A Pareto chart ranks the contributing causes in the order of their contribution to the problem, so it is easy to see the largest contributors. A Pareto diagram can also be thought of as a “Fishbone diagram with numbers. ” Assign a weight to each bone and then graph it.

Notice that in the example, 80% of the problem is caused by the top two contributors. Where do the percentages come from? In some situations, you can measure how much each factor contributes to a problem. For example, if a mail order business is getting too many products returned, the business can ask each customer why the items were returned and tabulate the factors contributing to returns.

In other situations, the percentage contributions are estimates. For example, if a business is investigating the need for ATM machines, they can use focus groups to estimate the perceived problems associated with a lack of such facilities.

In many cases, rough estimates are used rather than hard data. In some cases, the top contributing causes are obvious. Focus on the top contributing causes rather than coming up with solutions to minor factors.

55 of 141

Understand the Broader Context of the Problem

A lack of understanding the business and its goals increases risk.
Does the problem have an organization/process component?
Does the team understand the domain in which the problem exists?
Does solving the problem present the opportunity to make process improvements?

Armed with a clear definition of the root causes to the business problem, it is important to ensure that the solution supports the business both operationally and strategically.

A new system might also provide the organization with the opportunity to improve the way it operates.

To do this, a more thorough understanding of the business may be required. Business modeling is a tool that you can use to help you answer these questions.

Some reasons to perform business modeling are:

To identify what to automate in a business.
To show how a tool can be used in the business.
As the first step in re-engineering the way a business currently conducts business.

Some reasons to skip business modeling are:

The product is a commercial product, rather than a contract (such as MS Word).
The product’s domain is well understood by the development team and clients.

56 of 141

Requirements Overview Topics

Introduction
Key Concepts
Use-Case Model
Glossary
Supplementary Specifications
Checkpoints

57 of 141

Major Use-Case Modeling Elements

Actor

Someone/something outside the system, acting in a role that interacts with the system

Use case

Represents something of value that the system does for its actors

Actor

Use Case

58 of 141

An actor represents a role that a human, hardware device, or another system can play in relation to the system.
Actor names should clearly denote the actor’s role.

Define Actors: Focus on the Roles

?

59 of 141

What Is System Behavior?

System behavior is how a system acts and reacts.

It is the outwardly visible and testable activity of a system

System behavior is captured in use cases.

Use cases describe the system, its environment, and the relationship between the system and its environment.

60 of 141

What Is a Use Case?

defines a sequence of actions

performed by a system

that yields an observable result of value

to an actor.

A use case

Use Case Name

A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor.

“Sequence of actions”: Atomic activities, decisions, and requests. Each action is performed fully or not at all.
“Performed by a system”: The actions performed by the system are the functional requirements.
“Observable result of value”: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.
“To an actor”: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called “Operate the Registration System.” It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.

Often the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case.

61 of 141

Use Cases Contain Software Requirements

Each use case

Describes actions the system takes to deliver something of value to an actor.
Shows the system functionality an actor uses.
Models a dialog between the system and actors.
Is a complete and meaningful flow of events from the perspective of a particular actor.

62 of 141

What Is a Use-Case Model?

A model that describes a system’s functional requirements in terms of use cases
A model of the system’s intended functionality (use cases) and its environment (actors)

Student

View Report Card

Register for Courses

Login

63 of 141

How Should I Name a Use Case?

Indicate the value or goal of the actor.
Use the active form; begin with a verb.
Imagine a to-do list.
Examples of variations

Register for Courses
Registering for Courses
Acknowledge Registration
Course Registration
Use Registration System

Which variations show the value to the actor? Which do not?

Which would you choose as the use-case name? Why?

64 of 141

Identify Use Cases

What are the goals of each actor?

Why does the actor want to use the system?
Will the actor create, store, change, remove, or read data in the system? If so, why?
Will the actor need to inform the system about external events or changes?
Will the actor need to be informed about certain occurrences in the system?

Does the system supply the business with all of the correct behavior?

Here are some questions that are useful to help you find the use cases in your system. The best way to find use cases is to consider what each actor requires of the system. Go through all the actors and identify the particular needs of each actor.

When you have made your first list of use cases, verify that all required functionality has been treated. Do not forget special use cases for system startup, termination, or maintenance. Also, do not forget to include use cases for automatically scheduled events. For example, a time-initiated job may run the payroll at midnight on the last day of each month. Use cases that concern automatically scheduled events are usually initiated by a special actor: the scheduler.

Try to keep all use cases at approximately the same level of importance. The notion of use-case levels as popularized by some authors is not recommended. It can lead to a functionally decomposed system.

The above questions can help get the right granularity (refer also to the definition of a use case). Ask yourself:

Would you ever want to perform a particular activity as an end result in itself?
Are there any activities that should be kept together so you can review, modify, test, and document them together?
Is the use case too complex? If it is, you may want to split it (a use-case report significantly longer than 10 pages may be a candidate).

Give each use case a name that indicates what an instance of the use case does. The name may have to consist of several words to be clearly understood.

Does it deliver something of value to multiple actors? If so, it may be too large.

65 of 141

Identify Actors

Who/what uses the system?
Who/what gets information from this system?
Who/what provides information to the system?
Where in the company is the system used?
Who/what supports and maintains the system?
What other systems use this system?

Here are some questions that may be used to help identify the actors in the system.

To fully understand the system's purpose, you must know who or what the system is for, that is, who or what use it. Different user types are represented as actors.

An actor is any person or any thing that is outside the system and that exchanges data with the system. An actor can either give information, receive information, or give and receive information.

Actor is a role, not a particular person or thing. The name of the actor should represent, as clearly as possible, the actor’s role.�Make sure that there is little risk of confusing one actor’s name with another at a future stage of the work. Also, try to avoid an actor called “User,” rather try to figure out the role of that particular user.

In most instances, some person or some other system does something to trigger the start of the use case. If a use case in your system is initiated at a certain time, for example, at the end of the day or the end of the month, this can be modeled with a special actor, such as the “scheduler” or “time.” “Scheduler,” as opposed to “time,” is a useful name for such an actor because scheduler may be human or non-human. “Time” leaves an element of design in your use case model.

66 of 141

Find Actors

Student

Registrar

Registration System

The student never touches the system; the registrar operates it.

Or, are you building an Internet application?

Online Registration System

(www.college.edu)

Student

Who is pressing the keys (interacting with the system)?

67 of 141

Description of an Actor

Text

Name Student

Brief description A person who signs up for a course.

Relationships with

use cases

Register for Courses

Student

Use-Case-Model

Survey

68 of 141

Steps for Creating a Use-Case Model

Find actors and use cases.

Identify and briefly describe actors.
Identify and briefly describe use cases.

Write the use cases.

Outline all use cases.
Prioritize the use-case flows.
Detail the flows in order of priority.

Creating a use-case model involves putting the pieces you have learned together. First, the actors and the use cases are found by using the requirements of customers and potential users as vital information. As they are discovered, the use cases and the actors are identified and illustrated in a use-case diagram. Next, the steps in a use case are outlined to get a sketch of the flow.

The actor's name must clearly denote the actor's role. Make sure there is little risk at a future stage of confusing one actor's name with another.

Define each actor by writing a brief description that includes the actor's area of responsibility and what the actor needs the system for. Because actors represent things outside the system, you need not describe them in detail.

Each use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name.

Define each use case by writing a brief description of it. As you write the description, refer to the glossary and, if you need to, define new terms.

When the actors and use cases have been found, each use case is described in detail. These descriptions show how the system interacts with the actors and what the system does in each individual case. In an iterative development environment, you select a set of use case flows to be detailed in each iteration. These are prioritized in such a way that technical risk is mitigated early and the customer gets important functionality before less important functionality.

69 of 141

How Would You Read This Diagram?

Course Catalog

View Report Card

Register for Courses

Submit Grades

Select Courses to Teach

Student

Professor

Billing System

Maintain Student Information

Maintain Professor Information

Login

Close Registration

Registrar

70 of 141

Global Use case Diagram

71 of 141

Use-Case Specifications

Name
Brief description
Flows of Events
Relationships
Activity diagrams
Use-Case diagrams
Special requirements
Pre-conditions
Post-conditions
Other diagrams

Use-Case Specifications

...

Use-Case Model

Actors

Use Cases

72 of 141

Use-Case Flow of Events

Has one normal, basic flow
Several alternative flows

Regular variants
Odd cases
Exceptional flows handling error situations

73 of 141

What Are Scenarios ?

A scenario is an instance of a use case

74 of 141

What Is an Activity Diagram?

An activity diagram in the use-case model can be used to capture the activities in a use case.
It is essentially a flow chart, showing flow of control from activity to activity.

Flow of Events

This use case starts when the Registrar requests that the system close registration.

1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.

2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.�

75 of 141

Objectives: Concepts of Object Orientation

Review the basic principles of object orientation
Review the basic concepts and terms of object orientation and the associated UML notation
Review the strengths of object orientation
Review some basic UML modeling notation

76 of 141

Best Practices Implementation

Object Technology helps implement these Best Practices.

Develop iteratively: tolerates changing requirements, integrates elements progressively, facilitates reuse.
Use component-based Architectures: architectural emphasis, component-based development.
Model visually: easy understanding, easy modification.

Iterative development allows you to account for technological changes. If a technology changes, becomes a standard, or new technology appears, the project can take advantage of it. This is particularly true for platform changes or lower-level infrastructure changes.
Integration is not one "big bang" at the end. Elements are integrated progressively. Actually, the iterative approach is almost continuous integration. Non-iterative integration takes up to 40 percent of the total effort at the end of a project and is hard to plan accurately. What used to be a long, uncertain and difficult process is broken down into six to nine smaller integrations that start with far fewer elements to integrate.
By clearly articulating the major components and the critical interfaces between them, an architecture allows you to reason about reuse, both internal (the identification of common parts) and external (the incorporation of off-the-shelf components). It also allows reuse on a larger scale, the reuse of the architecture itself in the context of a line of products that addresses different functionality in a common domain.
An object-oriented model aims at reflecting the world we experience in reality. Thus, the objects themselves often correspond to phenomena in the real world that the system is to handle. For example, an object can be an invoice in a business system or an employee in a payroll system.
A model, correctly designed using object technology, is easy to understand and modify. It clearly corresponds to reality and changes in a particular phenomenon concern only the object that represents that phenomenon.

77 of 141

What is Object Technology ?

Object technology is used for creating models that reflect a specific domain using the terminology of the domain.
Models created using object technology should be easy to create, change, expand, validate, and verify.
Systems built using object technology are flexible to change, have well-defined architectures, and have the opportunity to create and implement reusable components.
Models created using object technology are conveniently implemented in software using object-oriented programming languages.
Object technology is not just a theory, but a well-proven technology used in a large number of projects and for building many types of systems.

78 of 141

What Is Object Technology?

Object Technology

A set of principles guiding software construction together with languages, databases, and other tools that support those principles. (Object Technology - A Manager’s Guide, Taylor, 1997)

Object technology is used for creating models that reflect a specific domain using the terminology of the domain.
Models created using object technology should be easy to create, change, expand, validate, and verify.
Systems built using object technology are flexible to change, have well-defined architectures, and have the opportunity to create and implement reusable components.
Models created using object technology are conveniently implemented in software using object-oriented programming languages.
Object technology is not just a theory, but a well-proven technology used in a large number of projects and for building many types of systems.
Successful implementation of object technology requires a method that integrates a development process and a modeling language with suitable construction techniques and tools. (UML Toolkit, Eriksson and Penker, 1997)

79 of 141

Strengths of Object Technology

A single paradigm

A single language used by users, analysts, designers, and implementers

Facilitates architectural and code reuse
Models more closely reflect the real world

More accurately describes corporate entities
Decomposed based on natural partitioning
Easier to understand and maintain

Stability

A small change in requirements does not mean massive changes in the system under development

Adaptive to change

The UML represents the convergence of this Best Practice throughout the object-technology industry. It provides a consistent language that can be applied for both system and business engineering.
By clearly articulating the major components and the critical interfaces between them, an architecture lets you reason about reuse, both internal reuse (the identification of common parts) and external reuse (the incorporation of ready made, off-the-shelf components). But it also allows reuse on a larger scale, the reuse of the architecture itself in the context of a line of products that addresses different functionality in a common domain.
An object-oriented model aims at reflecting the world we experience in reality. Thus, the objects themselves often correspond to phenomena in the real world that the system is to handle. For example, an object can be an invoice in a business system or an employee in a payroll system.
Object technology can help a company change its systems almost as fast as the company itself changes.

80 of 141

What Is a Model?

A model is a simplification of reality.

81 of 141

What is Model?

According to Grady Booch, a model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under construction. A good model includes those elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.

82 of 141

Model is :

83 of 141

Why Do We Model?

We build models to better understand the system we are developing.
Modeling achieves four aims. Modeling:

Helps us to visualize a system as we want it to be.
Permits us to specify the structure or behavior of a system.
Gives us a template that guides us in constructing a system.
Documents the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

According to Booch in The Unified Modeling Language Use Guide, modeling achieves four aims:

Models help us to visualize a system as we want it to be. A model helps the software team communicate the vision for the system being developed. It is very difficult for a software team to have a unified vision of a system that is only described in specification and requirement documents. Models bring about understanding of the system.
Models permit us to specify the structure of behavior of a system. A model allows us to document system behavior and structure before coding the system.
Models give us a template that guides us in constructing a system. A model is an invaluable tool during construction. It serves as a road map for a developer. Have you experienced a situation where a developer coded incorrect behavior because he/she was confused over the wording in a requirements document? Modeling helps alleviate that situation.
Models document the decisions we’ve made. Models are valuable tools long term because they give “hard” information on design decisions. We don’t need to rely on someone’s memory.

84 of 141

What Is an Object?

Informally, an object represents an entity, either physical, conceptual, or software.

Physical entity��
Conceptual entity��
Software entity

Truck

Chemical Process

Linked List

85 of 141

A More Formal Definition

An object is 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.

Object

Operations

Attributes

86 of 141

Object ?

An object is an entity that has a well-defined boundary. That is, the purpose of the object should be clear.
An object has two key components: attributes and operations.
Attributes represent an object’s state, and operations represent the behavior of the object.

87 of 141

An Object Has State

The state of an object is one of the possible conditions in which an object may exist.
The state of an object normally changes over time.

Name: J Clark

Employee ID: 567138

HireDate: 07/25/1991

Status: Tenured

Discipline: Finance

MaxLoad: 3

Name: J Clark

Employee ID: 567138

Date Hired: July 25, 1991

Status: Tenured

Discipline: Finance

Maximum Course Load: 3 classes

Professor Clark

88 of 141

An Object Has Behavior

Behavior determines how an object acts and reacts.
The visible behavior of an object is modeled by the set of messages it can respond to (operations the object can perform).

Professor Clark’s behavior

Submit Final Grades

Accept Course Offering

Take Sabbatical

Maximum Course Load: 3 classes

SubmitFinalGrades()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

89 of 141

An Object Has Identity

Each object has a unique identity, even if the state is identical to that of another object.

Professor “J Clark” teaches Biology

90 of 141

Representing Objects in the UML

An object is represented as a rectangle with an underlined name.

Named Object

Unnamed Object

Professor J Clark

91 of 141

Basic Principles of Object Orientation

Object Orientation

Encapsulation

Abstraction

Hierarchy

Modularity

92 of 141

What Is Abstraction?

The essential characteristics of an entity that distinguish it from all other kinds of entities
Defines a boundary relative to the �perspective of the viewer
Is not a concrete manifestation, denotes the ideal essence of something

93 of 141

Abstraction :

Any model that includes the most important, essential, or distinguishing aspects of something while suppressing or ignoring less important, immaterial, or diversionary details. The result of removing distinctions so as to emphasize commonalties. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)
Abstraction allows us to manage complexity by concentrating on the essential characteristics of an entity that distinguish it from all other kind of entities.
An abstraction is domain and perspective dependent. That is, what is important in one context, may not be in another.
OO allows us to model our system using abstractions from the problem domain (for example, classes and objects).

94 of 141

Abstraction Example :

A car is an example of an abstraction. A car is an abstraction for “a mobile, powered vehicle for transporting people from place to place.”
The abstract use of car is not concrete. However, if you describe the car as a 1995 Blue Ford Mustang, then it becomes a concrete manifestation and not an abstraction.

95 of 141

Example: Abstraction

Student

Professor

Course Offering (9:00 AM,

Monday-Wednesday-Friday)

Course (e.g. Algebra)

96 of 141

What Is Encapsulation?

Improves Resiliency

Hide implementation from clients.

Clients depend on interface.

Encapsulation can be defined as:

The physical localization of features (e.g., properties, behaviors) into a single blackbox abstraction that hides their implementation (and associated design decisions) behind a public interface. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

Encapsulation is often referred to as “information hiding,” making it possible for the clients to operate without knowing how the implementation fulfills the interface.
Encapsulation eliminates direct dependencies on the implementation (clients depend on/use the interface). Thus, it’s possible to change the implementation without updating the clients as long as the interface is unchanged.
Clients will not be affected by changes in implementation. This reduces the “ripple effect,” which happens when a correction to one operation forces the corresponding correction in a client operation and so on. As a result of encapsulation, maintenance is easier and less expensive.
Encapsulation offers two kinds of protection. It protects an object’s internal state from being corrupted by its clients and client code from changes in the object’s implementation.

97 of 141

Encapsulation ?

The physical localization of features (e.g., properties, behaviors) into a single blackbox abstraction that hides their implementation (and associated design decisions) behind a public interface.
Encapsulation is often referred to as “information hiding,” making it possible for the clients to operate without knowing how the implementation fulfills the interface.
Encapsulation eliminates direct dependencies on the implementation (clients depend on/use the interface). Thus, it’s possible to change the implementation without updating the clients as long as the interface is unchanged.
Clients will not be affected by changes in implementation. This reduces the “ripple effect,” which happens when a correction to one operation forces the corresponding correction in a client operation and so on. As a result of encapsulation, maintenance is easier and less expensive.
Encapsulation offers two kinds of protection. It protects an object’s internal state from being corrupted by its clients and client code from changes in the object’s implementation.

98 of 141

Example on Encapsulation ?

An example is a car’s accelerator. Generally speaking, you put your foot down and the car goes faster. You don’t worry about the cables, electronics, engine, and the rest.

99 of 141

Encapsulation Illustrated

Professor Clark needs to be able to teach four classes in the next semester.

SubmitFinalGrades()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

Name: J Clark

Employee ID: 567138

HireDate: 07/25/1991

Status: Tenured

Discipline: Finance

MaxLoad:4

SetMaxLoad(4)

The key to encapsulation is an object’s message interface. The object interface ensures that all communication with the object takes place through a set of predefined operations. Data inside the object is only accessible by the object’s operations. No other object can reach inside of the object and change its attribute values.
For example, Professor Clark needs to have her maximum course load increased from three classes to four classes per semester. Another object will make a request to Professor Clark to set the maximum course load to four. The attribute, MaxLoad, is then changed by the SetMaxLoad() operation.
Encapsulation is beneficial in this example because the requesting object does not need to know how to change the maximum course load. In the future, the number of variables that are used to define the maximum course load may be increased, but that doesn’t affect the requesting object. The requesting object depends on the operation interface for the Professor Clark object.

100 of 141

What Is Modularity?

Modularity is the breaking up of something complex into manageable pieces.
Modularity helps people to understand complex systems.

101 of 141

Example: Modularity

Course Registration System

?

Billing System

Course Catalog System

Student Management System

102 of 141

What Is Hierarchy?

Decreasing

abstraction

Increasing

abstraction

Asset

RealEstate

Savings

BankAccount

Checking

Stock

Security

Bond

Elements at the same level of the hierarchy should be at the same level of abstraction.

Hierarchy can be defined as:

Any ranking or ordering of abstractions into a tree-like structure. Kinds: Aggregation hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

Hierarchy organizes items in a particular order or rank (for example, complexity, responsibility, and so on). This organization is dependent on perspective. Using a hierarchy to describe differences or variations of a particular concept provides for more descriptive and cohesive abstractions and a better allocation of responsibility.
In any one system, there may be multiple abstraction hierarchies (for example, a financial application may have different types of customers and accounts).
Hierarchy is not an organizational chart nor a functional decomposition.
Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize similarities and differences. For example, botany organizes plants into families. Chemistry organizes elements in a periodic table.

103 of 141

What Is a Class?

A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.

An object is an instance of a class.

A class is an abstraction in that it

Emphasizes relevant characteristics.
Suppresses other characteristics.

104 of 141

Representing Classes in the UML

A class is represented using a rectangle with compartments.

Professor J Clark

105 of 141

The Relationship Between Classes and Objects

A class is an abstract definition of an object.

It defines the structure and behavior of each object in the class.
It serves as a template for creating objects

Objects are grouped into classes.

Professor Paul Meijer

Professor Tom Allen

Professor Jane Torpie

A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.
An object is defined by a class. A class defines a template for the structure and behavior of all its objects. The objects created from a class are also called the instances of the class.
The class is the static description, the object is a run-time instance of that class.
Since we model from real-world objects, software objects are based on the real-world objects, but they exist only in the context of the system.
Starting with real-world objects, abstract out what you don't care about. Then, take these abstractions and categorize, or classify them, based on what you do care about. Classes in the model are the result of this classification process.
These classes are then used as templates within an executing software system to create software objects. These software objects represent the real-world objects we originally started with.
Some classes/objects may be defined that don't represent real-world objects. They are there to support the design and are "software only.”

106 of 141

What Is an Attribute?

An attribute is a named property of a class that describes a range of values that instances of the property may hold.

A class may have any number of attributes or no attributes at all.

Attributes

107 of 141

What Is an Operation?

An operation is the implementation of a service that can be requested from any object of the class to affect behavior.
A class may have any number of operations or none at all.

Operations

108 of 141

What Is Polymorphism?

Manufacturer A

Manufacturer B

Manufacturer C

OO Principle:�Encapsulation

The ability to hide many different implementations behind a single interface

109 of 141

Example: Polymorphism

Stock

Bond

Mutual Fund

Get Current Value

getCurrentValue()

In this example, a requesting object would like to know the current value of a financial instrument. However, the current value for each financial instrument is calculated in a different fashion. The stock needs to determine the current asking price in the financial market that it is listed under. The bond needs to determine the time to maturity and interest rates. A mutual fund needs to look up the closing price for the day from the fund management company.

In a non object-oriented development environment, we would write code that may look something like this:

IF financialInstrument = Stock THEN

calcStockValue()

IF financialInstrument = Bond THEN

calcBondValue()

IF financialInstrument = MutualFund THEN

calcMutualFundValue()

With object technology, each financial instrument can be represented by a class, and each class would know how to calculate its own value. The requesting object simply needs to ask the specific object (for example, Stock) to get its current value. The requesting object does not need to keep track of three different operation signatures. It only needs to know one. Polymorphism allows the same message to be handled in different ways depending on the object that receives it.

110 of 141

What is an Interface?

Interfaces formalize polymorphism
Interfaces support “plug-and-play” architectures

Realization relationship

(stay tuned for realization relationships)

Shape

draw()

move()

scale()

rotate()

<<Interface>>

Tube

Pyramid

Cube

From the UML User’s Guide (Booch, 1999): An interface is “a collection of operations that are used to specify a service of a class or a component.”

Interfaces formalize polymorphism. They allow us to define polymorphism in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. In other words, if two objects use the same behaviors to get different, but similar results, they are considered to be polymorphic. A cube and a pyramid can both be drawn, moved, scaled, and rotated, but they look very different.

You’ve probably heard that polymorphism one of the big benefits of object orientation, but without interfaces there was no way to enforce it, verify it, or even express it except in informal or language-specific ways. Formalization of interfaces strips away the mystery of polymorphism and gives us a good way to describe, in precise terms, what polymorphism is all about. Interfaces are testable, verifiable, and precise.

Interfaces are the key to the “plug-and-play” ability of an architecture: Any classifiers (e.g., classes, subsystems, components) which realize the same interfaces may be substituted for one another in the system, thereby supporting the changing of implementations without affecting clients.

Realization relationships are discussed later in this module.

111 of 141

How Do You Represent An Interface?

Elided/Iconic Representation�(“lollipop”)

Canonical (Class/Stereotype) Representation

(stay tuned for realization relationships)

Shape

draw()

move()

scale()

rotate()

<<Interface>>

Shape

Tube

Pyramid

Cube

Tube

Pyramid

Cube

112 of 141

What Is a Package?

A package is a general purpose mechanism for organizing elements into groups.
It is a model element that can contain other model elements.

A package can be used

To organize the model under development.
As a unit of configuration management.

University

Artifacts

A package can be defined as:

A general purpose mechanism for organizing elements into groups. (The Unified Modeling Language User Guide, Booch, 1999)

Models can contain hundreds and even thousands of model elements. The sheer number of these elements can quickly become overwhelming. Therefore, it’s critical to group model elements into logical collections to maintain and easily read the model (application of modularity and hierarchy).
Packages are a general grouping mechanism for grouping elements into semantically related groups. A package contains classes that are needed by a number of different packages, but are treated as a “behavioral unit.”
A package is simply a grouping mechanism. No semantics are defined for its instances. Thus, packages do not necessarily have a representation in implementation, except, maybe, to represent a directory.
In the UML, a package is represented as a tabbed folder.

113 of 141

What is a Subsystem?

A combination of a package (can contain other model elements) and a class (has behavior)
Realizes one or more interfaces which define its behavior

OO Principles: Encapsulation and Modularity

Interface

Realization

Subsystem

(stay tuned for realization relationship)

Subsystem

Name

<<subsystem>>

Interface

114 of 141

What is a Component?

A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture
A component may be

A source code component
A run time components or
An executable component

Source File

Name

<<EXE>>

Executable

Name

OO Principle:�Encapsulation

<<DLL>>

Component

Name

Component Interface

From the UML User’s Guide (Booch, 1999): A component is “a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.”

Software components include:

Source code components (e.g., .h, .cpp files, shell scripts, data files),
Binary code components. Examples include: Java Beans, ActiveX controls, COM objects (DLL's and OCX's from VB), CORBA objects), and
Executable components (.exe’s).

Stereotypes (with alternate icons) may be used to define these specific kinds of components.

Component-based development is the creation and deployment of software-intensive systems assembled from components. Component software development should not be confused with object-oriented programming (OOP). OOP is a way to build object-based software components. Component based development (CBD) is a technology that allows you to combine object-based components. OOP is concerned with creating objects, CBD is concerned with making objects work together.

A component conforms to and provides the physical realization of a set of interfaces. Components are implementation things. They are the physical realization of an abstraction in your design. Interfaces were discussed earlier in this module.

115 of 141

Subsystems and Components

Components are the physical realization of an abstraction in the design
Subsystems can be used to represent the component in the design

Design Model

Implementation Model

Component

Name

<<subsystem>>

Component Name

Component Interface

OO Principles: Encapsulation and Modularity

116 of 141

What Is an Association?

The semantic relationship between two or more classifiers that specifies connections among their instances

A structural relationship, specifying that objects of one thing are connected to objects of another

Course

<<entity>>

Student

<<entity>>

Schedule

<<entity>>

An association can be defined as:

The semantic relationship between two or more classifiers that specifies connections among their instances. In other words, an association is a structural relationship that specifies that objects (instances of classes) are connected to other objects.

The way that we show relationships between classes is through the use of associations. Associations are represented on class diagrams by a line connecting the associating classes. Data may flow in either direction or both directions across a link.
Most associations are simple. That is, they exist between exactly two classes. They are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible.
Sometimes, a class has an association to itself. This does not always mean that an instance of that class has an association to itself. More often, it means that one instance of the class has associations to other instances of the same class.
This example shows that a student object is related to a schedule object. The second example demonstrates how a course object can be related to another course object.

117 of 141

What Is Multiplicity?

Multiplicity is the number of instances of one class relates to ONE instance of another class.
For each association, there are two multiplicity decisions to make, one for each end of the association.

For each instance of Professor, many Course Offerings may be taught.
For each instance of Course Offering, there may be either one or zero Professor as the instructor.

Professor

<<entity>>

CourseOffering

<<entity>>

0..1

0..*

0..1

0..*

instructor

118 of 141

Multiplicity Indicators

Unspecified
Exactly one
Zero or more (many, unlimited)

One or more
Zero or one (optional scalar role)
Specified range
Multiple, disjoint ranges

2..4

0..1

1..*

0..*

1

*

2, 4..6

119 of 141

What Is Aggregation?

An aggregation is a special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

An aggregation “Is a part-of” relationship.

Multiplicity is represented like other associations.

Part

Whole

0..1

1

0..1

An aggregation can be defined as:

A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

Aggregation is used to model a compositional relationship between model elements. There are many examples of compositional relationships: a Library contains Books, Departments are made up of Employees, a computer is composed of a number of Devices. To model an aggregation, the aggregate (Department) has an aggregation association to the its constituent parts (Employee).
A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation.
An aggregation relationship that has a multiplicity greater than one for the aggregate is called shared. Destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation forms a graph or a tree with many roots. Shared aggregations are used where there is a strong relationship between two classes. So, the same instance can participate in two different aggregations.

120 of 141

What Is Navigability?

Indicates that it is possible to navigate from a associating class to the target class using the association

RegistrationController

<<control>>

CourseOffering

<<entity>>

Schedule

<<entity>>

The navigability property on a role indicates that it is possible to navigate from a associating class to the target class using the association. This may be implemented in a number of ways: by direct object references, by associative arrays, hash-tables, or any other implementation technique that allows one object to reference another.
Navigability is indicated by an open arrow placed on the target end of the association line next to the target class (the one being navigated to). The default value of the navigability property is true (associations are bi-directional by default).
In the course registration example, the association between the Schedule and the Course Offering is navigable in both directions. That is, a Schedule must know the Course Offering assigned to the Schedule and the Course Offering must know the Schedules it has been placed in.
When no arrowheads are shown, the association is assumed to be navigable in both directions.
In the case of the association between Schedule and Registration Controller, the Registration Controller must know its Schedules, but the Schedules have no knowledge of the Registration Controllers (or other classes). As a result, the navigability property of the Registration Controller end of the association is turned off.

121 of 141

Relationships: Dependency

A relationship between two model elements where a change in one may cause a change in the other
Non-structural, “using” relationship

Package

Class

Dependency relationship

Component

Client

Supplier

ClientPackage

SupplierPackage

Client

Supplier

122 of 141

What Is Generalization?

A relationship among classes where one class shares the structure and/or behavior of one or more classes
Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses

Single inheritance
Multiple inheritance

Is an “is a kind of” relationship

Generalization can be defined as:

A specialization/generalization relationship, in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). (The Unified Modeling Language User Guide, Booch, 1999)

The subclass may be used where the superclass is used, but not vice versa.
The child inherits from the parent.
Generalization is transitive. You can always test your generalization by applying the “is a kind of” rule. You should always be able to say that your specialized class “is a kind of” the parent class.
The terms “generalization” and “inheritance” are generally interchangeable. If you need to distinguish, generalization is the name of the relationship, while inheritance is the mechanism that the generalization relationship represents/models.

Inheritance can be defined as:

The mechanism by which more-specific elements incorporate the structure and behavior of more-general elements. (The Unified Modeling Language User Guide, Booch, 1999)

Single inheritance: The subclass inherits from only one superclass (has only one parent).
Multiple inheritance: The subclass inherits from more than one superclass (has multiple parents).

123 of 141

Example: Single Inheritance

One class inherits from another

Checking

Savings

Superclass (parent)

Subclasses

Generalization Relationship

Ancestor

Descendents

124 of 141

Example: Multiple Inheritance

A class can inherit from several other classes.

Use multiple inheritance only when needed and

always with caution!

FlyingThing

Animal

Horse

Wolf

Bird

Helicopter

Airplane

Multiple Inheritance

125 of 141

What Gets Inherited?

A subclass inherits its parent’s attributes, operations, and relationships
A subclass may:

Add additional attributes, operations, relationships
Redefine inherited operations (use caution!)

Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy

Inheritance leverages the similarities among classes

126 of 141

Example: What Gets Inherited

Truck

tonnage

GroundVehicle

weight

licenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1

Superclass (parent)

Subclass

generalization

size

127 of 141

What Is Realization?

One classifier serves as the contract that the other classifier agrees to carry out
Found between:

Interfaces and the classifiers that realize them

Elided form

Canonical form

Use-Case Realization

Use-Case

Use cases and the collaborations that realize them

Subsystem

<<subsystem>>

Interface

Class

Interface

128 of 141

What Are Stereotypes?

Stereotypes define a new model element in terms of another model element.
Sometimes, you need to introduce new things that speak the language of your domain and look like primitive building blocks.

Stereotype

Stereotypes can be defined as:

An extension of the basic UML notation that allows you to define a new modeling element based on an existing modeling element.

The new element may contain additional semantics, but still applies in all cases where the original element is used. In this way, the number of unique UML symbols is reduced, simplifying the overall notation.
The name of a stereotype is shown in guillemets (<< >>).
A unique icon may be defined for the stereotype, and the new element may be modeled using the defined icon or the original icon with the stereotype name displayed, or both.
Stereotypes can be applied to all modeling elements including classes, relationships, components, and so on.
Each UML element can have one stereotype only.
Stereotype uses include modifying code generation behavior and using a different or domain-specific icon or color where an extension is needed or helpful to make a model more clear or useful.

129 of 141

What Are Notes?

A comment that can be added to include more information on the diagram
May be added to any UML element
A ‘dog eared’ rectangle
May be anchored to an element with a dashed line

MaintainScheduleForm

There can be up to one

MaintainScheduleForm

per user session.

130 of 141

Tagged Values

Extensions of the properties, or specific attributes, of a UML element
Some properties are defined by UML

Persistence
Location (e.g., client, server)

Properties can be created by UML modelers for any purpose

PersistentClass�{persistence}

anObject : ClassA�{location=server}

In addition to the building blocks you can define using stereotypes, tagged values allow you to extend the properties of the basic UML building blocks (classes, packages, etc.).

Tagged values are placed within braces beneath the name of the element to which the property applies

Persistence is a predefined UML property that can be applied to attributes, classes and objects. It denotes whether or not the item’s state is retained when the instance is destroyed.

Location is a predefined UML property that can be applied to a model element. For classes and objects, it denotes what component the class resides in. For components, it denotes what node the component resides on.

Properties are often used for third-party tools, code generators, and to express language-specific or process-specific information.

Another example of a property is configuration management information like version number and status.

131 of 141

Class Relationships

Class diagrams may contain the following relationships:

Association
Aggregation
Composition
Generalization
Dependency
Realizes

OR

132 of 141

Association

Specifies peer-to-peer relationships between model elements

Navigability can be unidirectional or bidirectional

OR

133 of 141

Aggregation

Used to model a whole to part relationship between model elements

The part element can exist without the whole

Navigability can be unidirectional or bidirectional

OR

134 of 141

Composition

Aggregation with strong ownership

When the container is destroyed, all of its composite objects are destroyed

Navigability can be unidirectional or bidirectional

OR

135 of 141

Generalization

A relationship where one class shares the structure and behavior of one or more classes

Defines a hierarchy of abstractions where a subclass inherits a superclass

This is an “is a kind of” relationship

136 of 141

Dependency

A relationship in which one class uses another
Dependencies may exist between classes because:

A message is sent from one class to the other
One class is part of another's data
One mentions the other as a parameter to an operation

Following is a list of UML dependency stereotype relationships:

Binding: Used with template elements to identify that the contents of the template would be copied into the target element

Usage: A usage relationship in which one element requires another element for its implementation or operation

Abstraction: An abstraction relationship relates two elements that represent the same concept at two different levels of abstraction

Derive: Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type

Refine: Specifies a refinement relationship between the two elements or sets of elements. Used in the transformations from analysis to design and other such changes

Trace: Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models

Instantiate: A usage dependency among classifiers indicating that operations on the client create instances of the supplier

Package Import: A directed relationship that identifies a package whose members are to be imported into by a namespace

Element Import: A directed relationship that identifies an element to be imported into by a namespace

137 of 141

Realization

A specialized relationship where the client implements the suppliers specification

138 of 141

Review: Concepts of Object Orientation

What are the four basic principles of object orientation? Provide a brief description for each.
What is an object and what is a class? What is the difference between the two?
What is an attribute?
What is an operation?
What is an interface? What is polymorphism?

139 of 141

Review: Concepts of Object Orientation (continued)

What is a package?
What is a subsystem? How does it relate to a package? How does it relate to a class?
Name the four basic UML relationships and describe each.
Describe the strengths of object orientation
What are stereotypes?

140 of 141

Review: OOAD

OOAD :

Divides the problem into set of objects that interacts to solve the problem .

Why OOAD ?

1.As Software industries are Complex,labour Intensive i.e., too many people is doing too many things we can’t predict any ting.

2.To avoid redundancy (duplication of Component)

3.Obaject can help to increase modularity.

141 of 141

Example: Activity Diagram

Select

Course

Check

Schedule

Check

Pre-requisites

Assign to

course

Resolve

conflicts

Update

schedule

[ student added to the course ]

[ add course ]

Delete Course

[ delete course ]

[ checks completed ]

[ checks failed ]

Activity State

Synchronization Bar (Fork)

Guard Condition

Synchronization Bar (Join)

Decision

Concurrent threads

Transition