Dr D. Greer, Queens University Belfast Four 1 Software Engineering Chapter 4: Software Design Unified Modelling Language.

Slides:



Advertisements
Similar presentations
Introduction to Object Orientation System Analysis and Design
Advertisements

Chapter 7 System Models.
An Introduction to Object Modeling
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Information System Design IT60105
Lecture 9 Object-Oriented Analysis
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
Department of Computing
Introduction To System Analysis and Design
Object-oriented analysis (OOA) techniques are used to (1) study existing objects to see if they can be reused or adapted for new uses, and (2) define new.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
COMP1007 Intro to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Intro to Requirements Analysis Object Oriented.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Lecture 4 Class Responsibility Collaboration Cards
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Requirements Analysis 9. 1 OO Concepts b509.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Object.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
The chapter will address the following questions:
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Introduction To System Analysis and design
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
1 CSc 131 Computer Software Engineering Fall 2012 Lecture # 7 Object-Oriented Design & UML Class Models.
1 A Student Guide to Object- Orientated Systems Chapter 4 Objects and Classes: the basic concepts.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Two Approaches to System Development
Introduction To System Analysis and Design
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
1 Object-Oriented Analysis Use Case Driven. 2 The outline method for OOA 1.Identify object classes within the problem domain 2.Define the behaviour of.
Faculty of Computer & Information Software Engineering Third year
Chapter 7 System models.
Slide 1 System models. Slide 2 Objectives l To explain why the context of a system should be modelled as part of the RE process l To describe behavioural.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Copyright Irwin/McGraw-Hill Object Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
Class diagram Used for describing structure and behaviour in the use cases Provide a conceptual model of the system in terms of entities and their relationships.
BCS 2143 Object Oriented Design Using UML. Objectives Objects Interactions Finding Classes Relationship Between Classes Attribute and Operation Class.
Design Model Lecture p6 T120B pavasario sem.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Object Oriented Analysis and Design Class and Object Diagrams.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
UML (Unified Modeling Language)
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
McGraw-Hill/Irwin© 2008 The McGraw-Hill Companies, All Rights Reserved Chapter 17 Object-Oriented Design and Modeling Using the UML.
Identification of Classes. Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements.
CHAPTER 6 OBJECT ANALYSIS.
1 Object-Oriented Static Modeling of the Banking System - III Lecture # 33.
Inf 43: Introduction to Software Engineering May 7, 2016.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Object-Oriented Static Modeling of the Banking System - I
OO Domain Modeling With UML Class Diagrams and CRC Cards
Abstract descriptions of systems whose requirements are being analysed
Presentation transcript:

Dr D. Greer, Queens University Belfast Four 1 Software Engineering Chapter 4: Software Design Unified Modelling Language Class Diagrams Learning Outcomes Be able to identify classes from a problem description Be able to create class diagrams from a description of a problem Understand and be able to apply the constructs of a class diagrams

Dr D. Greer, Queens University Belfast Four 2 Objects  The object-oriented approach to system development is based on the concept of objects that exist within a system’s environment.  Objects are everywhere  An object is something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behaviour.  The types of objects may include a person, place, thing, or event. An employee, customer and student are examples of person objects. A particular warehouse, office, building, and room are examples of place objects. A product, vehicle, piece of equipment, video tape, or a window appearing on a users display monitor are examples of thing objects. An order, payment, invoice, application, registration, and reservation are examples of event objects.

Dr D. Greer, Queens University Belfast Four 3 Attributes  In OO the term “data” refers to what are called attributes. Attributes are the data that represent characteristics of interest about an object. Example attributes for the person class called customer: »customer id, first name, last name, home address, work address, type of customer, home phone, work phone, credit limit, available credit, account balance, and account status. Each individual customer object is referred to as an object instance. »An instance (or object instance) of an object consists of the values for the attributes that describe a specific person, place, thing, or event.

Dr D. Greer, Queens University Belfast Four 4 Methods  AKA - Operations, behaviour, services  What is the “behaviour” of an object? Behaviour refers to those things that the object can do and which correspond to functions that act on the object’s data (or attributes). In OO, an object’s behaviour is commonly referred to as a method An object is solely responsible for carrying out any functions or behaviours that act upon its own data (or attributes). »For example, only YOU (an object) may CHANGE (behaviour) your HOME ADDRESS and TELEPHONE NO. (attributes about you).

