A Gentle Introduction to Object-Oriented Software Engineering using UML Ugur Dogrusoz Associate Professor, Computer Eng Dept, Bilkent University, Ankara,

A Gentle Introduction to

Object-Oriented Software Engineering using UML

Ugur DogrusozAssociate Professor, Computer Eng Dept,Bilkent University, Ankara, Turkey

October 2010 Computer Eng Dept, Bilkent Univ

2

Software Engineering

Economies of all developed nations are dependent on software

More and more systems are software controlled

Software engineering is concerned with theories, methods and tools for professional software development

Expenditure on software represents a significant fraction of GNP in all developed countries

Ugur Dogrusoz Computer Eng Dept, Bilkent Univ

3

Software Costs

Often dominate computer system costsOn a PC often greater than the hardware cost It costs more to maintain than it does to

develop. For systems with a long life, maintenance costs may be several times development costs.

Software engineering is concerned with cost-effective software development.


4

Objectives

Appreciate Software Engineering SE is an engineering discipline: analyze, design, and

then implement Build complex software systems in the context of

frequent change

Understand how to produce a high quality software system within time

and budget while dealing with complexity and change

Acquire technical knowledge (main emphasis)Acquire managerial knowledgeUgur Dogrusoz Computer Eng Dept, Bilkent Univ

5

Why Object-Oriented Approach?As opposed to

procedural/functional/imperative approachEach object (modeled after its real-life equivalent) has

certain properties and responsibilities

OO software = interacting collection of objectsAbstraction, encapsulation, reuse,

maintenance


6

SE Methodologies

Every software needs Analysis (what to do) Design (how to do) Implementation & Testing

Process/algorithm used for development Waterfall Prototyping Iterative

Incremental XP (eXtreme Programming)

...Ugur Dogrusoz Computer Eng Dept, Bilkent Univ

7

Modeling

To understand real-life system to be automated (model it “as is”) software system to be built (model it “as you want it to

be”)

Same idea as blueprints for building bridges, houses, etc. layouts for manufacturing VLSI chips


8

Modeling

Textual (e.g. long textual descriptions or X3D) or visual/graphical (e.g. sketches or flowchart)

UML (Unified Modeling Language) is a visual modeling language to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development Helps you model both application and software domains!


9

OO Analysis & Design w/ UML


Requirements Elicitation & Analysis

System & Object Design

Implementation & Testing

Disclaimer: Do not expect every software to

be developed using the same methodology / process described here!

Not necessarily even when software is built in OO manner using UML!

10

OO Analysis w/ UML

Requirements elicitation: Definition of the system in terms understood by the

customer (“Requirements specification”)

Analysis: Definition of the system in terms understood by the

developer (Technical specification, “Analysis model”)


11

OO Analysis w/ UML


Problem Statement

Requirements Elicitation

Functional ModelNon-functional Req.

Analysis

Analysis Object Model Dynamic Model

Use Case Diagrams

System Design

State Diagrams

Sequence Diagrams

Class Diagrams

Activity Diagrams

12

OO Analysis w/ UML: sample project


College Registration System (CRS) The college would like a new client-server system to replace its much older system developed around mainframe technology. The new system will allow students to register for courses and view report cards from personal computers attached to the Internet. Professors will be able to access the system to sign up to teach courses as well as record grades.

The college will keep the existing course catalog database where all course information is maintained. This database is an Ingres relational database running on a DEC VAX. Fortunately the college has invested in an open SQL interface that allows access to this database from college’s UNIX servers. The legacy system performance is rather poor, so the new system must ensure that access to the data on the legacy system occurs in a timely manner.

At the beginning of each semester, students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites, will be included to help students make informed decisions.

The new system will allow students to select four course offerings (i.e., four primary course selections) for the coming semester. In addition, each student will indicate two alternative course choices, in case the student cannot be assigned to a primary selection. Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be canceled. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester (based on the number of credits that they are registered for). If a course fills up during the actual registration process, the student must be notified of the status before submitting the schedule for processing.

13

