1. CIS511 Information System Architecture
Asst.Prof. Dr. Surasak Mungsing

2. Information System Architecture and Approaches to System Development

3. Information System Architecture

4. Information System Architecture
The architecture of an information system defines that system in terms of components and interactions among those components, from the viewpoint of specific aspects of that system, and based on specific structuring principles.

5. Aspects architecture

6. Data aspect architecture

7. System aspect architecture

8. Configuration aspect architecture

9. Communication aspect architecture (I)

10. Communication aspect architecture (II)

11. Organization aspect architecture

12. A design path with aspects

13. Types of IS Architectures

14. Structuring principles (I)

15. Structuring principles (II)

16. Structuring principles (III)

17. Purpose of architecture (I)

18. Purpose of architecture (II)

19. Q & A

20. Approaches to System Development
CS 578 Software Architecture -- Origins of Software Architectures
10 June 2018
Approaches to System Development
© Neno Medvidovic & Edward Colbert

21. Learning Objectives
Explain the purpose and various phases of the systems development life cycle (SDLC)
Explain when to use an adaptive approach to the SDLC in place of a more predictive traditional SDLC
Explain the differences between a model, a tool, a technique, and a methodology
Describe the two overall approaches used to develop information systems: the traditional method and the object-oriented method

22. The Systems Development Lifecycle (SDLC)
Provides overall framework for managing systems development process
Two main approaches to SDLC
Predictive approach – assumes project can be planned out in advance
Adaptive approach – more flexible, assumes project cannot be planned out in advance
All projects use some variation of SDLC

23. Traditional Predictive Approach to the SDLC
Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project
Analysis – understand business needs and processing requirements
Design – define solution system based on requirements and analysis decisions
Implementation – construct, test, train users, and install new system
Support – keep system running and improve

24. “Waterfall” Approach to the SDLC

25. Modified Waterfall Approach with Overlapping Phases

26. Newer Adaptive Approaches to the SDLC
Based on spiral model
Project cycles through development activities over and over until project is complete
Prototype created by end of each cycle
Focuses on mitigating risk
Iteration – Work activities are repeated
Each iteration refines previous result
Approach assumes no one gets it right the first time
There are a series of mini projects for each iteration

27. Activities of Planning Phase of SDLC
Define business problem and scope
Produce detailed project schedule
Confirm project feasibility
Economic, organizational, technical, resource, and schedule
Staff the project (resource management)
Launch project  official announcement

28. Activities of Analysis Phase of SDLC
Gather information to learn problem domain
Define system requirements
Build prototypes for discovery of requirements
Prioritize requirements
Generate and evaluate alternatives
Review recommendations with management

29. Activities of Design Phase of SDLC
Design and integrate the network
Design the application architecture
Design the user interfaces
Design the system interfaces
Design and integrate the database
Prototype for design details
Design and integrate system controls

30. Activities of Implementation Phase of SDLC
Construct software components
Verify and test
Convert data
Train users and document the system
Install the system

31. Activities of Support Phase of SDLC
Maintain system
Small patches, repairs, and updates
Enhance system
Small upgrades or enhancements to expand system capabilities
Larger enhancements may require separate development project
Support users
Help desk and/or support team

32. Methodologies and Models
Comprehensive guidelines to follow for completing every SDLC activity
Collection of models, tools, and techniques
Models
Representation of an important aspect of real world, but not same as real thing
Abstraction used to separate out aspect
Diagrams and charts
Project planning and budgeting aids

33. Tools and Techniques Tools Techniques
Software support that helps create models or other required project components
Range from simple drawing programs to complex CASE tools to project management software
Techniques
Collection of guidelines that help analysts complete a system development activity or task
Can be step-by-step instructions or just general advice

34. Two Approaches to System Development
Traditional approach
Also called structured system development
Structured analysis and design technique (SADT)
Includes information engineering (IE)
Object-oriented approach
Also called OOA, OOD, and OOP
Views information system as collection of interacting objects that work together to accomplish tasks

35. Object-Oriented Approach
Completely different approach to information systems
Views information system as collection of interacting objects that work together to accomplish tasks
Objects – things in computer system that can respond to messages
Conceptually, no processes, programs, data entities, or files are defined – just objects
OO languages: Java, C++, C# .NET, VB .NET

36. Object-Oriented Approach
Object-oriented analysis (OOA)
Defines types of objects users deal with
Shows use cases are required to complete tasks
Object-oriented design (OOD)
Defines object types needed to communicate with people and devices in system
Shows how objects interact to complete tasks
Refines each type of object for implementation with specific language of environment
Object-oriented programming (OOP)
Writing statements in programming language to define what each type of object does

37. Life Cycles with Different Names for Phases

38. Current Trends in Development
The Unified Process (UP): Reinforces six best practices(develop iteratively, define and manage system requirements, use component architectures, create visual models, verify quality, control changes)
Extreme Programming (XP): Recent development approach to keep process simple and efficient
Agile Modeling: Hybrid of XP and UP
Scrum: Respond to situation as rapidly as possible

39. Tools to Support System Development
Computer-aided system engineering (CASE)
Automated tools to improve the speed and quality of system development work
Contains database of information about system called repository
Upper CASE – support for analysis and design
Lower CASE – support for implementation
ICASE – integrated CASE tools
Now called visual modeling tools, integrated application development tools, and round-trip engineering tools

40. Q&A

41. Why Analyse Requirements?
Use case model alone is not enough
There may be repetition
Some parts may already exist as standard components
Analysis aims to identify:
Common elements
Pre-existing elements
Interaction between different requirements
© Bennett, McRobb and Farmer 2005