Dr D. Greer, Queens University Belfast Four 5 Encapsulation ( Information Hiding)  Encapsulation is the packaging of several items together into one unit.  Both attributes and methods of the object are packaged together.  The only way to access an object's attributes is through that object’s behaviours.  No other object may perform that object’s operations  Separate external, visible aspects of an object from its internal implementation detail. This allows implementation to be changed without affecting the applications that use it.

Dr D. Greer, Queens University Belfast Four 6 Classes  A class is a set of objects that share common attributes and behaviour. For example, chair and table objects represent thing-objects that have some similar attributes and behaviour and could be classified as FURNITURE.  Using UML notation, classes are represented on an object model as a rectangle. The rectangle is divided into three sections. »The top section contains the name of the class. »The middle section contains the name of the common attributes of interest. »The lower section contains the common behaviour (or methods).

Dr D. Greer, Queens University Belfast Four 7 Class Lecturer Attributes Name Room no. Salary Methods Lecture() Mark() Publish()... Lecturer Fred Name=Fred Room 16J03 Salary=10000 Name=Laura Room 16J15 Salary=15000 Lecturer Laura Instances of the class Lecturer i.e. objects Classes - example

Dr D. Greer, Queens University Belfast Four 8 Classes and Objects Classname Class Name Attributes Methods/ functions/ behaviour OR  Document static structure of the system  Identify classes that should exist in system Identify candidate classes - noun identification and noun phrases Requirements specification required Can also be sought from Use- Case Flow of Events

Dr D. Greer, Queens University Belfast Four 9 Class associations  An class association is an relationship that exists between one or more objects/classes. For example, consider the object classes customer and order a CUSTOMER PLACES zero or more ORDERs »an ORDER IS PLACED BY one and only one CUSTOMERs  We graphically illustrate the association(relationship) between two classes as a connecting line. Verb phrases describe the relationship. All relationships are implicitly bi-directional Multiplicity defines the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Because all relationships are bi-directional, multiplicity must be defined in both directions for every relationship. Customer Order Places 0..*

Dr D. Greer, Queens University Belfast Four 10 Class name means one and only one 1 Class name means zero or more 0..* Class name means zero or one 0..1 Class name one or more 1..* Multiplicity

Dr D. Greer, Queens University Belfast Four 11 Associations Lecturer Course teaches An Association Lecturer Course teaches 0..* 1..* Is taken by

Dr D. Greer, Queens University Belfast Four 12  A class may be attached to an association rather than directly to another class.  Such a class is called an Association Class. It can have data attributes and behaviour just like any other class  Used to hold information on each occurrence of a relationship Supplier Part Supplies Date Contract

Dr D. Greer, Queens University Belfast Four 13 Another Example Student Module Is taking Mark: int Mark 1..* 6

Dr D. Greer, Queens University Belfast Four 14 Aggregation Association  objects/classes can be made up of other objects/classes. This relationship is called aggregation. It is also sometimes known as “whole-part” or “part-of” relationships.  For example, a BOOK object may contain several objects, including: COVER, TABLE OF CONTENTS, CHAPTER, and INDEX objects. The CHAPTER object contains PAGE objects, which in turn contain PARAGRAPH objects, which in turn contain WORD objects, and so forth.  By identifying aggregation relationships we can partition a very complex object and assign behaviours and attributes to the individual objects within it.  Multiplicity is also specified for aggregate relationships

Dr D. Greer, Queens University Belfast Four 15 Book Cover Table of Contents ChapterIndex Page Word Paragraph Aggregate Relationship

Dr D. Greer, Queens University Belfast Four 16 Inheritance  Inheritance implies that methods and/or attributes defined in an class can be inherited or reused by another class.  The approach that seeks to discover and exploit the commonalties between objects/classes is referred to as generalisation and specialisation. Generalisation/specialisation »attributes and behaviours that are common to several types of an object classes are grouped into their own class, called a supertype. Supertypes are generalisations of subtypes. Subtypes are specialisations of supertypes. »In the object class PERSON, STUDENT and PROFESSOR example, PERSON is referred to as a supertype (or generalisation class) whereas STUDENT and PROFESSOR are referred to as subtypes (or specialisation class).

