IMS5006 - Information Systems Development Practices

IMS5006 - Information Systems Development Practices Object-oriented development approaches

System development approaches • three basic approaches to systems development: functional process decomposition is the basis data used by processes data-centred data is the stable basis process decomposition to define functions object-oriented data, process and behaviour combined in one object “objects” structure the application domain

The three perspectives of an information system Data Behaviour Process These three perspectives are encapsulated within the object.

Object-oriented development • Object-oriented development is built around the concept of modelling a system in terms of objects • An object encapsulates data, process and behaviour • Programming languages first, then analysis and design

Object-oriented and conventional approaches Conventional Database Process Object-oriented message Data Data Process Process message The emphasis is on object structure NOT on procedure structure

Object-oriented approaches • claimed benefits: • “seamless” development process • shift of development effort into analysis: conceptual models, not computer models • facilitates reuse • increased consistency between analysis, design and programming activities and models • more “natural” modelling of the problem domain • a “cleaner” design

Object-oriented development • An object is a thing (tangible or a concept) that has a well-defined role in the application domain • It has an identity, state and behaviour, and is something to which actions are directed • Its state encompasses its properties (attributes and relationships) and their values • Its behaviour is how it acts and reacts

Object-oriented development lifecycle • The OO lifecycle consists of progressively developing an object representation through 3 phases: analysis, design and implementation • In the early stages, the model is abstract, focusing on the external qualities of the application • As the model evolves, it becomes more detailed, focusing on how the system will be built and how it will function • Focus on front-end conceptual issues, not back-end implementation issues to avoid restricting design choices

Example object-oriented development lifecycle • Analysis: a model of the real-world application abstracting concepts describing what the system must do • Design: • System design: overall system architecture, subsystems (the context for physical design decisions) • Object design: add design detail e.g. internal data structures and algorithms, efficiency tuning, control, associations, module packaging • Implementation: implement design using programming languages, DBMS etc.

Object-oriented notations • Various object-oriented approaches have been proposed with various modelling notations in late 80s and early 90s e.g. Booch’s Booch Method, Rumbaugh et al’s Object Modelling Notation (OMT), Jacobson et al’s Object-oriented Software Engineering (OOSE), Coad and Yourdon’s Object-oriented Analysis (OOA) • Booch, Rumbaugh, Jacobson created a standard modelling language: Unified Modelling Language (UML) with version 1.0 released in 1997 • UML is widely-accepted standard for notation

Object-oriented modelling • Object class diagrams show the static structure of the application domain • Dynamic models represent the dynamic behaviour of the system • Operations represent the processes of the system and are triggered by events

Object modelling Object class: • group of objects with similar properties, behaviour, relationships and semantics • each object is in one class (an inherent property of the object) • objects have identity: objects are distinct even if all their attribute values and operations are the same • an object has a state and exhibits behaviour through operations that can examine or inspect its state • attribute: a data value held by objects in a class

Object modelling: class diagrams Class name Employee Ian Smith: Employee Employee id Employee name Employee address Employee D-O-B Employee id = 345 Employee name= Ian Smith Employee address = Caulfield, Vic Employee D-O-B = 4/10/64 Attributes Create new employee Change employee address Operations Object class diagram Object instance diagram

Object Modelling Concepts • abstraction • encapsulation • information hiding • polymorphism • inheritance • messaging

Abstraction in object modelling • hide detail to focus our attention on selected aspects of the system • Identification • Classification • Association • Generalisation • Aggregation

Classification • groups objects into classes • group objects based on similarity • inherently subjective • based on common attributes, behaviour or semantics for example: Polygon Objects Polygon Class Attributes: vertices border-colour fill-colour Operations: draw erase move

Association • means of establishing relationships between objects and object classes • group of conceptual links between objects • exists independently of objects • an association is a group of links with common structure and semantics • describes a set of potential links • inherently bi-directional • degree may be unary, binary, ternary etc.

