CS计算机代考程序代写 compiler Java algorithm case study database gui 300144

300144
Object Oriented Analysis
Dr Mahsa Razavi
1

Lecture 8
Interface Specifications Prototyping and Emerging Technologies
References
Bhuvan’s book Chapter 8 Boock’s Book Chapter 9
2

Things in Last Lecture
• Major Ingredients of Sequence Diagram
• Importance and Relevance of Sequence Diagram in
Analysis
• InteractionOverviewDiagrams
• StateMachineDiagramsinDynamicModelling
• What are other Diagrams:
• Package Diagrams • Use Case Diagrams • Activity Diagrams • Class Diagrams
3

Main Topics of Lecture
• Understanding what are interface specifications
• Relating interface specification to use cases
• Creating Graphic User Interface (GUI)
Specifications for Actor-Use Case Interfaces
• Creating User Interface (UI) Navigation Maps (Flow diagrams)
• Prototyping – its importance and relevance in problem Space
4

Interfaces
• Interfaces are the areas of the system that enable it to interact with external entity.
• Interfaces do not contain any business logic in them.
• Interfaces are responsible for sending/receiving information to/from the outside of the system.
• There are four most generic groups of system interface.
5

SYSTEM
Users
Interfaces (Cont.)
Printers
Devices Other Systems
• User Interfaces – are the most common mechanisms to display and receive information from the users.
• Printer Interfaces – provide the printed output for the users.
• Device Interfaces – are interfaces of the system to any external devices, e.g. key card readers, speakers, etc
• External system interfaces – are interfaces that enable interaction of the system with other systems and databases
6

Specifying Interfaces
• Specify what is required for the actor to interact with the system
• User interface specification includes:
– Name: identify the interface
– Descriptive information: understand the usage of the interface, e.g. Actors, Use cases, short description
• Note:
– No UML diagram provides precisely with interface
specifications
– It is essential to specify the user interfaces, prototype them and get the user feedback.
7

Template of an Interface
Interface Identifier

Actors:

User Cases:

Short Description:

8

Graphic User Interface
• GUIs are the graphic images that display and receive information to and from the actors (users) of the system.
• GUIs are also known as screens, forms, pages, etc.
• Modern user interfaces are sufficiently detailed and complex enough to be considered as systems in their own right.
→ required careful design and development
9

Graphic User Interface (Cont.)
• A good GUI analysis and design follow three principles of quality:
– Syntactical correctness – requiring all user interfaces to be able to display and receive information correctly
– Semantic meaning – user interfaces should be meaningful to the user in helping her achieve the purpose for which he/she is using the system
– Aesthetic symmetry – user interfaces should be aesthetically pleasing to the users.
10

User Interface Example
Tuesday – 23-04-2019 – 11:00 am
Platform – Windows 10 Version: 1.0
© 2019 MethodScience
11

User Interface for PatientRegistrationForm
Interface Identifier: UI10-PatientRegistrationForm
Actors: A10-Patient, A80-Administrator
Use Cases: UC10-RegistersPatient, UC12- MaintainsPatientDetails
Short Description: This user interface enables the creation of registration details for a first-time patient at the hospital. This same user interface should also enable maintenance of a patient’s registration details. Specific registration details are found in the respective use cases.
12

User Interface for PatientRegistrationForm (Cont.)
11-05-2020
13

User Interface for PatientMedicalProfileForm
Interface Identifier: UI12- PatienMedicalProfileForm
Actors: A60-Doctor
User Cases: UC14-CreatesPatientMedicalProfile,
UC16-UpdatesPatientMedicalProfiles
Short Description: This user interface enables the creation of a medical record for a first time patient at the hospital. This same user interface should also enable maintenance of a patient’s medical profile details. Specific medical profile data are found in the respective use cases.
14

User Interface for PatientMedicalProfileForm
1213-054-202109
15

User Interface for CalendarMaintenanceForm
16

User Interface for BillPayInternetForm
17

User Interface Navigation
• User interface flow diagrams (or also called storyboards, screen navigation diagrams or navigation maps)
• Help to model the high-level relationships between major user interface elements
• Provide opportunity to inspect the usability aspect of the entire system
• Understand and develop User Interface flow diagrams by organise use case descriptions in a series of numbered steps
18

