Seminar on Design and Architecture Patterns

Ošlejšek

Lesson details

Generic feedback to proposals of patterns' application:

  • Organization hierarchy/structure: 
    • Use proper terminology. "A tester is a generalization of a co-author" is confusing. Terms like "being boss of somebody" or "falling under some organization unit" better characterize the meaning.
    • There is no clear organizational hierarchy evident from the QualityIS system, except for the enterprise module, where "the roles can change during the lifetime of a specific SW project at all levels of management". Therefore, the necessary context is the project plus timestamp. 
    • We model and clarify the ("static") hierarchy of organization units (classes), not instances. Although "the roles can change during the lifetime", the structure of the hierarchy itself never changes. A tester is always driven by a quality assurance manager, who is driven by a business assurance manager.
    • Possibly, also the author vs. co-author relationships from the "core" application can be considered organizational hierarchy. In this case, we can either encode them as two organization structure types (core system vs. enterprise module) or as a single organizational hierarchy with two different identification schemes for role names (the hierarchies are the same, but only the role names differ, e.g., an author is called quality assurance manager - see the Identification scheme below).
    • Another example: The hierarchical organization of a project code with possible parallel structures (source code structure can differ from Maven project structure, for instance).
  • Accountability:
    • There could be multiple contexts (accountability types), e.g., project authorship (author vs. co-author), or project updater ([co-]author or developer vs. a new version of the SW project).
    • Party: author vs. external system for project upload
  • Identification scheme:
    • In the enterprise module, the quality assurance manager = author and testers = co-author. Therefore, we have two identification schemes: for the core system and the enterprise module. The identified Object is the role. Therefore, we can combine this pattern with the organizational hierarchy to capture aliases of roles. 
    • Another example: internal versioning (2.3.4) vs. public release versioning (Windows 10 SP1)

Required output

Until Fri. 14.10. at 6:00, all teams implement the same following patterns. Adapt your existing PDM, i.e., all the patterns will be included in the single analytical class diagram. Submit your results as a PDF report (one per team).

General instructions for patterns' application:

  • We aim at taking the text description from the brainstorming and transforming the pieces of information into
    • classes,
    • notes linked to classes,
    • associations,
    • other generic notes placed on the diagram's canvas.
  • Use accurate naming of classes. Rename classes of patterns if it makes sense.
  • Add/adapt context, i.e., associated classes (add necessary, remove unnecessary).
  • Add attributes, if necessary. Never use methods at this requirements stage.
  • Put a note with your group letter into the upper left corner of the class diagram.
Measurements + Observations:

  • We want to measure the results of software quality tests.
  • At least three examples of phenomenon types. At least one of them has phenomenons. Put them as notes in the class diagram.
  • Extend or replace the context of the Observation (e.g., the Person class) with meaningful terms from the application domain. Focus on metrics, analyses, and reports. We aim to get a meaningful class diagram for these terms by using the M&O pattern.
  • Issues are "predefined values", e.g., the number of unused variables, the number of empty catch blocks in try-catch, .etc.
Enterprise segment: 

  • We want to analyze (at least):
    • Selling different SW products (e-shops, CMS, ...) in different geographical locations (US, EU, ...)
    • Which types/categories of quality metrics are applied to different SW products and/or in different geographical locations, and also how often?
    • We want to know all these statistics ale for different programming languages.
  • Identify dimension elements and put them as sub-classes of the DimensionElement. 
  • Propose meaningful classifications (trees) of identified dimension elements. Capture them as notes linked to sub-classes.
Planning (Completed and Abandoned Actions):

  • Identify key states of the "plan, realization, and results of quality testing a software product". Classify the states according to proposed, implemented, completed, and abandoned categories. Add additional categories, if necessary (and ignore/remove unrelated ones).
  • Identify and capture pieces of information that are necessary for each category. Capture them in the class diagram (as associations with the "neighboring" analytical classes).
  • List the states with necessary details in notes linked to the categories of actions.




Předchozí
Následující