OO Analysis w/ UML: sample project


College Registration System (CRS) cntd At the end of the semester, the student will be able to access the system to view an electronic report card.

Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings. In addition, the professors will be able to record the grades for the students in each class.

In order to prevent unauthorized access to sensitive information such as student grades, the system must employ security measures.

14

Analysis: Requirements ElicitationBridging the gap between end user and

developer: Questionnaires: Asking the end user a list of pre-

selected questions Task Analysis: Observing end users in their

operational environment Scenarios: Describe the use of the system as a series

of interactions between a concrete end user and the system

Use cases: Abstractions that describe a class of scenarios


15

Analysis: Requirements ElicitationFunctional requirements

Students should be able to add/drop courses Professors should be able to view course rosters ...

Non-functional requirements All user inputs should be acknowledged within 1

second A system crash should not result in data loss

Constraints (pseudo-functional requirements) The implementation language must be Java


16

Analysis: use case scenarios

Cases in which a software system is usedUse case instances = scenariosExample scenario:

“A student logs on to CRS successfully. CRS displays a list of options, from which he selects to add a new course to take. He is presented with a list of available sections, from which he makes his choice and successfully adds the new course.”

instance of use case “Add Course”


17

Analysis: use case descriptionsFind all the use cases in the scenario that

specify all instances of “how to add a course”Describe each of these use cases in more

detail Participating actors Describe the entry condition Describe the flow of events Describe the exit condition Describe exceptions Describe nonfunctional requirements


18

Analysis: use case descriptionsUse case name: Add CourseParticipating actors: StudentEntry condition: The student has already

successfully logged on to CRSExit condition: The student has successfully

added the course to his/her schedule


19

Analysis: use case descriptionsMain flow of events

1. The student chooses to list the courses available to take

2. The system lists all such courses

3. The student makes a selection

4. The system verifies the student is eligible to take the course and displays the sections available

5. The student chooses a section

6. The system adds the student to section roster


20

Analysis: use case descriptionsAlternative flow of events

The student is not eligible to take the desired course (display appropriate message and go to Step 2)

All sections of the course are full (display appropriate message and go to Step 2)

The schedule of selected section conflicts with current schedule of the student (display appropriate message and go to Step 5)


21

Analysis: UML use case diagramsSummary of use case model: relationships

between actors and use cases


22

OO Analysis w/ UML


Problem Statement



Analysis


Use Case Diagrams

System Design

State Diagrams

Sequence Diagrams

Class Diagrams

Activity Diagrams

23

Analysis: object model

Identify objects (classes), properties (attributes) & operations (methods), and relations between objects (inheritance, composition,

etc.)


24


Application domain approach Ask domain experts to identify relevant abstractions

Syntactic approach (Abbot’s technique) Start with use cases Analyze the text to identify the objects Extract participating objects from flow of events

...


25

Analysis: object types

Entity Objects Represent the persistent information tracked by the

system (Application domain objects, also called “Business objects”)

Boundary Objects Represent the interaction between the user and the

system

Control Objects Represent the control tasks performed by the system.


26


Do a textual analysis (noun-verb analysis) Abbott’s Technique Nouns are candidates for objects/classes Verbs are candidates for operations

Their types Identify real world entities that the system needs to

keep track of (Course Entity Object) Identify real world procedures that the system needs

to keep track of (Scheduler Control Object) Identify interface artifacts (Add/Drop Form Boundary

Object).Ugur Dogrusoz Computer Eng Dept, Bilkent Univ

27


Abbott’s Technique “ ... Professors will be able to access the system to

sign up to teach courses as well as record grades ...” “... Course offerings will have a maximum of ten

students and a minimum of three students ...”


28

Analysis: UML class diagramsClass diagrams represent the structure of the

systemUsed during

analysis to model application domain concepts system design to model subsystems object design to specify the detailed behavior and

attributes of classes.


29

Analysis: object model for CRS


30

OO Analysis w/ UML


Problem Statement



Analysis


Use Case Diagrams

System Design

State Diagrams

Sequence Diagrams