UI Flow Diagram for A50-Staff
UI20 CalendarMaintenanceForm
UI00 LogInForm
Other interfaces will be added here, as more use cases, activity diagrams and sequence diagrams are reviewed …..
• User Interface flow diagram for actor A50-Staff
• The Staff actor has to login to the HMS system using interface UI00-LoginForm
• The Staff actor then use UI20- CalendarmaintenanceForm to update his calendar
• This flow is derived form the pre-condition of use case UC22-MaintainsCalendar
19

UI Flow Diagram for A60-Doctor
UI00 LogInForm
UI11 PatientSearchForm
UI12- PatientMedicalProfileForm
UI20 CalendarMaintenanceForm
UI30 ConsultationBookingForm
Other interfaces will be added here, as more use cases, activity diagrams and sequence diagrams are reviewed …..
For updating Patient’s medical profile
20

UI Flow Diagram for A70-Patient
UI000 LogInForm
UI110 DoctorSearchForm
UI140 UpdatePersonalRecord
UI120 ConsultationBookingForm
UI130 PayBill
A different Login Form for Patients
21

Prototyping
Functional, Technical, Architectural
22

Prototyping
Process-component for prototyping
Interface Prototype can be part of Functional Prototype
Functional Prototype
Interface Prototype
Technical Prototype
Architectural Prototype
User/Project Sponsor
Prototyper (Programmer, Business Analyst, System Architect)
Project Manager/ Quality Manager
Providing Feedback
Purpose Identification
Functional Prototype Creation
Technical Prototype Creation
Set Expectations
Architectural Prototype Creation
Prototypes may not be created in this sequence. They can also be subject to quality checks
The User/Business Sponsor will benefit by looking at all prototypes to enhance their understanding and refine their scope of the project
Prototypes will influence requirements models, in task Model, System Design, and System Architecture
23

Functional Prototype
• Used in Model Of Problem Space (MOPS)
• Deals with the functional aspect of the system
• Relevant to end-users specifying the system
• Helps find missing requirements
• Helps in managing expectations
• May not be an executable
• Can be a collection of mock-up screens (as early as possible, as well as navigation of screens at user interface)
24

Technical Prototype
• Used in Model Of Solution Space (MOSS)
• Deals with the technical feasibility of system
– Will the language compiler handle the types of classes being created (composition or multiple inheritance)?
– A third-party component meets the requirements?
– How many records can this DB hold?
– What is the likely response time of this algorithm with million (dummy) records?
• Possible areas covered include: database, operating system, lower-level system design
• Would usually involve an executable
25

Architectural Prototype
• Used in Model Of Background Space (MOBS)
• Deals with the architectural feasibility of system
– Will the new database fit in with the existing environment (existing OS, DB etc.)?
– What is the future of the short listed web application server? Is it scalable?
• Possible areas covered include: middleware, architecture, database, security
• Would usually involve an executable
26

Prototype and Quality
• Used in all three spaces (MOPS, MOSS, MOBS) to ensure the quality of the system
– Functional Prototypes: used for engineering “quality” requirements in the problem space
– Technical Prototypes: used for modelling operational and other language-specific requirements
– Constraints placed the architecture of the enterprise is of immense interest to the analyst
• Require a continuous feedback loop between prototyping and original requirements
27

Prototype and Quality (Cont.)
• More details about prototyping
– Prototype helps extract requirements from the user, help identify potential pitfalls of the solution and ascertain the likely performance and volume
– Prototype should not be directly converted into a complete solution
– Balance of prototyping process:
1) too little → not extract enough requirements or test the technology sufficiently
2) too much → become a prototyping project
28

Activities and tasks in prototyping
Purpose Identification
Functional Prototype Creation
Technical Prototype Creation
Identify Purpose Prototype
Understand Purpose
Create GUI Prototype
Demonstrate and Execute Prototype
Create Prototype for Use Case
Sketch Interface
Write Code for Prototype
Analyze Results
Providing Feedback
Provide Feedback to Prototyper
Execute Prototype
Map to Project Goals
Architectural Prototype Creation
Set Expectation
Create Architectural Prototype
Provide Feedback to Steering Committee
Explain Purpose of Prototype
Control Prototype Demo
Understand and Execute Prototype
Provide Feedback to Modeler
Execute Prototype
Get Feedback
29

