CS计算机代考程序代写 Java scheme data structure case study 300144 300888 Object Oriented Analysis

300144 300888 Object Oriented Analysis
2021-Session 1
Dr Mahsa Razavi
Object Oriented Analysis – 300144 1

Lecture 7b Mid-term Revision
References
Lecture 1~6 and specified readings
Practical 1~6 (tutorial questions and project exercises)
Object Oriented Analysis – 300144 2

Main Topics of Lecture
• Highlights of Lecture 1-6
• Sample questions for checking understanding
• Next stage of Unit teaching and learning
Object Oriented Analysis – 300144 3

Highlight of Lecture 1
• Introduction to OOA
• Positioning Object Oriented Analysis
• Object Oriented Paradigm
• Introduction to UML
Object Oriented Analysis – 300144 4

Why analysis?
• Analysis of a system requires
– when starting from scratch
– when responding to a change request during the maintenance of an existing system
– when replacing legacy systems with new ones • Its primary goal is to answer the question
– What is the problem that needs to be solved – the requirements?
Object Oriented Analysis – 300144 5

Requirement Analysis
• Requirements for a software system are initially generated during the analysis phase of software development and are, typically:
– simple statements of desired functional capabilities • “the system should allow its users to sort records by
priority”
– statements of non-functional capabilities
• “the system should support 10,000 simultaneous users” – statements of constraints that must be met
• “the system will be run cross platform”
Object Oriented Analysis – 300144 6

Requirement Analysis (Cont.)
• The problem? Experienced developers will tell you that
– Requirements are usually incomplete and unable to tell the
whole story
– Requirements are typically wrong: factually wrong or become obsolete
– Users thus the requirements they requested are misleading. Users may be non-technical and may not understand the range of options that could solve their problem.
– Most importantly, “requirements are always changing”. • Needs changes
• Better ideas
• Environment changes
Object Oriented Analysis – 300144 7

OO analysis, design and programming techniques provide you with powerful tools to handle changes of software.
Object Oriented Analysis – 300144 8

Object-oriented paradigm
• Objects are conceptual units that combine both data and behavior
– The data of an object is referred to by many names: attributes, properties, instance variables, etc.
– The behavior of an object is defined by its set of methods
• Objects inherently know what type they are. Its attributes allows it to keep track of its state. Its methods allow it to function properly
• OO Analysis & Design is centered around the concept of objects. It produces systems that consist of objects collaborating to fulfill the responsibilities (requirements) of the systems
Object Oriented Analysis – 300144 9

Object-Oriented A,D&P
• Object-Oriented Analysis (OOA) is method which examines requirements from the perspective of the classes and objects found in the vocabulary of the system.
• Object-Oriented Design (OOD) refers to any method that encompasses the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.
• Object-Oriented Programming is a method of implementation in which programs are organised as cooperative collections of objects, each of which represents instance of some class, and whose classes are related to one another via composition and inheritance relationships.
Object Oriented Analysis – 300144 10

Four Uses of the UML
SPECIFYING
VISUALISING
CONSTRUCTING
DOCUMENTING
Object Oriented Analysis – 300144 11

Four Uses of the UML (Cont.)
• VISUALISING: Use notations diagrams to represent graphic models of Requirements to design, e.g. business processes, solution and architecture
• SPECIFYING: Facilitate specification of some of the artifacts, eg. actors, use cases, classes, attributes, operations
• CONSTRUCTING: UML models can be directly connected to a variety of Programming Languages (C++, Java, VB, SmallTalk)
• DOCUMENTING: Documentation, e.g. Requirements, Architecture, Design, Project Plans, Tests, Prototypes etc. is used to enhance specifications and visual representations
Object Oriented Analysis – 300144 12

Highlight of Lecture 2
• Objects and classes
• Fundamentals of Object–Orientation
– Classification – Abstraction
– Inheritance
– Encapsulation – Polymorphism
Object Oriented Analysis – 300144 13