Associations • often implemented as pointers • an association is independent of object classes Country Has-capital City Class Diagram name name Has-capital (City) (Country) Australia Canberra Instance Diagram Has-capital (City) (Country) Indonesia Jakarta

Association multiplicity indicates how many instances participate in the association is-assigned 0..1 0..1 parking permit employee one-to-one places 1 1..* customer sales order one-to-many enrols-in * * student subject many-to-many

Association ternary or higher order associations may be represented * * Project Language * Person (Project) Accounting System (Language) Cobol (Person) Mary (Project) CAD program (Language) C++

Generalisation • group object classes based on similarity • powerful abstraction technique for sharing similarities between classes • the class being refined is the “superclass” and each refined version is a “subclass” • each object can have many subclasses and many superclasses • sometimes called the “is-a” or “ako” relationship • the generalisation relationship may be specified by a discriminating attribute: the discriminator - the basis for the generalisation

Generalisation Connector Location Diameter Length displayLocation displayDiameter displayLength upstreamPipe connector type Free Flow Connector Pump Connector Network Connector openWaterSupply: {abstract} closeWaterSupply: {abstract} on off network connector type Service Outlet Valve Connector Permit Number openWaterSupply closeWaterSupply openWaterSupply closeWaterSupply

Inheritance • each subclass is said to inherit the features of its superclass • generalisation and inheritance are transitive across levels (ancestor and descendant) • each subclass not only inherits all features of its ancestors but adds further specific attributes and operations • inheritance is a major benefit of OO derived by implementing generalisation structures

Use of generalisation • both conceptual modelling and implementation • structuring classes based on similarity and difference • mechanism for inheritance • reuse of library classes

Disjoint and overlapping subclasses • Disjoint subclasses • each instance belongs to exactly one of the subclasses • E.g. Hourly-employee, Salaried-employee, Exempt-employee • indicated using braces in UML notation • Overlapping subclasses • each instance can belong to more than one subclass • e.g. graduate student, part-time student • indicated using braces in UML notation • Complete and incomplete subclasses • in UML notation this indicates whether additional subclasses are expected

Disjoint and overlapping subclasses • all students are either graduate or undergraduate • graduate students may hold one or both types of assistantships student {complete, disjoint} student level graduate student undergraduate student assistantship type {complete, overlapping} research assistant teaching assistant

Multiple Inheritance • where a class has more than one superclass and inherits from all parents • brings greater power to modelling but with loss of conceptual simplicity vehicle land vehicle water vehicle amphibious vehicle Car boat

Aggregation a grouping of component classes: • a “part-of” relationship representing components and assemblies • a special form of association where component classes do not have independent existence • transitivity: If A is-part-of B and B is-part-of C then A is-part-of C • anti-symmetric: If A is-part-of B then B is NOT part-of A

aggregation • relates an assembly class to ONE component class and allows us to specify multiplicity of each component Document Paragraph Sentence * *

Aggregation Car • • • 1-2 Electrical System Fuel System Drive System • • • Alternator Battery Coil aggregation and generalisation are commonly confused because of the hierarchical nature of both constructs

Aggregation and Generalisation • aggregation groups unlike instances (AND) • generalisation groups similar classes (OR) Network Pipe Connector Network Connector note: associations between Pipe and Connector have been omitted Pump Connector Free Flow Connector

Aggregation or Association? • For aggregation: • would you use the phrase “part of”? • are some operations on the assembly automatically applied to its parts? E.g. copy document so copy paragraphs • are some attribute values propagated from the assembly to its parts? E.g. car speed is 60 kph so car door speed is 60 kph • is there an intrinsic “asymmetry” to the association?

Encapsulation and Information Hiding • encapsulation and information hiding are often used interchangeably • they are related concepts but not the same • encapsulation is the containment of data and behaviour within an object • information hiding refers to the restricted interface an object offers to its internal workings: the object “hides” its internal implementation details - messages are required to access the object’s data or status