Class Diagrams

Activity Diagrams

31

Analysis: dynamic model

Complements previous techniques of Application domain analysis General world knowledge and intuition Textual analysis of event flow in use cases (Abbot)

Describes components of the system w/ interesting dynamic behavior

Dynamic (vs. static) diagrams: Sequence diagrams: one per use case scenario State diagrams: one per object/class Activity diagrams: one per operation


32

Analysis: UML sequence diagrams


Math department agrees in a faculty meeting that Prof. Cengiz is to also teach a section of Math 201, which is offered as two sections. Assuming he’s already logged on, he chooses the option to add a new course to teach. He inputs Math 201. The system checks and finds out that the schedule of section 1 conflicts with other course(s) he is teaching. Luckily, section 2 is unassigned and nicely suits his schedule, for which Cengiz successfully signs up and logs out.

33

Analysis: UML state diagrams


Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be canceled.

States and transitions for Section objects/class

34

Analysis: UML activity diagrams


A student wants to add a new course. The student fills out the form by specifying the semester, the course to take (department and course number) and the section, to which the student would like to be added. Then, the student clicks the OK button. The system checks whether the particular section is still open for registration and the maximum count hasn’t been reached. If so, the system checks if the particular section of the added course fits the student’s schedule. Add operation is not allowed when there are any conflicts in the schedule. If there is no conflict, the system updates the database and simultaneously notifies the billing system of the change. It then displays an appropriate message. The student may, of course, cancel the add operation at any point during this process.

35

Analysis: user interface

User Interface Menus and screens/forms/dialogs/windows Navigational paths between menus and screens Mock-ups


36

Analysis: report organization

IntroductionCurrent systemProposed system

Overview Functional requirements Nonfunctional requirements Constraints (“Pseudo requirements”)

System models ...

GlossaryUgur Dogrusoz Computer Eng Dept, Bilkent Univ

Share w/ customer; forms a basis for a contract w/ customer!

37

Analysis: report organization

...System models

Scenarios Use case model Object model Dynamic models User interface

Glossary


Use Case Diagrams

Class Diagrams

Sequence, State & Activity Diagrams

For the sake of developers

38

Analysis: summary


Application domain is modeled to fully understand the real-life system “as is” (vs. “as you want it to be”)

Resulting model specifies exactly what the system is going to do is a contract between developer and customer is input to design phase

39

OO Design w/ UML

Analysis: focuses on the application domainDesign: focuses on the solution domain

The solution domain is changing very rapidly Design knowledge is a moving target

what vs. how


40

OO Design w/ UML


System Design

System Design Object Model

Subsystem Decomposition

Object Design


Class Diagrams

Design Goals

Implementation & Testing

Object Design Model

Software

Deployment Diagrams

Component Diagrams

Class Diagrams

41

MonolithicEvent-DrivenConc. Processes

7. Software Control

2. System DecompositionLayers vs PartitionsCoherence/Coupling

4. Hardware/Software MappingSpecial Purpose SystemsBuy vs BuildAllocation of ResourcesConnectivity

5. DataManagement Persistent ObjectsFilesystem vs Database

Access Control Listvs CapabilitiesSecurity

6. Global Resource Handling

8. Boundary Conditions

InitializationTerminationFailure

3. Concurrency

Identification of Threads

1. Design GoalsDefinitionTrade-offs

From analysis to system design

NonfunctionalRequirements

Functional Model

Functional Model

Dynamic Model

Object Model

Dynamic Model

42

Design: examples of design goals Reliability Modifiability Maintainability Understandability Adaptability Reusability Efficiency Portability Traceability of requirements Fault tolerance Backward-compatibility Cost-effectiveness Robustness High-performanceUgur Dogrusoz Computer Eng Dept, Bilkent Univ

Good documentation Well-defined interfaces User-friendliness Reuse of components Rapid development Minimum number of errors Readability Ease of learning Ease of remembering Ease of use Increased productivity Low-cost Flexibility

43

Design: typical tradeoffs

