System Context and Domain Analysis

صفحه 1:
Oe maces ۱60 ceineisye! OSA eT ‏عنوراهه)‎ 

صفحه 2:
‎chapter will covered‏ (( ۱ اله ‎0 4 hew te produce severd pverd represrotitivas of the toptevel ‏یس ام تسیا‎ ۳۹9 Oteus ۹ ‏موس‎ ‏لت‎ ‎ee ed NA Sena CURR aaa © cast Overdl Oiew ra es ee ee ON eee ‏ا ل‎ ‏ل ةا‎ ‎ee eat eae ere eee See eee ee eco te‏ 0ك میاه 0 سم 6 ‎ 

صفحه 3:
‎Orr ra Oi asic‏ اله ‎DI, erent cede ene See ee eet eee ‏فیس ‎SO ed teeter‏ ‎RON ee aed‏ ‎an Saree een‏ ‎een ent ene em eet toa‏ 0 ا 0 0 ‎Ove‏ ‎RU‏ ۱ ‎ead ‎۱ Re ee Sena ‎Cee eee eee ere ee ee eee eee or ‏ا‎ ‎6 ‏میاه 0 سم‎ ‎ 

صفحه 4:
‎aaa‏ م 0 اله ‎8 ‏هو یی سس‎ ۱ Tana eee epee rey are ‏ا‎ ae Orne ‏دمتعيس‎ ‎ie rt aed wd eee hee eter Renee ote rede toa] ۲ ‏ما ما‎ ‏سصصا اه بوه ‎nee Pe tered es eaten coe‏ مم10 "ا ۳ ‎oa ‎(eae eee ee Oe eet tee ee ee TOO ‎Ce eee eee ne re eee ee ec ee ec 6 ‏میاه 0 سم‎ ‎ 

صفحه 5:
ا ا ا 49000 اله اللا مك ‎BAT ad RS an ad‏ ۱۳ ‎a) Be ec cas Car om UM ca ans cae Bde ce‏ ‎ote A a eS oe Oa‏ ۱۳۹ سس رش ‎eRe acne oma Caon ad‏ ا )155 ‎OOD view woe't work just os well‏ Cee eee ea eee eee ee ee eee ee ec oe ‏ا‎ ‏تیه‎ 0 

صفحه 6:
© 1 0202© اله يي اا يي ييا 0 تا مر مر یا ی رتست ۹ ص ‎eae ent et eee cece ve eee‏ 1۱ ‎NE Ee ee a ee cod‏ ا ‎se em‏ ای اس همست ما مور Cee eee eae ee eee er ec eee cor a] ‏تیه‎ areas 

صفحه 7:


صفحه 8:
ee Or coast ۲ ‏,بو با‎ A a a ee en ee © aod the spstew's terPaves wih these exterod euties ۳۹ © Create voly vor view (Croix! Ole) Proc this vievwpoict thot captures: ‏مت وت سا مت سل‎ ‏ل‎ en Oe an Re Ce as ne, Bo 0 ua be wed ol severd kuels (Spstew, Oubsystews, ...) ا ‎Cee‏ ‏میاه 0 سم 6 

صفحه 9:
0 eR eee ncn ne ee oa ee NE eee eae ee ‏ل‎ Tae eo on i a a oe ead 2000 ee Te rr cred wed ea eee ‏ا‎ nome beer occ en hee ccna eee ener ۲7 ۱ ‏وه‎ eo en ee oe Nah ee a BRR a oR © ‏و یه‎ wioeized Ce eee eae eee ee eee ee coe ‏ا‎ ‏تیه‎ areas 

صفحه 10:
Or ea KO) | eR ee ee Ra ee ‏مس سس(‎ eo el eee و با ی مصاصه صا اه كمه ‎ee ee ee‏ ا ‎a‏ يلي ا ‎a‏ ا لي ما 00 ا 0 ‎areas‏ ب 

صفحه 11:
Context Viewpoint Purpose Model the set of actors with which the syst * interfaces berween the system and these entities. When Applicable Throughout project lifecycle. Primarily prepared during the first stages of design and analysis, but is updated as information about external interfaces changes. Stakeholders Software Architecture Team, Software Systems Engineering Team, Subsystem Désign Leads, Developers, Testers, Systems Engineers, Marketing, oF others who are interested in or negotiate external interfaces. Scalability ‘The system should always be located in the middle of the view. The external actors should be surrounding the system. If the number of actors becomes too large, they may need to be grouped into higher- level actors. Multiple Context Views should only be used as a last resort. Should be consistent with other static views that show external Views interfaces. For example, the subsystem interface, component, __ process, or deployment views. Cee eee eae eee ee eee eee or a] 6 ‏میاه 0 سم‎ 

