Comments for M2

[changjurhee]

Jul 6 at 4:10am

• 1. Kudos for using the github project table. I hope it's been useful and easy to update. During active implementation, using git issues may be overwhelming. Also, it should not be redundant with the project table.
• 2. Experiments seem to have investigated the key technical challenges with breadth and depth.
  • Experiments were nicely recorded in separate md documents.
  • Section "Results and recommendations" of experiment milestone 1 : artifacts ? #5 has several subsections and snapshots;
    • it could have a distinctive recommendation or conclusion.
• 3. For your "second decompositons" view,
  • you could have created two separate views, one for the Client App and the other for the Server program.
  • These two programs are developed and deployed independently, so in a real world scenario there would likely be two teams, so having two separate views makes more sense.
  • Not clear why two modules are in orange (CallManager and TelephonyManager).
    • Add a comment to explain the meaning of colors. Module views use the <<external_lib>> stereotype to identify what modules are "external" (libraries not implemented by the team). That's OK.
    • Another option would be a different color.
  • Suggestion to rename view: "Second decompositions for MediaClient / MediaServer" --> "Module uses view of MediaClient and MediaServer"
  • Suggestion to rename view: "Second decompositions for ClientUI, Server UI, SessionClient, SessionServer, Database" --> "Module uses view of Client Windows APP and Server Windows APP"
• 4. The C&C views are not very expressive in terms of types of components and types of connectors.
  • What protocols are used?
  • What kind of database is being used?
  • Is the server a Python program, a Windows application, something else?
• 5. We can't really understand if Client UI and Session Client are part of the same application, or if they are different processes.
  • The use of a UML component diagram for the runtime view makes it less readable.
  • There are not different types of arrows for different connectors.
  • The multiple ports in components clutters the diagram a little and do not make it more .expressive.
  • The same box for all types of components also limits readability, so much so that the only distinctive type of component is the database, which, by the way,
  • is using a non-UML symbol What's the meaning of the different colors for components in the sequence diagrams?
• 7. "Module View for GStreamer" is not an architecture view.
  • It's a link to an external webpage that describes GStreamer. You can have this link in the element catalog of a proper module view where GStreamer is one of the modules.
  • The same comment applies to "C&C view for GStreamer Pipeline".
• 8. My personal opinion is that UML communication diagrams easily become hard to read. That's why we didn't cover them in lectures.
  • However, any communication diagram can be easily converted into a sequence diagram, where the sequence of messages is easier to follow IMO.
• 9. ADR01 is about using Star topology instead of mesh topology. But the ADR doesn't explain where this topology is applied. There's not high level runtime view where the Star topology is evident.
• 10. I'm glad the deployment view uses informal notation instead of UML. Your deployment view diagram has a green rectangle for Server PC environment and gray rectangle for Client PC Environment. You could have used the same rectangle and say "Windows 10 PC" in the key.
• 11. The ADR05 decision is "Client server session communication should be done in secure way." That's not the design decision! The project description already asks for secure communication. Your decision is to use TLS, right? Neither the deployment diagram nor the C&C views mention the use of TLS.
• 12. Apparently there's no information in the architecture about adding/replacing CODECs or encryption algorithms. In the first runtime view, the element catalog contains: "Database - Storage for Account and Conference call data". But what kind of DB is it? Postgres? MySQL? A flat file? In a module view you could say what type of modules (implementation units) you are going to create. In other words, what programing languages are you using on the client app and the server?