Functionality v. UsabilityCost v. RobustnessEfficiency v. PortabilityRapid development v. FunctionalityCost v. ReusabilityBackward Compatibility v. ReadabilitySpace v. Speed


A low cost system does not do mucherror checking (e.g. 5.00 or 5,00 Euros).

It’d be very difficult to build a real-time game that is portable.

44

Design: subsystem decompositionSubsystem

Collection of classes, associations, operations, events and constraints that are closely interrelated with each other

Great way to handle complexity


45

Design: subsystem decompositionService

A set of named operations that share a common purpose

The origin (“seed”) for services are the use cases from the functional model

Services are defined during system design


46

Design: subsystem interface object In a good design

The subsystem interface object describes all the services of the subsystem interface

Realized with the Façade design pattern


«PackageClass3»

«PackageClass2»

«PackageClass1»«Facade»

47

Design: layers and partitions


F:SubsystemE:Subsystem G:Subsystem

D:SubsystemC:SubsystemB:Subsystem

A:Subsystem Layer 1

Layer 2

Layer 3

Partition 1 of Layer 3

Partition 2of Layer 3

Partition 3of Layer 3

48


A layer is a subsystem that provides a service to another subsystem with the following restrictions: A layer only depends on services from lower layers A layer has no knowledge of higher layers

A layer can be divided horizontally into several independent subsystems called partitions Partitions provide services to other partitions on the

same layer Partitions are also called “weakly coupled” subsystems.


49

Design: relationships bw subsystemsLayer A “depends on” Layer B (compile time)

Example: Build dependencies (make, ant, maven)

Layer A “calls” Layer B (runtime) Example: A web browser calls a web server

Mapping of layers to processors is decided during the software/hardware mapping!

Partition relationship The subsystems have mutual knowledge about each

other. A calls services in B; B calls services in A (Peer-to-Peer)

UML convention: dashed vs. solid linesUgur Dogrusoz Computer Eng Dept, Bilkent Univ

50



F:SubsystemE:Subsystem G:Subsystem

D:SubsystemC:SubsystemB:Subsystem

A:Subsystem Layer 1

Layer 2

Layer 3

Layer Relationship“depends on”Partition

relationship

Layer Relationship

“calls”

51

Design: subsystem decompositionGoal: Reduce system complexity while

allowing changeCoherence measures dependency among

classes High coherence: The classes in the subsystem

perform similar tasks and are related to each other via many associations Achieved if most of the interaction is within subsystems, rather

than across subsystem boundaries

Low coherence: Lots of miscellaneous and auxiliary classes, almost no associations


52

Design: subsystem decompositionGoal: Reduce system complexity while

allowing changeCoupling measures dependency among

subsystems High coupling: Changes to one subsystem will have

high impact on the other subsystem Low coupling: A change in one subsystem does not

affect any other subsystem achieved if a calling class does not need to know anything

about the internals of the called class (information hiding)


53

Design: subsystem decompositionSubsystem decomposition

Identification of subsystems, services, and their association to each other (hierarchical, peer-to-peer, etc)

Architectural style A pattern for a subsystem decomposition Examples: client/server, peer-to-peer, repository,

model/view/controller, three-tier, four-tier, service-oriented architecture (SOA), pipes and filters

Software architecture Instance of an architectural style


54

Design: client/server architectural style One or many servers provide services to instances of

subsystems, called clients Each client calls on the server, which performs some

service and returns the result The clients know the interface of the server The server does not need to know the interface of the

client The response in general is immediate End users interact only with the client


Client

Server

+service1()+service2()

+serviceN()

**

provides services for

requests services from

55

Design: client/server architectural styleDesign goals for client/server architectures:

Service Portability Location-Transparency High Performance Scalability Flexibility Reliability


56

Design: subsystem decompositionFrom objects to subsystems, taking into

account the non-functional requirementsNo single/fixed algorithm Initial decomposition usually derived from

functional requirements; constantly revised as new issues addressed

The objects and classes from the object model could be the “seeds” for the subsystems


57

Design: concurrency