42. What a Requirements Model Must Do
A requirements model meets two main needs:
Confirms what users want a new system to do
Must be understandable for users
Must be correct and complete
Specifies what designers must design
Must be unambiguous
© Bennett, McRobb and Farmer 2005

43. What a Requirements Model Must Do
Describes what the software should do
Represents people, things and concepts important to understand what is going on
Shows connections and interactions among these people, things and concepts
Shows the business situation in enough detail to evaluate possible designs
Is organized so as to be useful for designing the software
© Bennett, McRobb and Farmer 2005

44. How We Model the Analysis
The main tool used for analysing requirements is the class diagram
Two main ways to produce this:
Directly based on knowledge of the application domain (a Domain Model)
By producing a separate class diagram for each use case, then assembling them into a single model (an Analysis Class Model)
© Bennett, McRobb and Farmer 2005

45. Class Diagram: Stereotypes
Analysis class stereotypes differentiate the roles objects can play:
Boundary objects model interaction between the system and actors (and other systems)
Entity objects represent information and behaviour in the application domain
Control objects co-ordinate and control other objects
© Bennett, McRobb and Farmer 2005

46. Class Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005

47. Class Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005

48. Class Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005

49. Class Diagram: Class Symbol
© Bennett, McRobb and Farmer 2005

50. Class Diagram: Instance Symbol

51. Class Diagram: Attributes
Attributes are:
Part of the essential description of a class
The common structure of what the class can ‘know’
Each object has its own value for each attribute in its class
© Bennett, McRobb and Farmer 2005

52. Class Diagram: Links

53. Class Diagram: Associations
Associations represent:
The possibility of a logical relationship or connection between objects of one class and objects of another
If two objects can be linked, their classes have an association
© Bennett, McRobb and Farmer 2005

54. Class Diagram: Associations
© Bennett, McRobb and Farmer 2005

55. Class Diagram: Multiplicity
© Bennett, McRobb and Farmer 2005

56. Class Diagram: Operations
Operations describe what instances of a class can do:
Set or reveal attribute values
Perform calculations
Send messages to other objects
Create or destroy links
© Bennett, McRobb and Farmer 2005

57. From Requirements to Classes
Start with one use case
Identify the likely classes involved (the use case collaboration)
Draw a collaboration diagram that fulfils the needs of the use case
Translate this collaboration into a class diagram
Repeat for other use cases
© Bennett, McRobb and Farmer 2005

58. From Requirements to Classes
This will require some explanation, either on whiteboard or with prepared examples on a handout.

59. Sequence Diagrams
Jun-18

60. sd Add a new advert to a campaign if within budget
:CampaignManager
:Client
:Campaign
:Advert
getName
listCampaigns
ref
List client campaigns
ref
Get campaign budget
addCostedAdvert
alt
[totalCost <= budget]
ref
Create advert
[else]
ref
Create request

61. Interaction Fragment Used
sd Get campaign budget
:CampaignManager
:Campaign
:Advert
checkCampaignBudget
loop
[For all campaign’s adverts]
getCost
getOverheads

62. Simple activity diagram
Create new StaffGrade
Link to CreativeStaff
Link to previous StaffGrade
Set previous StaffGrade gradeFinishDate
An activity diagram show the main steps for the operation

63. Activity Diagram with Selection and Iteration
Calculate bonus
[bonus > £250]
Add to list
[more StaffMembers]
Format list
[no more StaffMembers]
Add to ‘star’ list
Create warning letter
[bonus < £25]
[bonus >= £25 AND
bonus <= £250]

64. System Design and Detailed Design
System design deals with the high level architecture of the system
structure of sub-systems
distribution of sub-systems on processors
communication between sub-systems
standards for screens, reports, help etc.
job design for the people who will use the system
© Bennett, McRobb and Farmer 2005

65. System Design and Detailed Design
Object-oriented detailed design adds detail to the analysis model
types of attributes
operation signatures
assigning responsibilities as operations
additional classes to handle user interface
additional classes to handle data management
design of reusable components
assigning classes to packages
© Bennett, McRobb and Farmer 2005

66. © Bennett, McRobb and Farmer 2005
Qualities of Analysis
Correct scope—everything in the system is required
Completeness—everything required is in the system and everything is documented in the models
Correct content—accurate description of requirements
Consistency—each element is consistently referred to by the same name
© Bennett, McRobb and Farmer 2005

67. © Bennett, McRobb and Farmer 2005
Qualities of Design
Functional—system will perform the functions that it is required to
Efficient—the system performs those functions efficiently in terms of time and resources
Economical—running costs of system will not be unnecessarily high
Reliable—not prone to hardware or software failure, will deliver the functionality when the users want it
May have to watch storage  think enterprise systems. Give examples of firms who don’t want to take on support issues
May want to briefly mention McCalls quality factors as they compare to so much of this
© Bennett, McRobb and Farmer 2005

68. © Bennett, McRobb and Farmer 2005
Qualities of Design
Secure—protected against errors, attacks and loss of valuable data
Flexible—capable of being adapted to new uses, to run in different countries or to be moved to a different platform
General—general-purpose and portable (mainly applies to utility programs)
Buildable—Design is not too complex for the developers to be able to implement it
© Bennett, McRobb and Farmer 2005

69. © Bennett, McRobb and Farmer 2005
Qualities of Design
Manageable—easy to estimate work involved and to check of progress
Maintainable—design makes it possible for the maintenance programmer to understand the designer’s intention
Usable—provides users with a satisfying experience (not a source of dissatisfaction)
Reusable—elements of the system can be reused in other systems
© Bennett, McRobb and Farmer 2005

70. Q&A