User Interface Prototyping for ATM
30

Class Diagram for the ATM system
http://www-labs.iro.umontreal.ca/~keller/Suip/bookChapter.pdf
31

Use Case Diagram for the ATM system
Note: the three <> should be replaced by <> and broken arrow lines
32

33
Class ATM

State Machine Diagram of the ATM Object
Regular Withdraw
34

State Machine Diagram of the ATM Object
Balance Error
35

State Machine Diagram of the ATM Object
Integration of Two Scenarios
36

Menu generated for the interface object ATM
37

Prototype UI
38

Prototype UI (Cont.)
39

Workbook Exercises
• For The Class Room!!
40

Workbook Exercises
1. Identify an interface for each of the major use cases documented in Chapter 4 (Bhuvan’s book).
2. Specify details of those interfaces by using the template discussed here.
3. Identify dependencies or flows between interfaces.
4. Draw a UI-flow diagram for user interfaces for one actor.
5. Identify and specify TWO device interfaces for the hospital system. (Device interfaces may include printer, card readers for security ID cards, barcode readers for inventory, etc.)
6. Discuss the specifications of External Interfaces/Systems.
41

Use Case – MakeNewBooking
Use Case Thumbnail: UC10-MakeNewBooking
Actors: A20-OnlineCustomer, A130-OnlineCustOperator, A00-
Printer
Use Case Description: this use case deals with booking a new travel online. A20-OnlineCustomer selects destinations, date and time and any associated activities, such as car rental, hotel, etc. A20-OnlineCustomer also need to log onto the system in order to confirm the booking and pay the fee. The customer operator must double check the booking and contacting the customer if required. A receipt will be given to the customer.
Pre-Conditions: N/A.
Post-Conditions: Booking is issued with the receipt.
42

User Interface for MakeNewBooking
Interface Identifier: UI10-

Actors:

User Cases:

Short Description:

43

User Interface for MakeNewBooking
Interface Identifier:
UI10-MakeNewBooking
Actors:
A20-OnlineCustomer, A130-OnlineCustOperator, A00-Printer
User Cases:
UC10-MakeNewBooking, UC101-ValidateNewBooking, UC15- MakeAssociateBooking
Short Description:
This user interface enables the creation of a new booking for a customer online. This same user interface should also enable the customer operator to validate the booking information. Its interface might also be used when an associate booking (e.g. car rental, hotel, etc.) is made.
44

User Interface (Mock-up Screen) for MakeNewBooking
45

User Interface (Mock-up Screen) for MakeNewBooking (Cont.)
• With the associate booking being selected, external system interfaces like Car Rental, Accommodation and/or Tour could be displayed
• At the end, a confirmation page of the booking and the payment page will be displayed and printed (printer interface)
46

Real Estate Agency UI
47

UI Flow for Customer
Customer provides contact details in UI100, 120 and 140
UI100 SellPropertyForm
UI102- PropertyDetailsForm
UI10 WelcomePage
UI120 BuyPropertyForm
UI122- SearchPropertyForSale
UI140 RentPropertyForm
UI142- SearchPropertyForRent

UI Flow for Solicitor
Solicitor (and other business partners) may have a different Login Form
UI50 LoginForm
UI500 SearchPropertyForm
UI502-LegalAdviceForm
A home loan officer could process a home loan application through the interfaces here.

Emerging Technologies
Object Oriented Analysis – 300144 50

Modeling Domains for Emerging Technologies
Domains being Modeled?
Applications Contents Interfaces Security
Networks
Models
Emerging Technologies
Web Services
Mobile Technologies
Bio- Informatics
Nano- Technologies
UML MDA
Object Oriented Analysis – 300144
51

Understanding OMG’s Model Driven Architecture (MDATM) in Application Design
Business View
Model
Platform Specific Component View (PSM)
Platform Independent View
(PIM)
Driven
Architecture
MDA enables application of PIM (Platform Independent Model) to PSM (Platform Specific Model) Resulting into essentially an open-ended multi-tiered Architecture
Object Oriented Analysis – 300144
52

Web Services and Cloud Computing
53

Web Service Modelling
Web service: A software system designed to support machine to machine interaction over a network
Object Oriented Analysis – 300144 54