Nonfunctional requirements to be addressed: performance, response time, latency, and availability.

Two objects are inherently concurrent if they can receive events at the same time without interacting

Inherently concurrent objects can be assigned to different threads of control

Objects with mutual exclusive activity could be folded into a single thread of control


58

Design: problems w/ threads


:BankAccountc1:Customer c2:Customer

:WithdrawCtrl :WithdrawCtrl

getBalance()

200

withdraw(50)

setBalance(150)

getBalance()

200

withdraw(50)

setBalance(150)

computeNewBalance(200,50)


Assume: Initialbalance = 200

Final balance = 150 ??!

Thread 1

Thread 2

Should BankAccount be another Thread ?

59

Design: synchronizing threads


c1:Customer c2:Customer :BankAccount:WithdrawCtrl

getBalance()

200

withdraw(50)

setBalance(150)


Initialbalance = 200

withdraw(50)

Single WithdrawCtrlInstance

Synchronized method

Endbalance = 100

60

Design: identifying threads

To identify threads for concurrency we ask the following questions: Does the system provide access to multiple users? Which entity objects of the object model can be

executed independently from each other? What kinds of control objects are identifiable? Can a single request to the system be decomposed

into multiple requests? Can these requests and handled in parallel? (Example: a distributed query)


61

Design: implementing threadsPhysical concurrency is provided by

multiprocessors and computer networksLogical concurrency is provided by threads

packages.


62

Design: HW/SW mapping

This system design activity addresses two questions: How shall we realize the subsystems: with hardware

or with software? How do we map the object model onto the chosen

hardware and/or software? Mapping the Objects:

Processor, Memory, Input / Output

Mapping the Associations: Network connections


63

Design: mapping objects onto HWControl Objects -> Processor

Is the computation rate too demanding for a single processor?

Can we get a speedup by distributing objects across several processors?

How many processors are required to maintain a steady state load?

Entity Objects -> Memory Is there enough memory to buffer bursts of requests?


64

Design: mapping objects onto HWBoundary Objects -> Input / Output Devices

Do we need an extra piece of hardware to handle the data generation rates?

Can the desired response time be realized with the available communication bandwidth between subsystems?


65

Design: associations / connectivityDescribe the physical connectivity

Describes which associations in the object model are mapped to physical connections.

Describe the logical connectivity (subsystem associations) Associations that do not directly map into physical

connections. In which layer should these associations be

implemented?


66

Design: UML diagrams

Deployment Diagram: Once we have done

Subsystem decomposition Concurrency Hardware/Software Mapping

Illustrates the distribution of components at run-time. Deployment diagrams use nodes and connections to

depict the physical resources in the system.

Component Diagram: Illustrates dependencies between components at

design time, compilation time and runtime.


67

Design: UML component diagrams


68

Design: UML deployment diagrams


69

Design: data management

Some objects need to be persistent: Values for their attributes have a lifetime longer than a

single execution

A persistent object can be realized with: Filesystem:

If the data are used by multiple readers but a single writer

Database: If the data are used by concurrent writers and readers.


70

Design: data managementHow often is the database accessed?

What is expected query rate? The worst case? What is the size of typical and worst case requests?

Do the data need to be archived?Should the data be distributed?

Does the system design try to hide the location of the databases (location transparency)?

Is there a need for a single interface to access the data? What is the query format?

Should the data format be extensible?


71

Design: data management

UML object models can be mapped to relational databases Each class is mapped to its own table Each class attribute is mapped to a column in the

table An instance of a class represents a row in the table One-to-many associations are implemented with a

buried foreign key Many-to-many associations are mapped to their own

tables

Methods are not mappedUgur Dogrusoz Computer Eng Dept, Bilkent Univ

72

Design: global resource handlingDiscusses access controlDescribes access rights for different classes

of actorsDescribes how objects guard against

unauthorized access


73

Design: global resource handling In multi-user systems different actors usually

have different access rights to different functionality and data

How do we model these accesses? During analysis we model them by associating

different use cases with different actors During system design we model them determining

