1. 2-Oct-15 Bojan Orlic, b.orlic@tue.nl TU/e Informatica, System Architecture and Networking 12-Oct-151 Homework assignment 1 feedback Bojan Orlic Architecture of Distributed Systems 2010/2011

2. Evaluation of assignment 1 Goal 1: change point of view when thinking about software architectures –thinking about stakeholders, types of views, building blocks, connectors, semantics, clarity –thinking about how can diagrams capture relevant extra-functional requirements or be used for discussion about them –thinking about presence of complex concepts e.g. distribution on diagram representing some architectural view evaluation of goal 1: goal is achieved successfully by most students Goal 2: practice providing proper motivation for educated guesses regarding software architectures evaluation of goal 2: goal is achieved successfully by some students (difference in marks arises dominantly from motivation provided) 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 2

3. 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 3 Problems in approach Working alone instead of in teams Writing a story instead of answering the questions Systematically omitting to answer some questions Not motivating answers at all Providing incomplete motivation Providing incorrect motivation Choosing wrong option

4. Views 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 4 Same diagram can belong to multiple views. Diagram that is specifying division of system in modules, but no distribution of the modules to nodes, cannot belong to physical view. Diagram that shows distribution of modules to nodes cannot be just process view and is definitely not logical view. Use case diagram does not belong to process view. Defining set of required functionalities is not the same as defining processes “+1 view” (scenario) view is often not mentioned for appropriate diagrams. Often (only) logical view was used instead. Type of diagram used cannot be only motivation for placing a diagram into certain view. Views are more related to consistent viewpoint on a system (e.g. defined by a role) and this can be expressed via different diagrams.

5. Stakeholders 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 5 End-users can’t be stakeholders in a diagram specifying design details (e.g. class diagram or state diagram ). They especially cannot be only mentioned stakeholders for that diagrams. Even though sequence diagram might be understandable to end- user, it has end-user as stakeholder only if it is related to usage of the system (and not to its inner design). A diagram being useful for logical view does not imply end-users as (main) stakeholders. Diagrams relevant for end users (e.g. use case diagrams) are not only relevant for end users. They are used by other roles to communicate system properties to users. Developers are not only stakeholders of a diagram that represent division of large system into modules. For developer its just a context.

6. Extra-functional requirements 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 6 It is possible to use a diagram to talk about extra-functional requirements that are not explicitly stated on a diagram. Still, the discussed quality attributes need to be related to the diagram, that is the diagram needs to carry some information relevant for those qualities. Diagram that shows dependency of executables on libraries and source code files, as well as location of the files, does not speak about portability. Especially not only about it. Phrase “Extra functional requirements” does not have same meaning as extending the system with additional functional requirements, although modifiability is one of many extra-functional requirements. Sometimes answers just do not make much sense as in “Maintainability: A maintainable system usually exhibits availability, which indicates that the system is available to perform its functions on behalf of its users. Since the model is a distributed network, we expect low maintainability. “

7. Concept of distribution 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 7 Concept of distribution is related to notion of components making up the system being located on different nodes. Distribution of functionality to modules, and distribution of files to directories are not really kinds of distribution we had in mind with question. Division of system into modules without assigning them to nodes, does not have explicit concept of physical distribution, but it creates preconditions for it. Correct answer with wrong or odd motivation as in “there is concept of distribution which may be observed from the branched nature of the model.“ is not counted as correct.

8. Building blocks 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 8 Building blocks and connectors should be clearly identified, as well as their roles. It does not suffice to identify type of diagram (e.g. this is UML class diagram) or elements. Often, there is omission to answer whether building blocks and connectors are conceptual or physical. Sometimes it is hard to tell whether wrong answer is lapse or lack of knowledge, as for example when (even though diagram has associated legend with naming for elements) connectors between states in state machine diagram are called transactions, or when states in same diagram are called “processes and tasks”. Similar dilemma is when connectors in the diagram showing compilation dependencies are named “broadcast and compilation dependency”

9. Clarity & semantic 2-Oct-15 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Informatica, System Architecture and Networking 9 Some students completely omit to answer question about clarity of a diagram. Instead they talk about meaning of the diagram, which often turns into repeating the story about building blocks, but avoid to give their opinion on clarity and semantics. Sometimes artificial remarks are made as in “Missing are the extend- and include relations, which we would expect from this kind of diagram.“ for use case diagram, or as in “The semantic is not clear, we can know the relationship but the information about the class members, such as attributes and methods is not given.” for class diagram. Some comments are odd as in “The semantic is somewhat clear in terms of user requirements being specified but it terminates abruptly. “ for the sequence diagram.