פיתוח מערכות מידע Class diagrams Aggregation, Composition and Generalization

Stereotypes מנגנון שמופעל על מחלקות, קשרים וסוגי תלות בין מחלקות כדי לציין את הקטגוריה המתאימה. > > >

Class types Iconic /non-iconic representation of 3 class stereotypes: control, boundary and entity. Example: agreementUI – interacts directly with actors agreementControl- interacts with elements inside system agreementEntity- passive class manipulated by system elements. Entity = business class

Association אסוציאציה, מציין קשרים בין מופעים של מחלקות, בכל קצה של קשר ניתן לציין מספר מופעים מאותה מחלקה שיכולים להיות למופע אחד מהמחלקה השנייה לכל מופע של A מקושרים אחד או יותר מופעים של B אבל לכל מופע של B מקושר מופע של A אחד ויחיד לכל קצה של קשר ניתן לתת שם, וגם לקשר עצמו ניתן לתת שם

Multiplicity and Cardinality of associations ניתן לציין רק את מידת הריבוי של הקשר עדיף לציין גם את קרדינליות הקשר ניתן לא לרשום מידת הריבוי והקרדינליות כאשר סוג הקשר מובן מאליו או המידע אינו חשוב בשלב מסוים של בנית המודל

Composition המחלקה מצד שמאל היא חלק (part of) מהמחלקה בצד ימין,כלומר למחלקה מצד ימין יש "בעלות" על המחלקה מצד שמאל Composition הוא סוג של Association גם כאן ניתן לציין בקצות הקשר את מספר המופעים האפשריים

דוגמה ל- COMPOSITION מסמך שמורכב מהקדמה, פרקים,סיכום ואינדקס יופיע כשלם שמורכב מחלקים שאין להם זכות קיום אם הם לא חלק מאותו מסמך. אם מסמך מבוטל, אז כל המרכיבים שלו יבוטלו.

Aggregation קשר פחות חזק מ-Composition סוג קשר שנועד רק לייצג את היחס "חלק מ “- Assembly-Component: Component is part of an assembly and Assembly consists of components

Generalization המחלקה מצד שמאל מכלילה את המחלקה מצד ימין, כלומר המחלקה מצד ימין יורשת מהמחלקה מצד שמאל

Generalization One class is a kind of another class Generalization - Specialization Superclass - Subclass Supertype - Subtype Generalization allows inheritance of attributes and operations of a superclass by its subclasses

סוגי הגדרת Generalization Bottom-up generalization במהלך הגדרת מחלקות מתברר שלמספר מחלקות יש תכונות והתנהגות משותפות ולכן מגדירים superclass והמחלקות בעלות תכונות משותפות הופכות ל- subclasses Top-down generalization במהלך פיתוח המודל, מתברר שיש יותר ממחלקה אחת מאותו סוג ולכן יש להגדיר מספר subclasses והמחלקה המקורית הופכת ל- superclass

Abstract superclasses למחלקה מופשטת אין מופעים ישרים.

דוגמה ב-Generalization לקוח, בעל חשבון, מבצע טרנזקציה מסוג הפקדה או משיכה.

Visibility of attributes and operations Visibility = availability to other classes Private – :available only within the class Public + :available to any class associated with the class that owns the feature Protected #: available only within that class and any subtype of that class Attributes are normally private Operations are mostly public Private operations = internal responsibilities

Constraints for generalization {complete} –all subclasses defined within class model {incomplete} – not all subclasses specified {disjoint} – one instance of a subclass cannot be an instance of another subclass. {overlapping}- opposite of disjoint generalization. An instance may be an instance of more than one subclass

סוגי קשרים מורכבים-Association class קשר האסוציאציה שמקשר בין מופעים של עצמים לקשר זה יכולות להיות תכונות מסוימות ואז מדובר Association class

Dependency Dependency: one element requires the presence of another element in order to function. If the element upon which the dependency is specified is changed, then the dependent element may also need to be changed תלות בין שני אלמנטים/שתי מחלקות, בצורה ששינוי של אלמנט אחד עלול לגרור שינוי באלמנט השני.

עוד על קשרים... Visibility (prefix to role name on association end) private/public visibility of an attribute of a class as viewed from different classes associated with that class Changeability constraints (omission= no changeability constraint) {frozen}, {addOnly} Ordering constraints {ordered}, {unordered}, {sorted} Navigability ( omission = bi-directional navigability) – shows that it’s not necessary to implement navigability from x to y