LOG8430: Architecture logicielle et conception avancée

Transcription

1 LOG8430: Architecture logicielle et conception avancée Modeling, OO Concepts, and Design Patterns Winter 2018 Fabio Petrillo Chargé de Cours This work is licensed under a Creative 1 Commons Attribution-NonCommercialShareAlike 3.0 Unported License

2 Quiz 02 - Architecture is most important when... Student login Room: POLYMTL Name: Put your matricule number 2

3 Architecture is most important when... the failure risks are high (ObamaCare). there is a small solution space or it is hard to design any acceptable solution. stakeholders demand difficult quality attributes when you are working in a new domain (for you) Architecture can help manage complexity The value of creating a flexible architecture is the cost of not addressing the technical aspects that can help a system adapt to changes when they happen. Advice: many systems can succeed even when their developers ignore software architecture, but plenty of failures that could have been avoided by paying attention to software architecture 3

4 Graphical Modeling Languages 4

5 Graphical Modeling Languages to SA A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. Graphical modeling languages use a diagram technique with named symbols that represent concepts and lines that connect the symbols and represent relationships and various other graphical notation to represent constraints. 5

6 Graphical Modeling Languages to SA Unified Modeling Language (UML) Business Process Model and Notation (BPMN) ArchiMate 6

7 7

8 Unified Modeling Language (UML) Visual modeling Language Specify, visualize, construct, document Standardization (OMG) 1995 ~ 20 years Better than nothing! 8

9 Unified Modeling Language Structural Dynamic Static view - Class diagram Use case view Use case diagram Design View Component diagram State machine diagram Activity diagram Sequence/communication diagram Physical Deployment view Deployment diagram 9

10 Use case diagrams Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how. Use case diagrams are closely connected to scenarios. Use case does not represent sequence! 10

11 Use case diagrams 11

12 Class diagram Main OO diagram Static aspects - and relationships Classes and Relationships (including inheritance, aggregation, and association) Methods and attributes 12

13 Class diagram - Domain Model 13

14 Class diagram - Implementation Classes 14

15 Class diagram 15

16 Class diagram 16

17 Class diagram 17

18 Class diagram - Relationships 18

19 Component Diagram architecture-level artifact high-level software components interfaces to those components Components -> Services -> microservices Very useful and powerful 19

20 Component Diagram 20

21 Component Diagram 21

22 Sequence Diagram flow of logic within your system most popular artifact for dynamic modeling temporal sequence useful to represent layers 22

23 Sequence Diagram 23

24 Sequence Diagram 24

25 Sequence Diagram 25

26 Sequence diagram (robustness) 26

27 Sequence Diagram - Issues 27

28 Package Diagram organize model elements into groups organize classes, data entities, or use cases

29 Package Diagram 29

30 Package Diagram - Model or Structure Diagram 30

31 Package Diagram 31

32 Deployment Diagram Deployment diagram is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. physical view run-time configuration nodes and the components that run on those nodes technological decisions hardware, software and networking 32

33 Deployment Diagram - Components by Artifacts 33

34 Deployment Diagram - Specification Level 34

35 Deployment Diagram - Instance Level 35

36 Deployment Diagram 36

37 UML - Some online resources

38 Business Process Model and Notation (BPMN) Business Process comprehension - important step on SA modeling Business Process Model and Notation (BPMN) is a standard for business process modeling Maintained by the Object Management Group since 2005 Graphical notation for specifying business processes A flowcharting technique very similar to activity diagrams from Unified Modeling Language (UML), adding a rich semiotic (symbols) to express business processes 38

39 Basic flow objects and connecting objects Event Activity Connection Gateway 39

40 Business Process Modeling Notation (BPMN) End event Swimlane Start event Annotation Data object 40

41 BPMN - Some online resources

42 ArchiMate modeling language The ArchiMate modelling language is an open and independent Enterprise Architecture standard Supports the description, analysis and visualisation of architecture within and across business domains. Open standards hosted by The Open Group and is fully aligned. Open source modeling tool - Archi Three main layers in a single diagram Business layer Application layer Technology layer Archi can be a good alternative to UML/BPMN 42

43 ArchiMate - Business layer 43

44 ArchiMate - Application Layer 44

45 ArchiMate - Technology layer 45

46 Process and business layer Application Layer Technology Layer 46