Web Services – A Practical Scenario
Interactive Wireless Client Programmatic Client Interactive Desktop Client
Virtual HMS (Portal)
CLIENT INTERFACE
SERVICE PROVIDER INTERFACE
Pharmacies
Registry
Accounting Services (VISA)
Registration & Discharge Services
Private Medical Insurance Company
Laboratories (Pathology)
Object Oriented Analysis – 300144 55

Web Services – a Unified View to the Client (Patient)
Web Services bring together Data and Information from Various Domains resulting in a Unified View to the Client (Patient) of Web Services
Patient Personal Smart Client Application
Doctor Schedule & Booking
Internet
Medical Insurance
Hotel Availability & Booking
Personal Schedule
Object Oriented Analysis – 300144
56
Directory

Web Services – A UML Meta Model (HMS Example)
Web Services
publish
locate UDDI (Universal Description, Discovery and Integration) is a platform-independent, Extensible Markup Language (XML)-based registry for businesses worldwide to list themselves on the Internet and a mechanism to register and locate
ervice applications
<> Registration
WS based on SOA (Services Oriented Architecture), software modules published as services, located on either internal servers or internet
<> UDDI
The Directory is used to search and consume services
web s
Web Engineering
consume
<> Patient
This is a Web Service for Registration and Discharge of Patient
<> Implementation
This is a Web Service Client wanting a Service
Legacy Application
Object Oriented Analysis – 300144
57

The patient object searches
the Directory
for services that
it needs.
On locating the Registration service, the Patient consumes the services
Web Services – Dynamic Model
: Patient : UDDI
searchServiceProviders( )
locateRegistrationService( )
getRegistrationService( )
: Registration
Messages to Registration will be used by the classes that have realised Registration
Object Oriented Analysis – 300144 58

Web Service Technologies HTTP; SOAP; XML; WSDL; UDDI
Object Oriented Analysis – 300144 59

Web Services – Technology Layers
UDDI
WSDL
Applications that
Need services locate XML/ Them through UDDI SOAP And consume
through WSDL
Applications that offer services define them through WSDL and publish through UDDI
Object Oriented Analysis – 300144
60

Discovery Layer: UDDI
• Universal Description, Discovery and Integration (Current Version 3.0; www.uddi.org)
• Register and locate Web services
• Originally developed my Microsoft and IBM now maintained by Organization for Advancement of Structured Information Standards (OASIS)
• It is a “meta service” for locating web services
• Useful in private as well as public deployments.
• IBM, Microsoft, and SAP had closed their public UDDI nodes
Object Oriented Analysis – 300144 61

Service Layer: WSDL
• WSDL = Web Services Description Language
• Web Services Description Language defines the
Interfaces to Web Services
– What the Web Services do
– How to communicate with the Web Services – Where to find the Web Services
• WSDL is XML based
Object Oriented Analysis – 300144 62

Information Layer: XML
• XML = EXtensible Markup Language
• XML and HTML are both derived from SGML – meta
languages
• XML is simple form of SGML
– A subset of SGML (Standard Generalized Markup Language)
– Independent of Platform, Language or Tool
– XML facilitates Interchange of Structured Documents over the Net
– Extensively used in EDI, Multimedia Publishing and Workflow Management
– Bulky and for Non-Real time B2B applications
Object Oriented Analysis – 300144 63

Packaging Layer: SOAP
• Simple Object Access Protocol (SOAP)
• Originally developed by Microsoft but now maintained by W3C
• Provides the interface to a Web service – Communication standard for web services
• Provides a framework to invoke services across the Internet, independent of Languages
• SOAP is text-based encoded XML, running over HTTP:
– Encoding rules that define how messages should be processed
– An envelope, which provides the framework for packaging message information
– An RPC representation that defines how to represent remote procedure calls and responses
• 2 types of SOAP RPC messages requests and responses – Documentstyle
– RPC style
Object Oriented Analysis – 300144 64

Packaging Layer: SOAP (Cont.)
• MechanismtosendXMLmessagesacross networks
– Consistent envelope
• Header contains message management information and security etc.
• Body contains message payload
– Consistent data encoding
• Based on XML Schema type system
– Protocol binding framework
Object Oriented Analysis – 300144 65