Object states and behaviour • the state of an object includes its properties (attributes and associations) and the values they have: it is determined by its attribute values and links • the behaviour of an object is how it acts and reacts: it is determined by its state and the operation being performed • an operation is a function or transformation that may be applied to or by an object in a class eg. COMPANY hire, fire, pay-dividend • a method is an implementation of an operation in class

Polymorphism • polymorphism = “many forms” • same operation may behave differently on different classes • An operation may have more than one method implementing it. • The correct method is selected based on the class and operation names. • an operator may have arguments (parameters) • methods for same operator must have same signature (number and type of arguments and type of result value) • behaviour of all methods for an operation should have consistent intent Picture file E.g. print Binary file

Operation notation • operations are listed in third part of class box • can include parameter list and result type • $ indicates an operation performed on the whole object Person Geometric Object Name: string Address: string Age: integer color: string position: point change-name change-address $createPerson move (delta:Vector) select (p:point): Boolean rotate (angle)

Dynamic modelling • Characterises temporal nature of system : describes changes to object classes and relationships over time • Deals with flow of control, interactions and sequences of operations in a system of concurrently active objects (message passing) • Shows object states and events, and operations as actions and activities • Use state diagrams and sequence diagrams

Scenarios and sequence diagrams • a scenario is a sequence of events that occurs during one particular execution of a system • E.g. consumer inserts coin ($1) interface displays amount ($1) letter selection button pressed (A) interface displays letter (A) number selection button pressed (1) interface displays number (1) food dispenser dispenses item (A1)

Sequence diagrams • show the sequence of events and the objects exchanging events food dispenser interface consumer consumer inserts coin ($1) interface displays amount ($1) letter selection button pressed (A) interface displays letter (A) number selection button pressed (1) interface displays number (1) food dispenser dispenses item (A1)

Example state diagram Waiting for letter money Inserted ButtonPressed (name) Idle [letter invalid] [letter valid] [digit invalid] Waiting for digit Dispensing [digit valid] ButtonPressed(name) • an event is received from the coin collector (moneyInserted) • the conditions indicate processing within the food dispenser object and not the state of the coin collector.

Messaging • Message passing is the means of communication between objects in an application • A message is passed when an object invokes one or more of another object’s operations to request information or some action • Can create an Object Communication Model • Form: operation name (arguments) E.g. Food Vending Machine amount paid? dispense(selection) Food selection panel Coin Slot Dispenser 100

UML (Uniform Modelling Language) Major analysis models in UML: • use cases: represent the functional requirements (the “what”) of the system • class diagrams: the static structure of data and operations that act on the data • state diagrams: represent how objects change their states in response to events • sequence diagrams:represent dynamics of of the interactions between objects

UML (Uniform Modelling Language) use case: • a complete sequence of related actions initiated by an actor (scenarios) • use cases may be extended by or used by another use case class diagram: • models the object classes and their attributes and operations state diagram: • models the states of an object and the events that cause state transitions sequence diagrams: • shows the passing of messages between objects

Coad & Yourdon’s OOA • five major activities: 1. find class-&-objects 2. identify structures 3. identify subjects 4. define attributes 5. define services • activities may be iterative, and there is no strict sequence

Coad & Yourdon’s OOA find class-&-objects: • identify object classes that form the core of the application identify structures: • organise the classes into generalisation (gen-spec) and aggregation (whole-part) hierarchies identify subjects: • group the object model into manageable subject areas to create subject layer and structure layer define attributes: • identify data elements of each class define services of each class: • a service is the operation or processes performed by the object in response to receipt of a message; service charts specify details

Advantages of object-oriented approaches • reduced semantic gap between models and problem domain • greater semantic richness particularly in the use of inheritance to explicitly represent commonality • re-usability is encouraged: not code libraries but object libraries • “seamless” development and increased consistencyof activities and models: traceability of objects • effect of changes to an object is more localised • message passing convention leads to easier interface descriptions between objects

References • AVISON, D.E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London. Chapter 21 • HOFFER, J.A., GEORGE, J.F. and VALACICH (1999) 2nd ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts. Chapter 12 • WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Modules A, B

IMS5006 - Information Systems Development Practices