Dr D. Greer, Queens University Belfast Four 17 walk talk sleep eat last name first name Person enrol Classification Student ID Student lecture rank Professor Supertype and Subtype relationship Between object classes

Dr D. Greer, Queens University Belfast Four 18 Example - Problem Statement for ATM Design the software to support a computerised banking network including both human cashiers and automated teller machines (ATMs) to be shared by a consortium of banks. Each bank provides its own computer to maintain its own accounts and process transactions against them. Cashier stations are owned by individual banks and communicate directly with their own bank computers. Human cashiers enter account and transaction data. ATM’s communicate with a central computer which clears transactions with the appropriate banks. an ATM accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash and prints receipts. The system requires appropriate record keeping and security provisions. The system must handle concurrent accesses to the same account correctly. The banks will provide their own software for their their own computers; you are to design the software for the ATM’s and the network. The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards. Ref: Raumbaugh et al. Object Oriented Modeling and Design, Prentice Hall, 1991.

Dr D. Greer, Queens University Belfast Four 19 The Class Diagram  Identifying classes From the nouns in the problem statement Eliminate the » redundant » irrelevant - those unrelated to the problem » Vague - ill-defined boundary, very broad in scope » attributes - things that describe an object » operations - things that manipulate objects » implementation constructs - extraneous to real world must be eliminated from analysis model, needed during design, but not now.

Dr D. Greer, Queens University Belfast Four 20 Object Modeling - Identifying Classes e.g. ATM system - Potential Object List SoftwareCentral Computer Banking NetworkCash Card CashierUser ATMCash ConsortiumReceipt Bank ComputerSystem AccountRecordkeeping provision Transactionsecurity provision Cashier stationAccess Account dataCost Transaction DataCustomer

Dr D. Greer, Queens University Belfast Four 21 Object Modeling -Keeping the right classes KEEP: Account, ATM, Bank, Bank Computer, Cash Cards, Cashier, Cashier Station, Central Computer, Consortium, Customer, Transaction

Dr D. Greer, Queens University Belfast Four 22 Object Modeling - Data Dictionary Prepare a Data Dictionary/Description of each class Account - a single account in a bank against which transaction can be applied. Accounts may be of various types, at least checking or saving. A customer can hold more than one account. ATM - a station that allows customers to enter their own transactions using cash cards as identification. The ATM interacts with the customer to gather transaction information, sends the transaction information to the central computer for validation and processing, and dispense cash to the user. Bank - ………….

Dr D. Greer, Queens University Belfast Four 23 ATM - Identify Associations Associations correspond to verbs in the problem statement Association = any dependency between two classes form verb phrases involving identified classes » consortium shares ATMs » bank provides bank computer » bank computer maintains accountsetc... or from implicit verb phrases » consortium consists of banks » bank holds accountetc... or from knowledge of the problem domain » cash card accesses accounts » bank employs cashiers

Dr D. Greer, Queens University Belfast Four 24 Initial Class Diagram

Dr D. Greer, Queens University Belfast Four 25 Further Specify the semantics of associations  Include Multiplicity  Qualifier or Qualified Associations Usually a name identifies an object within some context; most names are not globally unique. The context combines with the name to uniquely identify the object. A Qualifier distinguishes objects on the many side of an association. For example, a qualifier bankcode could be added to distinguish the different banks in a consortium. Each cash card needs a bank code so that transactions can be directed to the appropriate bank. Bank bankcode Consortium

Dr D. Greer, Queens University Belfast Four 26 Identifying Attributes and operations  Attributes Properties of an individual object Usually possessive phrases e.g. the colour of the car Identify from the problem description and domain knowledge  Operations Define ways in which objects interact

Dr D. Greer, Queens University Belfast Four 27 Identifying Attributes

Dr D. Greer, Queens University Belfast Four 28 More on UML Aggregation Rem : Aggregation is the “part-whole” relationship. It relates classes, representing parts (or components) to the whole (or assembly) class. In UML there are three types of aggregation: Normal Aggregation Shared Aggregation Composition aggregation

Dr D. Greer, Queens University Belfast Four 29 Normal Aggregation University Class diagram Faculty School * * 1 Lecturer works for Course takes 1..*