Protocol Layer: HTTP
• Web services work at the existing protocol of internet
• Web browsers (Internet Explorer, Firefox, Chrome, Safari, etc) use protocols like http to access the web
• HTML – Hyper Text Markup Language
– Provides Document Layout and Hyperlink Specification for WWW browsers
– XHTML-new version of HTML based on XML
• Business uses the Secure Hyper Text Transfer Protocol (SHTTP or HTTPS)
• Other protocols:
– ftp:// (File transfer protocol)
– telnet:// remote access
– smtp:// simple mail transfer protocol
– mime:// multipurpose internet mail extension
Object Oriented Analysis – 300144 66

Web Services – Usage and Modeling
Web Service
UDDI
WSDL
XML/ SOAP
UDDI
WSDL
XML/ SOAP
Business Application B1 & Its Location
UDDI is the Facilitator by Enabling Publication & Location of Services
Business Application A1 & Its Publication
Object Oriented Analysis – 300144
67

• •

.NET and J2EE to create WS application
.NET framework consists of programming standards plus software programs – Proprietary of Microsoft
J2EE is based on open source Java Programming language that is supported by software vendors like Oracle, SAP, IBM
Using Web Services in Practice
Object Oriented Analysis – 300144 68

Automating Web Services using .NET
Web Services AutoGenerate: Declaration WSDL, SOAP, XML
Publish: UDDI Server
Object Oriented Analysis – 300144
69

Enterprise Application Integration (Within an Organization)
HMS Application A: Staff Salaries XML Web Service
HTTP Get Salary Details
HTTP Verify Salary Details HTTP TransferFunds
HMS Application B: Payroll
XML Web Service
UDDI Discovery
Internal
Object Oriented Analysis – 300144 70

Business to Business
(Outside the Organization, with another Organization and its Applications)
HMS (Company A) XML, WSDL, SOAP
HTTP get Medical Quotes
Internet
HTTP Provide QuoteDetails HTTP Insure Event
Medical Insurance Company B: XML, WSDL, SOAP
UDDI Discovery
External
Object Oriented Analysis – 300144
71

WML – XML Web Services for Mobile Devices
Wireless XML (WML) Web Services
Handheld devices
for HMS Users
Like Doctors; Nurses; Administrators;
Mobile Gateway Services
(Using Mobile Internet Toolkit – for example)
Object Oriented Analysis – 300144
72

Conclusions
• Understanding What are interface specifications
• Creating Graphic User Interface
• Creating User Interface and Navigation maps
• Prototyping ✓Functional
✓Technical, ✓Architectural
• Introduction to Emerging Technologies
73

Project Work : (During Tutorials in the Lab);
Follow the Project Work Requirements given at the End of the Chapter;
Discuss Project Work with Team Members and Tutor;
Carry Out the Project Work
74

RUP Case Study – Train Traffic Management System (TTMS)
Construction – 1
75

System Structure
• Architectural design involves establishment of the central class structure of the system
– A specification of the common collaborations that animate these classes.
– Focusing on these mechanisms early directly attacks the elements of highest risk in the system
– Concretely captures the vision of the system’s architects – The products of the phase serve as the framework of
classes
• Examining the semantics of each of this system’s four key mechanisms: message passing, train schedule planning, displaying information and sensor data acquisition
76

Message Passing
• Do not mean to imply method invocation, as in an object-oriented programming language, but referring to a concept in the vocabulary of the problem domain, at a much higher level of abstraction
• Typical messages in the Train Traffic Management System include
– signals to activate wayside devices
– indications of trains passing specific locations – orders from dispatchers to train engineers
• In general, these kinds of messages are passed at two different levels within the TTMS:
– Between computers and devices – Among computers
77

Message Passing (Cont.)
• First cut at identifying these messages by examining each pair of communicating computers, as shown in our previous deployment diagram
• Three questions.
– What information does each computer manage?
– What information should be passed from one computer to the other?
– At what level of abstraction should this information be?
78

Message Passing (Cont.)
• It is critical at this level of design to focus on the content, not the form, of these messages.
• Should decide on the roles and responsibilities of each message and what operations we can meaningfully perform on each message
• The class diagram captures the design decisions regarding some of the most important messages in the Train Traffic Management System
79

The Message Class Diagram
80

81
The communication diagram provides a scenario that captures the design of the message-passing mechanism.
The Message-Passing Mechanism