47 47

48 ArchiMate - Some online resources

49 Architectural Modeling Use a standard notation or describe our notation in the diagrams Decide your project modeling language notation and follow it! Just enough modeling -> Modeling versus Documenting CASE tools Several tools: ArgoUML, Astah, Visual Paradigm, Archi Tool,. Documenting Suggestion: work with two monitors. :-) 49

50 Conceptual framework for system and software architecture 50

51 (Serebrenik, 2012) 51

52 Architecture Views General guidelines to describe architecture document 4+1 View Model (Krutchen, 1995) SEI Views and Beyond approach Rozanski, Woods [2005] 52

53 4+1 architectural view model [Kruchten 1995] Describing the architecture of software-intensive systems, based on the use of multiple, concurrent views It is not possible to capture the functional features and quality properties of a complex system in a single comprehensible model that is understandable by and of value to all stakeholders. View: A view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more of its stakeholders. Kruchten, Philippe (1995, November). Architectural Blueprints The 4+1 View Model of Software Architecture. 53 IEEE Software 12 (6), pp

54 4+1 architectural view model [Kruchten 1995] Kruchten, Philippe (1995, November). Architectural Blueprints The 4+1 View Model of Software Architecture. 54 IEEE Software 12 (6), pp

55 4+1 Views: Scenarios The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They also serve as a starting point for tests of an architecture prototype. This view is also known as use case view. Use case diagram, activity diagram, or business process modeling (BPM) 55

56 4+1 views: Logical view The logical view is concerned with the functionality that the system provides to end-users. This describes the architecturally significant elements of the architecture and the relationships between them. The logical view essentially captures the structure of the application using class diagrams or equivalents. UML Diagrams used to represent the logical view include Class diagram, Activity diagram, State Diagram. 56

57 4+1 views: Process view The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. This focuses on describing the concurrency and communications elements of an architecture. In IT applications, the main concerns are describing multithreaded or replicated components, and the synchronous or asynchronous communication mechanisms used. UML Diagrams to represent process view include the Activity diagram. 57

58 4+1 views: Development view The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. This captures the internal organization of the software components, typically as they are held in a development environment or configuration management tool. For example, the depiction of a nested package and class hierarchy for a Java application would represent the development view of an architecture. UML Diagrams used to represent the development view include the Component diagram and Package diagram. 58

59 4+1 views: Physical view The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. This depicts how the major processes and components are mapped on to the applications hardware. It might show, for example, how the database and web servers for an application are distributed across a number of server machines. UML Diagrams used to represent physical view include the Deployment diagram. 59

60 60

61 Stakeholder 61

62 SEI Views and Beyond approach Module: This is a structural view of the architecture, comprising the code modules such as classes, packages, and subsystems in the design. It also captures module decomposition, inheritance, associations, and aggregations. Component and connector: This view describes the behavioral aspects of the architecture. Components are typically objects, threads, or processes, and the connectors describe how the components interact. Common connectors are sockets, middleware like CORBA or shared memory. Allocation: This view shows how the processes in the architecture are mapped to hardware, and how they communicate using networks and/or databases. It also captures a view of the source code in the configuration management systems, and who in the development group has responsibility for each modules. 62

63 Viewpoints - Rozanski, Woods [2005] Principle: It is not possible to capture the functional features and quality properties of a complex system in a single comprehensible model that is understandable by and of value to all stakeholders. A view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more of its stakeholders. A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views. 63

64 Viewpoint Catalog Six core viewpoints for information systems architecture: Functional Information Concurrency Development Deployment Operational viewpoints. 64

65 Viewpoint Catalog Six core viewpoints for information systems architecture: Functional Information Concurrency Development Deployment Operational viewpoints. In fact, do we need all that? 65

66 Risks due to multiplicity of views Wrong views Fragmentation Inconsistency Kruchten, Rozanski-Woods provide guidance but specifics of the system should be taken into account Each view has to be created and maintained costs! Views have to be kept consistent, the more views the more potential inconsistencies' costs! 66

67 Homework 1) 2) 3) Combine the three software architecture definitions in our own definition. Using your definition, describe elements from your definition to a system that you know (for example, a library system, a Todo list, time tracker, etc) Using the 4+1 view model, model the system that discuss in question 2. 67