صفحه 12:


صفحه 13:
ا ل 00 اله Ree Ren eae ‏ل ا ا‎ ome Nol ANA RN CAS CCL SCR ESCA 0 Dhree viewpotdis used Por dowata odpsis ‏اا‎ Overcl Oiewpvict © @uabsis Pooused Oiewpoiat GN eral er OL Una} Cee eee eee eee ee eee eee oe ‏ا‎ ‏تیه‎ 0 

صفحه 14:
‎yen eer eatd Mec aneie se‏ ال 4 اله ‎Analysis ‎Focused View ‎Analysis ‎Overall ‎View ‎ ‎Ce eee ea eee ere ee ee ee ee ee ee 6 ‏میاه 0 سم‎ ‎ 

صفحه 15:
"٩۳ ‏مس‌سیه‎ 155 day aad aacd tac Be ca oe aca at et Ae EAD RN ces cic aR ‏يي‎ ‎SET ea aaa Reed oe Re cee a ۳ SRR a Ree oe Ree eR cl cad 0 aaa ‏ل ا‎ © Ose codes putteras or predePiaed views Por sicviar ‏4و وت‎ Ce ‏ا‎ ‎preter, areas 

صفحه 16:
a "1 Ox ee (aegis Onan ‘Analysis Interaction Viewpoint lustrate a set of classes, attributes, methods, and associations for a specific path through a use case. Prepared during analysis, along with use case development. Generally not maintained. Software Architecture Team, Software Systems Engineering Team, Subsystem Design Leads, Developers, Testers. ‘The Analysis Interaction Views will be used to produce a focused view for that use case. ۰ Should be consistent with the initial focused views, but will most likely not be maintained as the focused views evolve. Cee eee eee ne rea ee ee eee ee coe ‏ا‎ ‏ل رسیم ما0‎ 

