context diagram
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
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 |
6
REF: Adapted from Rozanski and Woods (2012)
6
ENVIRONMENT
System Concepts for Context Views of a System
7
YOUR SYSTEM
THING
THING
THING
THING
THING
THING
THING
THING
The things I have to design are in the grey box
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 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
The number one communicate is your audience
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
Where are your data centers
SECURITY
20
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 3 Describing System Scope with Context Diagrams
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson B
Introduction to Context Diagrams (CDs)
Lesson C
Notation, Grammar and Styles for System Context Diagrams
Lesson A
Defining Scope Using our Framework
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
Historically, where did context diagrams originate?
False credit goes to the “Object-Oriented Analysis & Design” methodology, and the UML tool
FACT: Context diagrams are NOT a UML tool
FACT: UML did NOT invent context diagrams
FACT: Many UML authors merely chose to use context diagrams to illustrate scope because the UML did not offer a tool to do so
True credit goes to the “Structured Analysis and Design” methodology (≈1978)
Context diagrams were required in this methodology to define the scope of processing
The diagram was considered a contextual data flow diagram (DFD)
Invented by four people: Yourdon, DeMarco, Gane, and Sarson
25
And it looked something like this …
26
Gane and Sarson Notation
This is the most common SCD notation
27
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
28
1
2
3
4
5
Learning Module 3 Describing System Scope with Context Diagrams
Today’s Reference
Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition) Upper Saddle River, NJ: Addison-Wesley.
Lesson B
Introduction to System Context Diagrams (SCD)
Lesson C
A UML Notation, Grammar and Styles for Context Diagrams
Lesson A
Defining Scope Using our Framework
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.
28