Dr D. Greer, Queens University Belfast Four 30 Shared Aggregation  With ‘Shared Aggregation’ the parts can be associated with many wholes.  To use the example of staff recruitment, a candidate may be associated with an ‘applicants’ whole and at the same time be part of a ‘short-listed’ whole and eventually an ‘offer-made’ whole. Each of these wholes is acting as a collection class for ‘applicants’. List Applicant * * ‘Shared’ aggregation if multiplicity > 1. Open diamond symbol for both shared and ‘normal’ aggregation

Dr D. Greer, Queens University Belfast Four 31 Shared Aggregation in UML  Lifetime of parts is not constrained by the lifetime of the container:  Parts can exist independently from the whole.  Shared aggregates form a network of parts rather than a tree structure. PersonTeam * * Sound Clip Remix * *

Dr D. Greer, Queens University Belfast Four 32 Composition Aggregation  The ‘whole’ owns the instances of the parts. Those instances cannot belong to any other instance of the whole.  Composition Aggregation forms a tree structure. Aircraft Door Landing Gear 2+ EngineWing Fuselage 2 1+  A part cannot belong to more than one whole

Dr D. Greer, Queens University Belfast Four 33 Don’t confuse aggregation and inheritance  Aggregation relates to Instances  Inheritance relates to Classes Plane CommercialPrivate Military 1 Engine Fuselage Wing 1+ 2

Dr D. Greer, Queens University Belfast Four 34 Object Modelling - Main Features User Address Member# Name Subscribe Unsubscribe External Reader Ext. Library Name Borrower Items Borrowed Maximum Loans Library Item No. Copies ShelfNo Status Title Issue Return Shelve Book Author ISBN Pub. Date Publisher CAL Package Distributor Recorded Media Course Text Borrows Aggregation Association Generalisation Object Class 0..*

Dr D. Greer, Queens University Belfast Four 35 Object Modelling - Main Features User Address Member# Name Subscribe Unsubscribe External Reader Ext. Library Name Borrower Items Borrowed Maximum Loans Library Item No. Copies ShelfNo Status Title Issue Return Shelve Book Author ISBN Pub. Date Publisher CAL Package Distributor Recorded Media Course Text Borrows Aggregation Association Generalisation Object Class 0..*

Dr D. Greer, Queens University Belfast Four 36 Encapsulation ( Information Hiding)  Encapsulation is the packaging of several items together into one unit.  Both attributes and methods of the object are packaged together.  The only way to access an object's attributes is through that object’s behaviours.  No other object may perform that object’s operations  Separate external, visible aspects of an object from its internal implementation detail. This allows implementation to be changed without affecting the applications that use it.

Dr D. Greer, Queens University Belfast Four 37 Messages and Message Sending  Object communication is by messages and message sending objects/classes interact or ‘communicate’ with one another by passing messages A message is passed when one object invokes another object’s method(behaviour) to request some action or information The object does not need to know how the receiving object is organised internally or how the behaviour is to be accomplished. Customer: William Jones display order status MESSAGE REQUEST add order modify order delete order display status etc. order number order date order status etc. Order order

Dr D. Greer, Queens University Belfast Four 38 Message Example  The name of the service requested by the calling object.  In practice, messages are often implemented by method/procedure/function calls Name = method name. Information = argument list.  Call the printing service associated with the object list to print the list L1 List L1; L1.Print (wide); Instance arguments Class Declaration method Instance

Dr D. Greer, Queens University Belfast Four 39 Polymorphism  Polymorphism means many forms  The same operation may behave differently on different classes.  It is essentially implemented through inheritance  In an OO language the language selects the correct method to implement an operation based on the name of the operation and the class of the object being operated on.  For example………..

Dr D. Greer, Queens University Belfast Four 40 Developing Class Diagrams - Summary oIdentify the main Use-cases and write down descriptions of these oIdentify the main elements of information which must be stored. oIdentify the main actors with which the system must interact. oIdentify objects and classes oIdentify associations between classes oCreating object model segments for each Use-case. oIdentify attributes for classes oMerge the object model segments to create an overall object model for the system oOrganise and simplify classes using inheritance oTest the object model and it’s relationships by performing walk- through using, for example, UML Sequence diagrams (Dynamic Modeling) oIterate and refine the models