Class & Object
• A Class is a DEFINITION, a TEMPLATE, for the Objects
• NOTE: A Class is NEITHER an Individual Object, NOR simply a Collection of Objects
• A Class represents a Whole Set of Objects • Objects are instances of classes
Object Oriented Analysis – 300144 14

Class & Object Example
• Contract for property sale could be defined as a class (provide a template with certain format, including the terms and conditions of the sale and valuable information about the land)
• A property cannot be put on the market until a contract of sale has been drawn up. That contract linked with a particular property is an object of the defined class.
Object Oriented Analysis – 300144 15

The Star of OO Fundamentals: Cornerstone of Object-Orientation
CLASSIFICATION
Fundamentals of Object-Orientation: THE OBJECT
Object Oriented Analysis – 300144 16

OO Fundamentals
• Classification: groups things that have a common structure & exhibit a common behavior, the starting point of object analysis
• Abstraction: denotes the essential characteristics, from Objects to Class and from concrete classes to abstract classes.
• Inheritance: represents an ‘IS-A” relationship to enable significant code reuse
Object Oriented Analysis – 300144 17

OO Fundamentals (Cont.)
• Encapsulation: controls the accessibility of the features of the objects for information hiding in order to increase system robustness and code reusability
• Polymorphism: is able to refer to different derivations of a class in the same way, but getting the behavior appropriate to the derived class being referred to
Object Oriented Analysis – 300144 18

Case study: An example in Java
class Polymorph {
public static void main(String[] args) {
Polygon poly1, poly2, poly3; poly1 = new Rectangle(); poly2 = new Triangle();
poly3 = new Polygon(); poly1.set_values (4,5); poly2.set_values (4,5); poly3.set_values (4,5); System.out.print( poly1.area()
+“\n” + poly2.area()+ “\n“ + poly3.area()+ “\n”); }
}
20 10 0
object
polymor phism
class
encapsu lation
class Polygon {
protected int width, height;
public void set_values (int a, int b) {
width=a; height=b; } int area () {
return 0; } }
class Rectangle extends Polygon {
int area () {
return width * height; } }
class Triangle extends Polygon { int area () {
return (width * height / 2); } }
inheritance
Output:
Classification: many shapes could be grouped together Abstraction: defined a class Polygon from these shapes.
Object Oriented Analysis – 300144 Object Oriented Analysis, 300144
19

Highlight of Lecture 3
• Understanding Software Processes and Lifecycles
– Phases of Software Development
– Iterative and Incremental Development – The Unified Process
• Business Evaluation and Scoping Requirements
– Critical Requirement Analysis
– Package Diagrams As Sub-system
Object Oriented Analysis – 300144 20

Problems of Waterfall model
• Takes no account of evolutionary change
• System is characterised by a single function – a
questionable concept
• Based on functional mindset; data structure aspect often neglected
• Does not encourage reusability
Object Oriented Analysis – 300144 21

Iterative
• Updatethesameentity(e.g.ausecase,package or a class)
• Gradually refine the strategic and tactical decisions, converging on a solution that meets the user’s requirement and yet is simple, reliable and adaptable
• Validate and verify at predetermined steps
Object Oriented Analysis – 300144 22

Incremental
• Extend the current models by adding new entities /things to them
• Validate and verify at predetermined steps
Object Oriented Analysis – 300144 23

Unified Process
• Inception — approximate vision, business case, scope, vague estimates.
• Elaboration — refined vision, resolution of high risks, iterative implementation of core architecture, identification of most requirements and scope, more realistic estimates.
• Construction — iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
• Transition — beta tests, deployment.
Object Oriented Analysis – 300144 24

Rational Unified Process (RUP)
• A refinement of the unified Process created by the Rational Software Corporation, a division of IBM
• RUP Building blocks
– Main building blocks: Roles, Work products and Tasks
– Each iteration tasks are categorised into six engineering and three supporting disciplines
• Four Project Phases
• Six Best Practices
– Develop iteratively
– Management requirements – Use components
– Model visually
– Verify quality
– Control changes
Object Oriented Analysis – 300144 25

Roles in OO Analysis
The core role with business and technical skills
Object Oriented Analysis – 300144 26