which objects are shared among actors.


74

Design: global resource handlingNeed authentication? Authentication scheme?

User name and password? Access control list Tickets? Capability-based

User interface for authentication?Need a network-wide name server?How is a service known to the rest of the

system? At run time? At compile time? By Port? By Name?


75

Design: software control Implicit vs. explicit control,

centralized vs. decentralized controlCentralized control:

procedure-driven, control resides within program code. event-driven: control resides within a dispatcher calling

functions via callbacks.

Decentralized control control resides in several independent objects (e.g.

Message based system, RMI). possible speedup by mapping the objects on different

processors, increased communication overhead.


76

Design: boundary conditions

Initialization The system is brought from a non-initialized state to

steady-state.

Termination Resources are cleaned up and other systems are

notified upon termination.

Failure Possible failures: bugs, errors, external problems Good system design foresees fatal failures and

provides mechanisms to deal with them.


77

Design: patternsThe recurring aspects of designs are called

design patterns A pattern is the outline of a reusable solution to a

general problem encountered in a particular context Many of them have been systematically documented

for all software developers to use

A good pattern should Be as general as possible Contain a solution that has been proven to effectively

solve the problem in the indicated context

Studying patterns is an effective way to learn from the experience of others


78

Design: Composite design patternContext:

Objects in a hierarchy can have one or more objects above them (superiors), and one or more objects below them (subordinates). Some cannot have any subordinates

Problem: How do you represent a hierarchy of objects, in which

some objects cannot have subordinates?

Forces: You want a flexible way of representing the hierarchy

that prevents certain objects from having subordinates All the objects have common properties/operations


79

Design: Composite design patternSolution:


«subordinate»*«Node»

«SuperiorNode»«NonSuperiorNode»

0..1

* supervises

Manager

Employee

TechnicianSecretary

0..1

* contains

Directory

FileSystemItem

File

0..1

80

Design: Singleton design patternContext:

It is very common to find classes for which only one instance should exist (singleton)

Problem: How do you ensure that it is never possible to create

more than one instance of a singleton class?

Forces: The use of a public constructor cannot guarantee that

no more than one instance will be created The singleton instance must also be accessible to all

classes that require it


81

Design: Singleton design patternSolution:


82

Design: UML class diagrams


83

Design: report organization

Introduction Purpose of the system Design goals Definitions, acronyms, and abbreviations Overview

Current software architecture (if any)…


84


…Proposed software architecture

Overview Subsystem decomposition Hardware/software mapping Persistent data management Access control and security Global software control Boundary conditions

Subsystem services…Ugur Dogrusoz Computer Eng Dept, Bilkent Univ

85


…Low-level design

Object design trade-offs Interface documentation guidelines

Collections have an iterator() method returning an Iterator

Definitions, acronyms, and abbreviations

PackagesClass interfacesGlossary & references


86

CASE tools

Requirements managementCASE w/ UMLConfiguration management IDE Issue trackingProject scheduling ...


87

Measuring quality of softwareProduct quality

conformance to requirements

scalability correctness completeness absence of bugs fault-tolerance extensibility /

maintainability documentation


Source code quality readability ease of maintenance,

testing, debugging, fixing, modification and portability

low complexity low resource consumption number of compilation or lint

warnings robust input validation and

error handling

88

Measuring quality of OO softwareExtensibility / maintainability

low coupling/high coherence reuse (inheritance/composition) information hiding/encapsulation polymorphism design patterns

Documentation capturing requirements (what to build) architecture/design (how to build)

design decisions


89

References

OOSE, Using UML, Patterns, and Java, 3rd Edition by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2010

Software Engineering by Ian Sommerville, Addison Wesley, 2010

Object-Oriented Software Engineering by Timothy C. Lethbridge and Robert Laganiere, McGraw-Hill, 2001

Wikipedia, http://en.wikipedia.org


Documents

A Gentle Introduction to Object-Oriented Software Engineering using UML Ugur Dogrusoz Associate Professor, Computer Eng Dept, Bilkent University, Ankara,