system thinking and problem solving for IT solutions
lauren II
lm_3_context_diagrams.pptx1
1
2
3
4
5
Learning Module Outline
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson 3.2
Introduction to System Context Diagrams (SCD)
Lesson 3.3
Notation and Styles for UML System Context Diagrams
Lesson 3.1
System Thinking – A Context Viewpoint
1
2
This is our first (or several) tool modules. In this chapter we will learn a “scoping” tool called SYSTEM CONTEXT DIAGRAMS (SCDs). There are other scoping tools that we will cover in other learning modules.
System Concept Diagrams
DIFFERENCES BETWEEN CNIT 380, 385, and this course
2
List of References
Rozanski, N. and Woods, E. (2009). The system context architectural viewpoint. Proceedings of 2009 IEEE/IFIP WICSA/ECSA (pp. 333-336). Retrieved from http://s3.amazonaws.com/academia.edu.documents/41186086/The_System_Context_Architectural_Viewpoi20160115-16229-1s08s8z.pdf?AWSAccessKeyId=AKIAJ56TQJRTWSMTNPEA&Expires=1476358091&Signature=mFYznNtNd%2BVk20D0udBdIaoNAMI%3D&response-content-disposition=inline%3B%20filename%3DThe_system_Context_architectural_viewpoi.pdf
---------- assigned readings above; additional references below ----------
DeMarco, T. (1978). Structured systems analysis and specification.
Gane, C. P., & Sarson, T. (1979). Structured systems analysis: tools and techniques. Prentice Hall Professional Technical Reference.
Gorton, I. (2006) Essential software architecture. Springer Science & Business Media, 2006.
Rozanski, N. and Woods, E. (2012) Software systems architecture: Working with stakeholders using viewpoints and perspectives (2nd edition). Upper Saddle Ridge, NJ, USA: Pearson Education.
Whitten, J. L.; Bentley, L.; and Dittman K. (2012). Systems analysis and design methods (7th Edition). Burr Ridge, IL, USA: Irwin/McGraw-Hill.
3
3
4
1
2
3
4
5
Learning Module Outline
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson 3.2
Introduction to System Context Diagrams (SCD)
Lesson 3.3
Notation and Styles for UML System Context Diagrams
Lesson 3.1
System Thinking – A Context Viewpoint
This slide serves as a roadmap through a learning module or course unit that has been divided into multiple lessons. Copy this slide as needed to precede each lesson included in the learning module.
The design is intended to highlight the “current” lesson in gold. To change the current lesson, do the following:
Left-click on the far right-hand side of the current gold bar.
Left-click on the format painter icon (the paintbrush)
Left-click on the far right-hand side of the new current lesson. You should now have two gold bars. We still need to make the old lesson gray.
Left-click on the far right-hand side of any remaining gray bar
Left-click on the format painter icon.
Left-click on the far right-hand side of the gold bar that is no longer the current lesson. We now should have a gold bar only for the new current lesson.
Delete or replace the image with the primary reference for the current lesson (usually a textbook). Replace APA citation with that of the primary reference.
4
Systems Thinking Context
5
REF: ISO Software Architecture Standard as described by Rozanski and Woods
CONTEXT Views
FUNCTIONAL View
INFORMATION View
TIMING View
DEVELOPMENT View
DELPOYMENT View
OPERATIONAL View
Not a new idea in systems design
Other architectural standards
Kruchten’s 4 + 1 architecture (IBM)
IEEE Standard 1471 that is the basis for your textbook
Zachman’s Framework for Information Systems Architecture
5
ENVIRONMENT
System Concepts for Context Views of a System
6
YOUR SYSTEM
THING
THING
THING
THING
THING
THING
THING
THING
6
What are the context views of a system?
| Characteristics | Explanation |
| Definition | The context view describes the relationships, dependencies, and interactions between YOUR system and its environment (which may include people, groups, other systems, and machinery). |
| Concerns | YOUR system’s scope and responsibilities, identification of external entities in YOUR system’s environment, data and services YOUR system needs from the environment (net inputs), information and services YOUR system provides to the environment (net outputs), implementation of said inputs and outputs (interfaces), and impact of your system on its environment |
| Architectural Descriptions | Context diagrams Lists of black box characteristics |
| Possible Problems | Missing or incorrect external entities, missing interactions or dependencies, loose or imprecise interface details or constraints, implicit or assumed scope, scope creep, jargon or details that are inappropriate to specific classes of stakeholders |
| Applicable Stakeholders | Systems owners, system users, technology providers/acquirers, system designers, system builders (in other words, all stakeholder classes) |
| Applicability | All systems of all types |
7
REF: Adapted from Rozanski and Woods (2012)
7
Systems Concepts for Context Views of a System
Black box thinking and information hiding
Every system of interest (YOUR system) must interact with its environment
Net Inputs it must receive from its environment
Net outputs it must send to its environment
Every system (and its environment) consists of things of interest (that we need to identify) = SCOPE
Every system’s interactions with its environment need to be designed = INTERFACES
8
THING
Systems Thinking for Context Views
9
YOUR SYSTEM
THING
THING
THING
THING
Irrelevant
THING
External Environment
Internal Environment
SOME THINGS ARE ARE RELEVANT; OTHER THINGS ARE NOT
9
Multiple Context Views in Systems Thinking
| Stakeholders | Value | Project Activities |
| System Owners | Used to communicate and manage high-level scope as a pseudo-contract | System Planning |
| System Users | Used to refine and communicate detailed scope as a pseudo contract | System Analysis |
| System Designers | Used to communicate technical details about user, system, and machine interfaces | System Design |
| System Builders | Used to communicate technical details about user, system, and machine interfaces | System Implementation |
10
Row for our course is boldfaced
10
System SCOPE
Scope defines the boundaries of your system
What is “in” scope?
What is “out” of scope?
Scope drives several things for system owners
Goals and objectives … how will we know when we succeed?
Budget … to develop the system, and to sustain the system
Timetable … to develop the system by the time it is needed
Scope is defined during system planning, BUT …
Scope is subject to constant change, and that’s not always bad
The level of detail we use to document scope increases as we progress
Scope can be reduced
Scope can be increased … at a cost
11
11
Best Way to Communicate SCOPE and INTERFACES?
As always, depends on which stakeholder groups that comprise your audience
System owners high-level SCOPE words; simple diagrams management jargon
System users detailed SCOPE words; detailed diagrams; business jargon
System designers INTERFACES diagrams; detailed specifications technical jargon
System builders same as system designers
12
System Context Diagrams (SCD)
13
Scope of the Inner Workings of the Black Box
Use the framework columns:
MOTIVATIONS
DATA/INFORMATION
PEOPLE
FUNCTIONALITY/ SERVICES
TIMING/ BEHAVIOR
GEOGRAPHY
SECURITY? Suggested by last year’s class
14
Will use an accordion style to expand and contract these bullets in the next several slides
Scope of the Inner Workings of the Black Box
MOTIVATIONS
List of strengths, weaknesses, opportunities, threats (SWOT)
List of perceived problems, opportunities, and/or directives (PIECES) (notice we said “list”; not “analysis of”)
List of goals and objectives (word using SMART sentences) (SMART = Specific, Measurable, Attainable, Reasonable, and Time-delimited)
List of applicable business policies ... if known
DATA/INFORMATION
PEOPLE
FUNCTIONALITY AND SERVICES
TIMING/BEHAVIOR
GEOGRAPHY
SECURITY?
15
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
List of things about which the system must capture and use data? (typically, nouns = persons, organizations, places, objects, abstractions, analog properties)
List of information or actions desired by management?
PEOPLE
FUNCTIONALITY AND SERVICES
TIMING/BEHAVIORS
GEOGRAPHY
SECURITY
16
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
PEOPLE
List of direct users of the system
List of indirect users of the system (people who may be impacted by the system)
Quick assessment of organizational readiness and potential resistance (useful framework = Prosci’s ADKAR model)
FUNCTIONALITY AND SERVICES
TIMING/BEHAVIOR
GEOGRAPHY
SECURITY
17
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
PEOPLE
FUNCTIONALITY AND SERVICES
List of functionality and services to be provided by the system
List of impacted business processes (if applicable) (almost always applicable in “information” systems)
TIMING/BEHAVIOR
GEOGRAPHY
SECURITY
18
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
PEOPLE
FUNCTIONALITY AND SERVICES
TIMING/BEHAVIOR
List of events for which the system must provide a response? (owners may not fully know all of the desired responses)
Is there a cyclical or recurring calendar for this system? If so list those events. (owners may not fully know all of the calendar events)
GEOGRAPHY
SECURITY
19
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
PEOPLE
FUNCTIONALITY AND SERVICES
TIMING
GEOGRAPHY
List of internal locations and, if known, mappings to users.
List of external locations, if known, and partners
SECURITY
20
Scope of the Inner Workings of the Black Box
MOTIVATIONS
DATA/INFORMATION
PEOPLE
FUNCTIONALITY AND SERVICES
TIMING
GEOGRAPHY
SECURITY
List of privacy concerns
List of internal security concerns
List of external security concerns
21
22
System owners, by the very nature of their jobs, have a somewhat ‘summary’ perspective on scope. They are usually more removed from the problem space than the system users.
EXPECT to have to refine, and perhaps expand these lists as a project progresses. But when the lists change, always validate backwards to prior audiences.
to make sure everyone is still in agreement
to make sure the budget and schedule are still OK
Final words of caution about these scoping “lists”
PLANNING ESTBALISHES THE initial LISTS
ANALYSIS starts by reviewing and updating the lists … validate afterwards with owners
DESIGN starts by reviewing the lists … and validate afterwards with users and owners
IMPLEMENTATION starts by reviewing the lists … BUT REALLY SHOULD NOT BE CHANGING AT THAT POINT
22
23
Complete the reading assignment posted to Blackboard
Web search “context diagram” and study the sample“ images” returned. Bring samples to class and answers to these questions:
What notations and formats did you discover?
What did you like or dislike about the different notations you researched?
What did possible issues could result from multiple?
Class prep for next class
24
1
2
3
4
5
Learning Module Outline
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson 3.2
Introduction to System Context Diagrams (SCD)
Lesson 3.3
Notation and Styles for UML System Context Diagrams
Lesson 3.1
System Thinking – A Context Viewpoint
This slide serves as a roadmap through a learning module or course unit that has been divided into multiple lessons. Copy this slide as needed to precede each lesson included in the learning module.
The design is intended to highlight the “current” lesson in gold. To change the current lesson, do the following:
Left-click on the far right-hand side of the current gold bar.
Left-click on the format painter icon (the paintbrush)
Left-click on the far right-hand side of the new current lesson. You should now have two gold bars. We still need to make the old lesson gray.
Left-click on the far right-hand side of any remaining gray bar
Left-click on the format painter icon.
Left-click on the far right-hand side of the gold bar that is no longer the current lesson. We now should have a gold bar only for the new current lesson.
Delete or replace the image with the primary reference for the current lesson (usually a textbook). Replace APA citation with that of the primary reference.
24
25
What notations and formats did you discover?
What did you like or dislike about the samples you researched?
What did you learn from that?
Let’s discuss YOUR research into Context Diagrams
Historically, where did context diagrams originate?
False credit goes to the “Object-Oriented Analysis & Design” methodology, and the UML
Context diagrams are NOT a part of the OMG’s UML standard
But many UML authors recommend them to add address scope before starting to draw any standard UML diagrams
True credit goes to the “Structured Analysis and Design” methodology (≈1978)
Inventors were Chris Gane, Trish Sarson, and Tom DeMarco
Context diagrams were invented in the methodology to visualize scope
Context diagrams were considered a simple type of data flow diagram (DFD)
26
REF: Gane, C. and Sarson, T. (1978). Structured systems analysis. REF: DeMarco, T. (1978). Structured analysis and system specification.
26
And they looked something like this …
27
Gane and Sarson Notation
This is the most common SCD notation
… or this …
28
Demarco Notation
Also Ward Notation
This is the 2nd most common SCD notation
… or this …
29
A UML-like Notation
… or this …
30
Another UML-like Notation
… or this …
31
Yet another UML-like
Notation
… or this …
32
An
Artistic
STYLE
… have a tendency to start looking like this … or worse
33
A Common Problem with Context Diagrams
In all but the smallest systems, the diagrams can become quite cluttered, thus detracting from the primary purpose of drawing ANY diagramming … COMMUNICATION with stakeholders
This diagram is an example of the problem – and they can get much, much worse.
We need to come up with ways of dealing with such complexity
So what do context diagrams communicate?
Focus on the world outside of your system – your system is just a “black box”
In other words, focus is on your system’s environment, NOT what’s going on INSIDE your system
Your system gets depicted as a black box (center of page) that intentionally hides details of how your system works
Interactions shown include net inputs, outputs exchanged with your system’s environment
Thus, context diagram illustrates scope
But context diagram also explicitly identifies INTERFACES that will need to be DESIGNED and built for your system
34
34
Conclusions
Too many notations between authors and analysts
Confuses stakeholders who see different looking context diagrams from one project to the next
Easily gets TOO busy to communicate, even for relatively simple systems
Violates RULE #1 of diagramming; failure to communicate
As originally conceived, only attempts to communicate scope; doesn’t carry over to add value to system design
35
In-class exercise
Present the retailer’s catalog to the user, including pictures and product specifications
Provide a flexible search facility (search on product name, type, keyword, size, and so on)
Accept orders for goods
Accept payment by credit card (with asynchronous approval and notification to the customer)
Provide automated interfaces into back-end systems for fulfillment
To be developed using agile software development; therefore, the scope exclusions for the first version of such the system will be:
The ability to amend or cancel orders (this will need to be done over the telephone but is planned to be automated in a subsequent release)
The ability to make payments by means other than credit card (e.g., PayPal, EFT, etc.)
Display of live stock levels and the ability to reserve out-of-stock items
36
Adapted from Rozanski, N. and Woods, E. (2011). Software systems architecture: Working with stakeholders using viewpoints and perspectives (2nd Edition) Pearson Education (USA). Kindle Edition.
Rozanski, Nick; Woods, E?in (2011-10-25). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2nd Edition) (Kindle Locations 4732-4738). Pearson Education (USA). Kindle Edition.
36
37
1
2
3
4
5
Learning Module Outline
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson 3.2
Introduction to System Context Diagrams (SCD)
Lesson 3.3
Notation and Styles for UML System Context Diagrams
Lesson 3.1
System Thinking – A Context Viewpoint
This slide serves as a roadmap through a learning module or course unit that has been divided into multiple lessons. Copy this slide as needed to precede each lesson included in the learning module.
The design is intended to highlight the “current” lesson in gold. To change the current lesson, do the following:
Left-click on the far right-hand side of the current gold bar.
Left-click on the format painter icon (the paintbrush)
Left-click on the far right-hand side of the new current lesson. You should now have two gold bars. We still need to make the old lesson gray.
Left-click on the far right-hand side of any remaining gray bar
Left-click on the format painter icon.
Left-click on the far right-hand side of the gold bar that is no longer the current lesson. We now should have a gold bar only for the new current lesson.
Delete or replace the image with the primary reference for the current lesson (usually a textbook). Replace APA citation with that of the primary reference.
37
PROBLEM: Lack of standardized notation for SCDs
SOLUTION
Build our own standard notation (which explains why we saw so many different notations earlier)
Develop an standard using an existing notation
We will adapt the UML standard notation for use as system concept diagrams (SCDs).
How? The UML standard provides for developing new tool profiles using the standard notations. Therefore, what we are doing here is not a violation or compromise of the UML.
38
39
In this course, we will standardize on a UML-style context diagram.
This instructor is NOT saying that the context diagrams you learned in other courses and books are wrong!
He IS suggesting that there is a way to bring greater consistency and communication clarity to context diagrams that will produce more meaningful communications with stakeholders.
About context diagrams as taught in your other courses
39
But first, we need to review some UML notations
In our UML context diagrams, we will use two UML notations available for use in all UML diagrams of any type
Stereotypes
Tags
40
UML Stereotypes
In UML, stereotypes allow designers to extend the vocabulary of UML to communicate specific properties about shapes or connections.
Should be standardized across all projects, or managed by someone (e.g., a project office).
Scott Ambler’s book, Elements of UML Style, provides a nice starting set, but it is intended that each organization maintain their own approved set.
Format is usually lowercase, no bold only
<< stereotype name >> as written inside any UML shape, or on a connection
One example that might be used in context diagrams includes:
<< internal >> or <<external >>
We will adopt the convention of placing << stereotypes >> above the name of the shape of connection to which they apply
A shape or connection can have more than one << stereotype >>. Should be listed on separate lines. Each should be bracketed.
41
41
UML Tags
In UML, tags allow designers to extend the vocabulary of UML to communicate specific properties or specifications
Not intended to be standardized within any organization
Highly used on technical context diagrams to communicate technology decisions or constraints that are intended for technologists
Format is usually mixed lower/uppercase
{ Tag Name } as written inside any UML shape, or on a connection
Examples include (notice
{ XML } or { RPC } or {C++} or {Oracle} or {Oracle SQL 9.3} or {Safari ≥ 8.1) or {MS C# V > 3}
We will adopt the convention of placing { tags } below the name of the shape of connection to which they apply
A shape or connection can have more than one { tag }. If so, they should be listed on separate lines. Each should be bracketed.
42
42
Quick example from Rozanski and Woods, but …
43
NOTICE THT THIS SAMPLE ONLY USED STEROTYPES, NOT TAGS
THING
Reminder - Systems Thinking for Context Diagrams
44
YOUR SYSTEM
Interrnal Entity
External Entity
External Entity
Internal Entity
Internal Entity
External Environment
Internal Environment
SOME THINGS ARE ARE RELEVANT; OTHER THINGS ARE NOT
44
Your System = The System of Interest in YOUR Project
Should be drawn in the center of the page as a rectangle.
45
If your drawing tool supports it, consider shading it BLACK to emphasize that this is YOUR system; and to reinforce BLACK BOX thinking!
<< project name >>
SYSTEM NAME
SYSTEM NAME could be descriptive or codename or
acronym
If project name is same as system name, stereotype can be omitted
External Entities
”Things” in your system’s environment with which YOUR system must interact (= communicate)
A user, a class of user, or some other person or role, such as operational or support staff – may be inside or outside our organization
An existing system that runs inside or outside our organization
A data store that is external to our system (for example, a shared database or data warehouse)
What about internal data stores?
A machine or other physical device that is external to the system (such as a sensor, appliance or robot, smart appliance or enterprise search engine)
46
REF: Rozanski, N. and Woods, E. (2012)
External Entities Vocabulary and Notations
People, groups (e.g. departments, teams, or external organizations with whom your system directly interacts (inputs and outputs)
Existing systems, internal or external with which your new system must exchange data (input and/or output)
Existing external data stores with which your system must use or update data (w/o structural changes) – what about internal database?
Machines, sensors, devices, appliances, etc. with which your system must interact.
47
47
Connections = INTERFACES that are in scope and must be designed
Human Computer Interfaces (HCI)
Internal HCI = used by employees inside your company
External HCI = used by customers or others outside of your company
System Interfaces (with existing systems or databases)
Internal System Interfaces = used to exchange data between your new system and other existing systems and databases inside your company
Permanent = will be used for the lifetime of your system
Temporary = will be used for some transitional period of your system = crosswalks
External System Interfaces = used to exchange data between your new system and other existing systems and databases outside your company
Permanent = will be used for the lifetime of your system
Temporary = will be used for some transitional period of your system = crosswalks
Real-time Machine Interfaces
Sensors = bring analog data into system (temperature, speed, altitude, air pressure, heart rate, fluid levels, time, moisture, etc.
Instructions = send commands and instructions to a device, machine, or appliance
48
TAKE A MOMENT TO EXPLAIN TEMPORARY INTERFACES
48
Interface Notations and Vocabulary
Data flows should the net data flow to or from “your system”
For HCI and system interfaces, names of data flows (inputs or outputs) to and from your actors or systems
For external DBs, names of data flow and parenthetical (data operations) where data operations are:
C = create records or rows
R = read records or rows
U = update or modify records or rows
D = delete (deactivate) records or rows
I = import batches of data
E = export batches of data
Control flows show either analog data monitored by your system, or instructions sent to your system
49
NO DOUBLE ENDED ARROWS ALLOWED
49
Summary of UML Context Diagram Notation and Styles
50
UML shape name is ACTOR or USER
UML shape name is COMPONENT
UML shape name is DATA STORE
UML shape name is DEVICE NODE
UML shape name is SYSTEM BOUNDARY
Summary of UML Context Diagram Notation and Styles
51
In UML, dashed arrows are called CONTROL FLOWS
In UML, solid arrows are called DATA FLOWS or MESSAGE (FLOWS)
Suggested Stereotypes (if no approved list)
| NOTATION | SUGGESTED STEREOTYPE NAMES |
| YOUR SYSTEM | project name, our system, our project, system of interest |
| ACTOR or USER | internal, external |
| Existing INTERFACING SYSTEM | internal, external |
| EXISTING DATA STORE (out of scope for structural changes) | internal, external |
| MACHINE or DEVICE | device, sensor, machine, appliance, robot |
| DATA FLOW | batch, transaction, on demand create, read, update, delete, import, export, batch |
| CONTROL FLOW | real-time |
52
Blank cells mean there are no suggestions
POSSIBLE Tags (list is not exhaustive or to be approved)
| NOTATION | SAMPLE TAGS (nowhere near exhaustive) |
| YOUR SYSTEM | |
| ACTOR or USER | |
| Existing INTERFACING SYSTEM | operating system name, programming language name, file system type, interface protocol name – all possibly inclusive of version |
| EXISTING DATA STORE | database management system name – possibly with version |
| MACHINE or DEVICE | technology name, protocol name |
| DATA FLOWS | user interface standard, communication protocol, database format – all possibly inclusive of existing version, or expected minimum version -- tbd |
| CONTROL FLOWS | communications protocol -- tbd |
53
Blank cells indicate not generally applicable – but also NOT forbidden
Data Flow Properties of Interfaces to be Described in Detail
Notice that these address quality properties of your interfaces. Not all are applicable to all systems. Instructor likes to describe these properties in Excel or Word tables that get “linked” to the arrows on the context diagram (if your tool permits that).
Performance Expectations – number of requests or transfers, amount of data, seasonal fluctuations, expected growth
Performance Expectations – response time, latency, scalability, availability, etc.
Timing – whether interactions are scheduled (occurring at pre-defined times), occur in response to events, or are ad hoc;
Timing – whether interactions must be processed as a batch, or are message based (one-at-a-time)
Timing – meaning must be completed fully, or not at all
Security – authentication, authorization, confidentiality, etc.
Formats – of data and files
54
Some address quality properties
54
VERY Oversimplified Table
55
REF: Tayntor, C. (2006). Successful packaged software implementation. Boca Raton, FL: CRC Press.
Instructor would rename first column to “Interface Name” and then greatly expand to columns to include the types of properties listed in the previous slide. Let’s see how many of you create one or more standard tables to connect to your diagrams.
UML Context Diagram Template
56
Enlarged on next slide
Three templates have been added to your Blackboard course web site. Equivalent templates for other drawing tools can be submitted to the instructor.
56
57
NEW AND IMPROVED TEMPLATE POSTED TO BLACKBOARD
57
Recommendations for using the template
Not all entity/agent/actor “types” apply to all systems … delete those not used; and copy those for which you have multiple instances
Not all flow “types” apply to all systems … delete those not used; and copy those for which you need multiple instances
There is no limit to the number of data or control flows between your system (center) and any given external entity or actor
Which means we WILL still need to deal with the potential for “clutter”
Use UML <<stereotypes>> to communicate categories for context diagram shapes and flows
Use UML {tags} to communicate other relevant technology or business constraints
58
Recommendations for using the template (continued)
Recommend legal size “paper” and landscape orientation
Add a title block to lower right (or other consistent location)
Provide a “Legend” for all shapes and connections (separate page)
Use UML NOTE shape to add other useful comments
Try not to overuse jargon when diagram is intended for communicating to system owners and users
Add technical jargon when diagram is intended for communicating to system designers and builders
59
EVERYTHING IS A SYSTEM
SCOPE CHANGES
59
60
COMMON MYTH
Systems analysts / architects should only draw ONE context diagram for their project
THIS IS JUST NOT TRUE! Leads to communication overload!
We still need to deal with potential clutter
This causes clutter and degrades readability.
It also assumes that all stakeholders will be able understand the vocabulary used in a single context diagram
60
We want to avoid clutter that starts looking like this or worse
61
Dealing with clutter in context diagrams
RECOMMENDATION #1
For larger systems and projects, draw separate context diagrams for major functional subsystems. Each will be intended for a different subgroups of our major stakeholder categories.
RECOMMENDATION #2 (a Whitten favorite)
Draw separate diagrams for different types of interfaces
One (or few) context diagrams for human computer interfaces
Perhaps separate diagrams for internal versus external user interfaces
Perhaps a separate diagram for standard reports
One (or few) diagrams for internal and external system interfaces
One (or few) diagrams for existing data store interfaces
One (or few) diagrams for device interfaces (if you even have any)
Combine RECOMMENDATION #1 and #2
RECOMMENDATION #3 (a Demarco suggestion from back in 1976)
Consolidate data flows into composites (groups)
62
62
63
If your drawing tool allows it, create multiple tabs (pages) in a single file to keep all your context diagrams together.
(This also makes it easy to find and edit; to maintain consistency)
IDEA TO PACKAGE MULTIPLE CONTEXT DIAGRAMS
This causes clutter and degrades readability.
It also assumes that all stakeholders will be able understand the vocabulary used in a single context diagram
63
Here’s our first context diagram using our UML profile
64
65
MISTAKES!
65
66
Now, Let’s DRAW a set of Context Diagrams
(for a system that includes BOTH information system and real-time system characteristics)
67
1
2
3
4
5
Learning Module Outline
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson 3.2
Introduction to System Context Diagrams (SCD)
Lesson 3.3
Notation and Styles for UML System Context Diagrams
Lesson 3.1
System Thinking – A Context Viewpoint
ADDENDUM
Sample System Concept Diagrams Using the UML Notation
This slide serves as a roadmap through a learning module or course unit that has been divided into multiple lessons. Copy this slide as needed to precede each lesson included in the learning module.
The design is intended to highlight the “current” lesson in gold. To change the current lesson, do the following:
Left-click on the far right-hand side of the current gold bar.
Left-click on the format painter icon (the paintbrush)
Left-click on the far right-hand side of the new current lesson. You should now have two gold bars. We still need to make the old lesson gray.
Left-click on the far right-hand side of any remaining gray bar
Left-click on the format painter icon.
Left-click on the far right-hand side of the gold bar that is no longer the current lesson. We now should have a gold bar only for the new current lesson.
Delete or replace the image with the primary reference for the current lesson (usually a textbook). Replace APA citation with that of the primary reference.
67
68
Our Case Study Example
69
INSTRUCTOR REMINDER TO SELF: START CONCEPTDRAW TO SHOW USE OF TABS; AND TO DO ANY EDITS THAT COME UP IN CLASS
70
Procedure to draw Context Diagrams
This is a general procedure to drawing system context diagrams. The best systems analysts and architects will learn how to adapt this procedure to their needs and culture.
First draw all direct users (as UML actors = stick figures).
Add stereotypes to distinguish between types of users (e.g., internal vs. external vs. other reasonable stereotypes that might be used to categorize your end users)
For each user, draw data flows for all human computer interfaces to and from your system
Remember, only one way arrows are allowed – use the concept of “net data flow”, but draw the flows as requested to communicate with your audience.
If too many data flows leads to clutter, consider consolidating “like” flows into composite data flows.
Add any indirect users, and attach to the appropriate direct user. Attach UML notes/comments to further describe the downstream impact.
71
72
This context diagram shows human-computer interfaces
Procedure to draw Context Diagrams (continued)
At this point, recommend drawing separate context diagrams for existing database interfaces (meaning, “DIRECT interfaces to existing out-of-scope databases”). Why?
The diagram may already be getting cluttered
Database interfaces require different designers and builders anyway
Next, add any external data stores that must be used by your system.
Add stereotypes to indicate if the databases are internal versus external to your business.
Add notes IF any of these databases are subject to structural change because of your system (meaning, new tables or attributes – very common with data warehouses) THEY DO NOT BELONG ON THE SYSTEM CONTEXT DIAGRAM
Next, for each existing database, add data flows for any data interactions with your system.
FYI, database interactions = CRUD = create, read, update, delete
Flows to a database indicate data changes to be recorded in the DB (create, update, delete)
Flows from a database indicate data usage (read)
Two-way arrows are permitted for database interactions (to reduce clutter)
73
74
This context diagram shows database interfaces
Procedure to draw Context Diagrams (continued)
At this point, recommend drawing separate context diagrams for system-to-system interfaces (meaning, “interfaces to other systems”). Why? Same reasons.
Next, add any existing systems that must be used by your system.
Add stereotypes to indicate if the databases are internal versus external to your business.
Use notes to indicate any existing systems to be retired – the data flows for such systems are temporary “crosswalks”
Next, for each existing system, add data flows for any data exchanges with your system.
Add stereotypes or tags as needed to clarify the types or nature of the data exchanges (e.g., {batch}, {import}, {export}, {real-time})
Name all data flows
To reduce clutter, you can consolidate “like” data flows into composite data flows, if that does not confuse your audience
75
76
NOTE: This system-to-systems context diagram was unusually SIMPLE. Sometimes you have so many system interfaces that you need multiple diagrams (e.g., internal vs. external)
This context diagram shows system interfaces
Procedure to draw Context Diagrams (continued)
RECOMMENDED – document characteristics of data flows into tables
IF YOUR SYSTEM HAS A REAL-TIME CHARACTERISTIC, DO THE NEXT STEP – Probably as a separate context diagram
77
Procedure to draw Context Diagrams (continued)
Next, add any sensors to be monitored, or devices to be controlled by your system.
Add stereotypes as needed
Next, add control flows between your system and the sensors and devices
Flows into your system are typically “sensed conditions in the environment” (e.g., temperature, altitude, location, or other sensed state)
Flows from your system are typically “instructions” to the receiving device
FINAL COMMENT:
All system context diagrams should be validated, edited, and regularly reviewed with their intended audiences (owners, users, designers, and builders) at the appropriate times (planning, analysis, design, implementation)
78
79
This context diagram shows real-time device interfaces
Summary – Context Diagram
Uses for context diagrams
During system analysis, context diagrams describe project scope and INTERFACE requirements and constraints
During system design, context diagrams describe INTERFACES implementation (technology constraints and decisions)
What interfaces get described during analysis an design?
User interfaces (a.k.a. “human computer interfaces” (HCI) or “user experience” (XU), typically screens and dialogs
System interfaces, between your system and legacy systems
Database interfaces, between your system and legacy databases that have been deemed ‘out of scope’ for structural changes
Control interfaces, between your system and analog sensors, machines, devices, or appliances
You need to develop one or more separate diagrams for each type of interface
Because different technologists will be charged with designing, constructing, testing, and implementing each type of interface
80
Summary – Final template for Context Diagrams
81
82
YOUR TURN!
From one of your project (preferred) or course (backup) projects, draw a set of UML-style context diagrams.
The set must include AT LEAST two of the four types of interfaces covered in class.