Roles in OO Analysis (Cont.)
• The main responsibilities of a Business Analyst (BA) role within the problem space
– Models the requirements and explains the models to the designers
– Facilitates a dialogue between users and programmers
– Decomposes and ranks business objectives
– Verifies models
– Assists in organising tests
Object Oriented Analysis – 300144 27

Critical Requirements Analysis
• Good Requirement Analysis requires:
– Understanding the problem by breaking it down
– Prioritisation of the problem by evaluating the various sub-components of the problem
• A formal way of doing it is called Critical Requirement Analysis (CRA)
• CRA is vital for any analysis process
– Helps creation of manageable chunks (sub-systems) – Helps understand which chunks to develop first
Object Oriented Analysis – 300144 28

Package & Package Diagram
• Package: a Logical Collection of anything – of Classes; of Components;
– of Use cases etc. • Package diagram
– Provides clarity and understanding in a complex systems development
– Provides encapsulation and containment, support modularity
– Provide abstraction at multiple levels, from systems to classes in a component
Object Oriented Analysis – 300144 29

Critical Requirements Analysis
Put the detailed Business Objective like “To Enable e- Business in a Cost Effective Way “
Critical Performance Areas
Object Oriented Analysis – 300144 30

Package Diagram
Store Management System Package Diagram
Object Oriented Analysis – 300144 31

Highlight of Lecture 4
• Introduction to Actors
– Primary Users of the System
– Actors as Roles
– Actors as Devices and External Systems – Actor Documentation and Hierarchies
• Introduction to Use Cases – How to elicit good Use Cases
– How to create Use Case documentation
Object Oriented Analysis – 300144 32

Who can be an actor?
• The users (different roles) of the system are usually actors, Bank Teller, Manager, Customer
• External Devices may be actors, e.g. ATM, Card Reader, Printer
• External systems may be actors, e.g. PayPal
• Organisations may be actors, e.g. the government
• External to the system under design; taking initiative and/or interacting with the system
• Having a goal to achieve through a use case
Object Oriented Analysis – 300144 33

Potential list of actors in
Real Estate Agency Management System
A10-Client
A50-Staff
A80-Admin A70-Accountant
A90-Department of Home Affairs
A01-CardReader
A20-Buyer
A60-Agent
A95-Fair Trading NSW
A02-Printer
A30-Tenant
Public User
A75-Cashier A62-Consultant A64-Auctioneer
Staff User
A92-Real Estate Association NSW
Association
Hardware
Object Oriented Analysis – 300144
34

Actor hierarchy
Actor hierarchy in Hospital Management System
Abstract Actors
A10-Patient
A50-Staff
A20-PrivatePatient
versus Concrete Actors
A30-PublicPatient A60-Doctor
A70-Nurse
A80-Administrator
A62-Surgeon
A64-Physician
A75-LabAssistant
Object Oriented Analysis – 300144
35

Documenting Actors
• Actor Thumbnail
–
• Actor Type, Stereotype, Package
–
• Actor Description
–
• Actor Relationships
–
• Interface Specifications
–
• Author & History
–
• Reference Material
–
Object Oriented Analysis – 300144 36

Use Case Model
• The use case model is a tool analysing how different types of actors interact with the system to achieve their goals.
• The use-case model contains, as a minimum, the following basic model elements:
– Actors
– Use Cases
– Associations: the relationships between actors and use cases.
Object Oriented Analysis – 300144 37

Elicit Use Cases
• User Workshops
– Following the Joint Application Design style – Playing various Scenarios with Users
– Critical Requirements Analysis
• Formal and Informal Problem Statements • Knowledge of Domain Experts
• InterviewsandDiscussions
• Existing Systems (esp. Legacy)
• UseCasePatterns/PublishedLiterature/URLs
Object Oriented Analysis – 300144 38

Documenting Use Cases
• Use Case Thumbnail
–
• Use Case Description (Goal)
– • Stereotype and Package
– • Pre-Conditions
–
• Post-Conditions
–
• Actors
–
• Use Case Relationships
–
Object Oriented Analysis – 300144 39