صفحه 17:
1 sl 1 | | ۱ 9 و [Tate Collec Customer Contact Data Type: Analysis Interaction View Date 2002-Now-1 Ri 

صفحه 18:
| atone Analysis Focused Viewpoint Purpose Ilustrate a set of actors, classes, attributes, methods, and associations for a specific use case, set of use cases, or subse Analysis Overall View. When Applicable Primarily prepared during analysis, along with use case Jevelopment. Generally not maintained, unless a product family is being developed. Stakeholders Software Architecture Team, Software Systems Engineering Team, Subsystem Design Leads, Developers Testers. Scalability The focused views will be used to produce an overall view that can be used to drive the software architecture definition Relation to Other Should be consistent with the initial overall views, bur will most Views likely not be maintained as the overall views evolve [0 ‏ا‎ ‏عا‎ a ni tents 

صفحه 19:
۳ <Entity> Customer | 1 Location Into Interface ‏رم‎ address ty ereate_customer()] 1 state 2dd_location( ) 1 creates مها وود 77650166 500165615323 ‘Type: Analysis Focused View Date: 2002-Nov-1 Responsible: Garland ! Anthony [0 ‏ا‎ ees ‎a ni tents‏ عا ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 20:
سر اسر حول | Analysis Overall Viewpoint Purpose Ilustrate the set of key actors, classes, artribures, methods, and associations for a system. This viewpoint should not contain implementation details. When Applicable Primarily prepared during analysis, along with use case development. Generally not maintained, unless a product family is being developed. Stakeholders Software Architecture Team, Sofrware Systems Engincéring Team, Subsystem Design Leads, Developers; Testers. The overall view is seldom small enough to fit onto a single sheet of paper. Subsets of the classes, actors, and associated information’ can be extracted to produce focused views that convey a key concept or set of concepts Relation to Other Should be consistent with the initial Analysis Focused and Analysis Views Interaction Views, but generally evolves to contain additional information. 

صفحه 21:


صفحه 22:
a DE ale oie ACs ae Ol en ae cae as od ۱ GoPivare Prokievture”. Ce eee eae eae ere ee eee ec ee eee ce ‏سوم‎ areas 8 

صفحه 23:
امسر مر اله ee ee eae eae ore er eee eee ee ee eco ‏ا‎ ‏ل رسیم ما0‎ S 

System Context and Domain Analysis Abbas Rasoolzadegan What this chapter will covered  How to produce several overall representations of the top-level architecture include:   Context View Conceptual diagrams  Non-architectural docs:    System engineering docs May be referenced in S.A. description Analysis Overall View  To gain understanding of the key entities in the system  To produce other artifacts and is usually not maintained  Except for use in product families Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 2 Conceptual Diagrams   Illustrates some of the elements of the system and relationships to external entities Very similar to context view    Less formal than Context view Can not write a viewpoint for them due to the:     Capture the system and its interfaces Lack of formality Variability in the stakeholders Lack of specific modeling conventions Usage   To communicate with the stakeholders are not familiar with UML notations and concepts To give newly hired employees an overview of the system scope beyond the software developed Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 3 Conceptual Diagrams Producer  Systems engineering organizations  Illustrate a proposed functional breakdown of the system along with some key hardware they expect to be included in the final system  Marketing organizations  Communicate the functionality of the system to prospective clients of the product  Technical leaders  Prepare a technical white paper intended for readers who may not know UML  ….  Also to prepare a proposal where the evaluators don’t understand UML Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 4 Conceptual Diag.s Guidelines  Some guidelines for creating a conceptual diag.:     Identify who are the stakeholders What information the view is intended to convey Analyze the level of information that must be communicated to the intended consumer …  Before generating a conceptual diagram, be sure that a UML view won’t work just as well Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 5 Conceptual Diag.s (Cont.)  Software architect or members of the architecture team are frequently asked to develop or support development of a conceptual diagram  Exception  To prepare a technical paper for marketing purposes that will need to include conceptual diagrams  The use of conceptual diagrams should be limited to communications with individuals external to the software development team Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 6 Example of Conceptual Diagram Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 7 Context Viewpoint  Contains only    the system, the external entities with which it interfaces, and the system’s interfaces with these external entities  Goal  Create only one view (Context View) from this viewpoint that captures all external entities and their interfaces  Is the first view of the system the architecture team often will create  Can be used at several levels (System, Subsystems, …) Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 8 Context Viewpoint (Cont.)  Can be based on information provided by  The systems engineering  Marketing or other sources that describe the system at a high level  The external entities along with the roles they perform are referred to as actors  Includes the interfaces between the system and external systems  The operator and system names defined by the software architecture team will be used for all lower level design  It is critical the names are carefully selected and change is minimized Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 9 Context Viewpoint (Cont.)  Context View in UML  Use a modified use case diagram to represent a context view  The system under design is placed as a box surrounding a set of use cases for the system  The actors are then connected to the use cases and not the system  In the software architecture documents, this view should be supplemented with a table to provide a brief description of each actor (roles, responsibilities, …) and interface (performance, data throughput, protocol utilized, …) Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 10 Context Viewpoint (Cont.) Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 11 Banking System Context View Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 12 Domain Analysis Techniques  Domain analysis is the process of identifying entities and abstractions related to problem domain  Three viewpoints used for domain analysis    Analysis Overall Viewpoint Analysis Focused Viewpoint Analysis Interaction Viewpoint Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 13 A Formal Analysis Technique Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 14 Analysis Shortcuts  Most projects come with real deadlines and constraints and projects that analyze endlessly are eventually canceled  It is important to get users looking at finished products as early as possible  Using a part of the system will make users recognize missing functions  Approaches  Prioritization of use cases  Use analysis patterns or predefined views for similar projects has been done previously Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 15 Analysis Interaction Viewpoint Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 16 Collect Customer Contact Data Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 17 Analysis Focused Viewpoint Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 18 Example Analysis Focused View Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 19 Analysis Overall View Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 2 0 Example Analysis Overall View Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 21 Reference  Jeff Garland, Richard Anthony, Chapter 6 of Book entitled “Large-Scale Software Architecture”. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 2 2 Conclusion Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Large Scale Software Architecture Course, Dr. Abdollahzadeh 2 3