אפיון ועיצוב מערכות מוכוון עצמים - לפי UML -

UML לפי OO - אפיון ועיצוב מערכות 6 שיעור [ 58]

קורס ניתוח מערכות מידע

אפיון ועיצוב מערכות מוכוון אפיון ועיצוב מערכות מוכוון עצמיםעצמים

- -UMLUML- לפי - לפי



הקדמה

ביחס קטנות היו בעבר המערכות שפותחו למערכות מהידע הקיימות כיום.

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

כל מתכנן מע' מידע משתמש בשיטת סימוןייחודית לו שהנה כמעין שפה שונה לגמרי.

2



הסיבות לכישלון של פרויקטים אין שיטה אחת ל←סימון/תיעוד מסמכים, לכן:

כול צוות פיתוח מתעד לעצמו המסמך אינו מתאר ממש את סביבת

הלקוח אין שימוש חוזר בקוד

מוכוון עצמים++SMALLTALK, C בהתחלה השפות:

NOTATION לאחר מכן שיטות הרישום



4

ים ד. ח/ א0 ים ר. ב/ וד1 ת ח/ א3 ה פ/ ש/ ץ אר3 ה/ ל כ/ י ה. י1 י . ו7 ה. י1 ו7יש א. רו י9אמ1 ו7 ם. בו ש/ ש1 י; ו7 ר ע/ נ1 ץ ש. ר3 א3 ב1 ה ע/ ק1 ב. או צ1 מ1 י. ו7 ם ד3 ק3 מ. ם ע/ ס1 נ/ ב1ה נ/ ב; ל1 ם ה7 ה3 י ל/ ה. ת1 ו7 ה; פ/ ר; ש1 ה ל. פ/ ר1 ש1 נ. ו1 ים נ. ב; ה ל1 נ/ ב1 ל1 נ. ה ב/ הו, ה/ ע; ל-ר; א3ל ד/ ג1 ומ. יר ע. נו ל/ ה נ3 ב1 נ. ה ב/ ה/ רו, י9אמ1 ו7 ר. ח9מ3 ל7 ם ה3 ל/ ה י/ ה/ ר מ/ ח; ה7 ו1 ן אב3 ל1ד ה' ר3 י; ו7 ץ. אר3 ה/ ל כ/ י נ; פ1 ל ע7 פוץ נ/ ן פ3 ם נו ש; ל/ ה ש3 ע0 נ7 ו1 ים, מ7 ש/ ר9אשו ב7 ו1ם ן ע7 ר ה', ה; י9אמ3 ם. ו7 אד/ י ה/ נ; נו ב1 ר ב/ ש3 ל א0 ד/ ג1 מ. ת ה7 א3 יר ו1 ע. ת ה/ א9ת א3 ר1 ל.ם ה3 מ; ר צ; יב/ לא ה ת/ ע7 ו1 שות; ע0 ל7 ם ל/ ח. ה7 ה, ז3 ו1 ם ל/ Hכ ל1 ת אח7 ה פ/ ש/ ו1 ד ח/ א3

ה ד/ ר1 נ; ה ב/ ה/ שות. ע0 ל7 מו ז1 י/ ר ש3 א0 ם כ9ל ת/ פ/ ש1 ם ש/ ה ל/ ב1 נ/ ו1הו ע; ת ר; פ7 יש ש1 עו א. מ1 ר לא יש1 ש3 ם א0 ש/ ם מ. ץ ה' א9ת/ פ3 י/ . ו7

ל, ב3 ב/ ה מ/ ש1 א ר/ ק/ ן כ; ל ע7 יר. ע. ה/ נ9ת ב1 ל. לו ד1 ח1 י7 ו7 ץ אר3 ל-ה/ כ/ י נ; פ1 ל י ע7 כ.ץ, אר3 ה/ ל כ/ ת פ7 ש1 ה' ל ל7 ב/ ם ם ש/ יצ/ פ. Lה ם ש/ ה', ומ.

ץ. אר3 ל-ה/ י כ/ נ; ל-פ1 ע7

בראשית )יא, א-ט(



5

חשיבות הבנת הדרישות - סיפורו של פרוייקט

מה הבין מנתח רצון הלקוחהמערכת

עדכון ממשק המשתמש

חלומו של מעצב המערכת



6

(2סיפורו של פרוייקט )

איש מכירות תאר כך

התוכניתןכתב

התעוד ..התמיכההנלווה

לפרוייקט



7

(3סיפורו של פרוייקט )

הלקוח חויב בעבור..

המשתמש היה צריך...



התוצאה במציאות

8



OOמהו ניתוח מוכוון עצמים -

.לא עוד טיפול בתהליכים.לא עוד טיפול באירועים.כעת מטפלים בעצמים - אובייקטים רואה שהוא כפי היא המערכת ← במרכז הלקוח

אותה:גישת האובייקטים עוסקת בעולם האמיתי

לא בהסבות ורעיונות של אנשי מערכת מידע. 9



מהו אובייקט

שקיים וירטואלי[ או ]מוחשי דבר כל בעולם וניתן לייחס לו תכונות:

אדם, ציפור, ספר, קורס, חשבון בנק

10



Unified Modeling Languageהכרות עם

1997גרסה ראשונה בשנת. סימון/תצוגה שיטת יצירת העל: מטרת

מידע מערכת ועיצוב לאפיון אחידה במתודולוגיה מוכוונת עצמים.

11



UMLמטרות

שפה אחת, שיטת סימון אחת.אחידות - חיי המערכת שיטת מחזור - UML בכל תומכת

מחזור חיי מערכת המידע.גדולים בפרויקטים פרויקטים תמיכה יכולת -

בכל סדר גודל, בעבודת צוות ובעבודה מקבילה.בטכנולוגיה תלות מוחלט חוסר תלות חוסר -

בחומרה ובתוכנה.

12



UMLמטרות

שפה מתאימה לכולם - UML לוקחת בחשבון את המערכת. מנתח התוכנה, מעצב תכניתן, הלקוח, לכל אחד מאלו קיימים שרטוטים מקובלים, שיטת

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

יאמר אחד כל אחד. בשרטוט הדרישות תוגדרנה את דברוץ

13



UMLמרכיבי

Use Case Diagram המערכת חלוקת - לפונקציונליות לצורך הגדרת הדרישות.

Class Diagram את המביע - המחלקות מודל - שקיימת כפי המערכת, מבוססת עליה החוקיות

בעולמו של הלקוח.Sequence Diagram הלקוח בעולם התנהגות -

הפונקציונליות לפי בחלוקה הזמן, ברצף .Use Caseשהוגדרה בשלב ה-

14



UMLמרכיבי

Collaboration Model מודל שיתוף -וה- לצרכים Sequence Modelהמחלקות

שונים.State Chart Diagram האובייקט מצבי -

במחזור החיים.

Activity Diagramפעילויות במערכת - .

15



UMLמרכיבי

Deployment Diagram על המערכת פריסת -חלקיה

Component Diagram.רכיבי מערכת המידע - Object Diagram.תיאור האובייקטים במערכת -

16



UML - Unified Modeling Language

DFDפירוק עד לרמה מפורטת ביותר ← אירועים ←

מתחילים באמצעעולים ל"אירוע על"

יורדים/יוצרים פירוט לשגרות UMLעד לרמת הפירוט אותה מבקש הלקוח ←



שלבים בתהליך הפיתוחDFD1חקר מצב קייםUse case הגדרת דרישות )רק כאן המשתמש מעורב

מלא(

זהו כתב הכמויות, ההסכם של התכולה

תרשים

תיאור הפונקציונאליות )תקן לסעיפים(

2

Use Case Documentation 2תיאור מפורט/אפיון של תוצר שלב

UML מיוצגת על ידי OOAD שימוש בתפישת

SQ, #UCתרשימים בסימון #

3

Class Diagram4הגדרת החוקיות בעולם של הלקוחDynamic Diagrams הגדרת ההתנהגות של הפרויקטים בממד

הזמן5

All Others6התכנון הפיסי, ההתקנות



(1)אפיון מערכות מוכוון עצמים OOAD

הוא הדבר האמיתי, אם כי לא תמיד מוחשי← אובייקט CLASS של העצמים תכונות← תבנית לוגית הקובעת

אוסף מוגדר של מאפייניםבעלי הנגזרים ממנה, ←אותה רשימת מאפיינים לכול האובייקטים, נבדלים בערכים שלהם:

הפשטה ← זווית ההסתכלות לפי שימוש או כוונת המתבונן

TYPE תכונות ← לפי סוגי שדות שיטות ← פעולות )פונקציות, פרוצדורות(

accessor, getter קבלת מידע מ←האוביקט mutator שינוי המידע האצור באוביקט

← classהכמסה של ה←המבנה הפנימי אינו קישור/גישה, שיטותכלפי חוץ יש רק הוראות/

מעניין

שיטת גישה פרטית ← רק האוביקט עצמו יודע על קיום תכונה ושיטה - שיטת גישה ציבורית ← כול אוביקט מכול מחלקה המוגדרת בה תכונה +

יודע על קיומהציבורית




בנאי ← כול מחלקה יש לה בנאי הבונה אוביקטים על ידי אתחול הערכים של האוביקט

מפרק ← סגירה של אוביקט, סימונו כמבוטל תכונה

מחלקתית ← זהה בכול האוביקטים: שע"ח, מונה )ת.ז.( סופית ← לאוביקט מסוים, אינה ניתנת לשינוי

קשרים בין מחלקות כסאות בכיתה(,30 )אסוציאטיבי ← כיוון, מידת ריבוי

מנהל ועובד אסוציאטיבי עצמאי ← קישור מחלקה אל עצמה )תאריך ערך(מחלקת קשר ← שומרת את הערכים של הקשר

רכב וגלגלים או הכלה חזקה/תלות פרק ← aggregation הכלה וסעיפים




הורשה ← של תכונות ושיטות ממחלקה אל מחלקה יורשת מיותר מאשר מחלקה הורשה מרובה ←

אחתהסימון הפוך לכיוון ההורשה

מוגן # ← הערך פרטי עבור כלל המחלקות למעט מחלקות יורשותעבור

חלקית או על ידי היורשת: (לא תכונות) רמיסה ← של שיטות מלאה

בשל הרמיסה polymorphismריבוי צורות הפעלת פעולה על אוביקט, מחפשת את הפעולה במעלה עץ ההורשה

רק שיטות אשר היורשת חייבת ממשק ← מחלקה ללא תכונות, לממש

מחלקה מופשטת ← לא ניתן לייצר ממנה אובייקטים רק תכונות ושיטות הניתנות

להורשה


UML”מפת דרכים“ -

22

פריסת התוכנה על גבי החומרה

PackagePackageDiagramDiagram

“חבילות עבודה”

:מקרא

מודלסטטי

מודלדינמי

מודלניהולי

SequenceSequenceDiagramDiagram

פונקציונליות,אינטראקציה

ActivityActivityDiagramDiagram

לוגיקה,זרימה

ComponentComponentDiagramDiagram

ארכיטקטורתהתוכנה

StateStateChartChart

התנהגות

ישויות,קשרים,יחסים

ClassClassDiagramDiagram

Use CaseUse CaseModelModel

שחקנים,תרחישים,

אופניפעולה

דרישות מערכתדרישות מערכת

DeploymentDeploymentDiagramDiagram

ארכיטקטורת מערכתארכיטקטורת מערכת



23

מסגרת הדיון:( מודל מקרי-שימושUse-Case Model)

“שחקנים”(use cases)מקרי-שימוש

תרחישים(use-case diagramתרשים מקרי-שימוש )

( המודל הסטטיStatic Model)מחלקות

קשריםתלויות

(class diagramתרשים מחלקות )( המודל הדינמיDynamic Modelבד"כ יותר מאוחר, בשלב עיצוב התוכן :)

מצביםמעברים

(state-chart diagramsתרשימי מצבים )



24

דוגמה לניתוח מונחה עצמים: מעלית

רשימת הדרישות המערכת מבקרתn מעליות המשרתות m קומות בכל מעלית ישmכפתורים - אחד לכל קומה עם הלחיצה על כפתור-מעלית

הכפתור מואר

המעלית מגיעה לקומה המבוקשת

הדלתות נפתחות והכפתור כבה)בכל קומה, פרט לראשונה ולאחרונה, יש שני כפתורים )לעליה ולירידהעם לחיצה על כפתור-קומה


כאשר מעלית מגיעה לקומה המבוקשת - הדלתות נפתחות והכפתור כבה

לאחר השהיה נסגרות הדלתות והמעלית ממשיכה בכיוון המבוקש )אם ישנן בקשות קיימות(כאשר אין בקשות למעלית, היא חונה בקומה הנוכחית כשדלתותיה סגורות



25

? היכן נמצאות האובייקטיםהיכן נמצאים ?הפונקציות

מבקרת המערכתn המשרתות מעליות m קומות בכל מעלית ישm אחד לכל קומהכפתורים - כפתור-מעלית על הלחיצהעם

מוארהכפתור

לקומה המבוקשתמגיעההמעלית

כבה והכפתור נפתחות הדלתות)בכל קומה, פרט לראשונה ולאחרונה, יש שני כפתורים )לעליה ולירידה כפתור-קומהעם לחיצה על


כאשר מעלית מגיעה לקומה המבוקשת - הדלתות נפתחות והכפתור כבה

והמעלית נסגרות השהיהלאחר הדלתות ישנן ממשיכה )אם המבוקש בכיוון בקשות קיימות(

בקומה הנוכחית כשדלתותיה סגורותחונהכאשר אין בקשות למעלית, היא

אובייקטיםעשויים לציין שמות עצם פונקציותעשויים לציין פעלים

אובייקטיםעשויים לציין שמות עצם פונקציותעשויים לציין פעלים



26

Use-Caseתרשים מקרי שימוש )Diagram)

( שחקניםActors)תפקיד שממלא משתמש כלשהו במערכתמשתמש אחד יכול למלא תפקידים שונים

כותבמאיירעורך

שחקן לא חייב להיות אנושיחיישןבקר

( מקרי שימושUse Cases)אופני ההפעלה של המערכת

אינטראקציה בין המערכת לבין שחקניה( חיצונייםscenariosתרחישים )



27

UCDמעלית -

ride the elevator

Elevator

call the elevatorUser

תרחיש נסיעה במעלית.

מופעל עם הלחיצה על

כפתור במעלית

תרחיש קריאה למעלית.

מופעל עם הלחיצה על כפתור בקומה

System Boundaries



28

Use Casesקשרים בין

ExtendUC אחד מרחיב UCאחר ע"י תוספת של התנהגות

(Extension Point)להגדיר את "נקודת ההסתעפות" ניתןInclude

UC אחד כולל בתוכו את ההתנהגות של UCאחר



29

מורחב UCDמעלית - מעלית

משתמש

ride

מכבי אש

<<include>>

call

repair& test

rescue

טכנאי<< include >>

<<extend>>

<<extend>>

מפעיל קריאה / נסיעה כחלק מתהליך

הבדיקה

מפעילים קריאה / נסיעה באופנים נוספים

תוך שימוש במפתח מיוחד



30

קיימים גם "בעלי עניין"

(stakeholders) אמורים לשרת UCה-

גם את האינטרסים שלהם!

תיעוד - UCמפרט בנוסף לתרשים, חייב כלUC להיות מלווה בתיעוד, הכולל את הנושאים

הבאים:UCמטרת ה-

נועד למילוי משימה שתשרת שחקן אחד לפחות

רשימת השחקנים ותפקידיהם"המערכת" איננה שחקן!

(pre-conditionsתנאים מקדימים ) יוכל להתבצע כהלכהUCמה צריך להתקיים כדי שה-

(post-conditionsתנאים לאחר מעשה )UCמה השתנה לאחר סיום )מוצלח!( של ה-

(MSS = Main Success Scenario)תרחיש הצלחה ראשי –התנאים • לקיום שתביא "המערכת" לבין השחקנים בין העיקרית האינטראקציה

לאחר-מעשה ]ללכת בתל"מ[

(branches)הסתעפויות ]"אלתר נתיב"[(alternative)חלופה

השגת התל"מ באופן שונה (exception)חריגה

מבלי שיתקיימו התל"מUCמסלול שיביא לסיום ה-



31

use-caseמעלית - ((ActorsActorsשחקנים )שחקנים )•

משתמש )נוסע(–

((pre-conditionspre-conditionsתנאים מקדימים )תנאים מקדימים )• והמעלית "בכיוון" המשתמש נמצא בתוך המעלית–

עלייה

((post-conditionspost-conditionsתנאים לאחר-מעשה )תנאים לאחר-מעשה )•המעלית הגיעה לקומה המבוקשת–הנוסע יכול לצאת מהמעלית–



32

use-caseמעלית - )המשך( - תרחיש הצלחה ראשיMSS

הקומה 1. של המעלית כפתור על לוחץ המשתמש המבוקשת

כפתור הקומה נדלק2.

דלתות המעלית נסגרות3.

המעלית עולה לקומה המבוקשת4.

המעלית נעצרת5.

הדלתות נפתחות6.

כפתור הקומה כבה7.

)אם הגיע לקומה המבוקשת - המשתמש יוצא מהמעלית(8.

לאחר השהיה נסגרות הדלתות9.



33

use-caseמעלית - )המשך(הסתעפויות

מתחת נמצאת המבוקשת הקומה חלופה: לקומה הנוכחית

ביותר 4 העליונה לקומה עולה המעלית - א שהתבקשה

ב - המעלית יורדת לקומה המבוקשת4חלופה: "מעלית שבת"

- בטל.1 - חוזר בכל קומה בדרך4-9

חריגה: עצירת חירום )יזומה ע"י המשתמש( - בטלים6-9



34

Classתרשים מחלקות )Diagram)

( מחלקהclass)(identifierמזהה )

(attributesמאפיינים )ממומשים באמצעות מבני נתונים

(operationsפעולות )ממומשות באמצעות שגרות / פונקציות

( זיקהassociationבין מחלקות )סוג הזיקה )ירושה, הכלה, ...(

(roleתפקיד )(multiplicityריבוי )



Class Stereotypes

Entity Boundry Controller Abstract מחלקה ללא אוביקטים

Interface למנוע הורשה מרובה

Actor תת תוית של הישות, הרשאות

Policy חוקי ארגון כמו מחירונים



36

)גרסה מעלית - תרשים מחלקות ראשונה(

Elevator Button Floor Button

communicateswith

2m - 2

n

communicateswith

1

m

ירושהinheritance

זיקהassociation



37

)גרסה מעלית - תרשים מחלקות מתקדמת(

Elevator Button Floor Button

Elevator

controls

2m - 2

1

mn

Elevator Controller

controls1

controls

n

1controlsn

1



38

Associationזיקה -

הכרות” בין עצמים ממחלקות שונות“סוגים מיוחדים של זיקה

(inheritance, generalizationירושה, הכללה )הגדרת מחלקה על בסיס מחלקה אחרת

(aggregationהכלה, הקבצה )עצם ממחלקה כלשהי “מכיל” עצמים ממחלקה אחרת

זוג סדור של שתי מחלקותA "מכיר" עצם ממחלקה Bעצם ממחלקה



39

Associationזיקה -

מאפייני הזיקה(nameשם )

(orderingסדר ), או להיפך?B ל-Aהאם הזיקה היא מ-

(roleתפקיד )מה תפקידו של כל אחד מהעצמים בקשר

(multiplicityריבוי )האם הזיקה קיימת תמיד?

האם ההכרות היא עם יותר מעצם אחד?



40

דוגמאות לזיקה

0..11 refers to

is expressed in a1*.. 0*..has

refers to

policyholder

married to

husbandwife

refers to

has

0*..

1 insurer

role

name multiplicity

זיקה עצמיתself association



41

Associationמחלקת זיקה )class) לפעמים לזיקה עצמה ניתן לתת מעמד של מחלקה לפעמים לזיקה עצמה ניתן לתת מעמד של מחלקה•

Company Person

* 0*..

employeeemployer

boss

worker0..1

*

association class• association part

• visual tie• class part



42

(Inheritanceירושה ) מחלקהB יורשת את מחלקה A:

B מכילה את כל המאפיינים של A

B מכילה את כל הפעולות של A

מכילה מאפיינים ופעולות משל עצמהBבנוסף, “B is-a A”B( היא תת-מחלקה sub-class של )A

מאשר א’יותרמינוח לא מוצלח, כי ב’ מכילה B( היא הכללה generalization של )A:דוגמאות לירושה

דוגמה רעה: ריבוע יורש מלבן

דוגמה טובה: ריבוע ומלבן יורשים מרובע



43

(Aggregationהקבצה ) כל עצם ממחלקהB מכיל עצם )עצמים( ממחלקה A“A is-part-of B”:שני סוגי הקבצה

B יש קיום גם ללא Aל-שמות נוספים:

logical aggregation

shared aggregation

B תלוי בקיומו של Aקיומו של –שמות נוספים:•

–physical aggregation

–non-shared aggregation

–composition



44

דוגמאות להקבצה1{ordered}

3*..

*

1

(compositionהקבצה פיסית ) למעגל יש נקודה אחת )מרכז(• נקודת המרכז משויכת אך ורק עם מעגל •

זה קיומה של נקודת המרכז מותנה בקיומו •

של המעגל

(aggregationהקבצה לוגית ) לפוליגון יש סגנון• סגנון יכול להיות משותף למספר •

פוליגונים הסגנון הוא ישות עצמאית, וקיומו אינו •

מותנה בקיום פוליגון

(navigationכיוון ) המעגל “מכיר” את הסגנון• הפוליגון “מכיר” את הסגנון• הסגנון אינו נדרש להכיר את העצמים •

המפנים אליו...

*

1



45

Dependencyתלות - יחס(relationship)בין שתי ישויות

ישות עצמאית

ישות תלויה

שינוי כלשהו בישות העצמאית עלול להשפיע על הישות התלויה זיקה ביניהן שאין ישויות בין גם להתקיים יכולה (association)תלות

כלשהילדוגמה: עצם ממחלקה כלשהי מועבר כפרמטר לפונקציה של מחלקה אחרת

כיוון התלות לא בהכרח זהה לכיוון הזיקהBuilding

Theater Seat



46

UML Diagram Usage - Summary

Development Phase

UML Diagrams

Analysis Use Cases, Class Diagrams, Activity Diagrams, Collaboration Diagrams, Sequence Diagrams

Design Class Diagrams, Collaboration Diagrams, Sequence Diagrams, State Diagrams, Component Diagrams Deployment Diagrams

Development Collaboration Diagrams, Sequence Diagrams, Class Diagrams, State Diagrams, Component Diagrams, Deployment Diagrams

Implementation Package Diagrams, Deployment Diagrams



← אפיון דרישות2/3שלב עדיף יחד עם העיצוב הלוגי

Use Case Diagramתרשים המבטא את הדרך בה המשתמש מפעיל את

המערכת: לתיאורתקנייםשדות

Name AssumptionsIdentifier Basic course of ActionDescription Alternate course of ActionActors Change History )change control(Frequency )open( IssuesPre Conditions Decisions )for next version(Post ConditionsExtend / Include



← הגדרת החוקיות4שלב Class Diagramהמודל הסטטי

← מתאר את החוקה העסקית בארגוןUse Case תרגום של ה←

שמות העצם ← מחלקות תיאור שמות העצם ← תכונות

פעלים ← שיטות ERD תרגום ה←

הוספה של השיטות הגדרה של ההורשה



(1) ← התנהגות על פני ממד הזמן 5שלב

Sequence Diagramהמודל הדינמי

האוביקטים, לא המחלקות, הם החיים בממד הזמן ← האנכי ← הוא ממד הזמןY ציר

התרשים מבטא את התנהגות האוביקטים בתהליך אילוצים: תנאי או התניית ביצוע בקיום ביטוי מסוים

Use Case הערות: בעיקר ה←

יצירה ופירוק




Collaboration Diagramתרשים שיתוף

Seq. Diagram לבין Class Diagram שיתוף בין ה← קשר בין המחלקות, ללא ממד זמן, בהקשר של

האוביקטים נועד לבדוק נכונות של התרשימים הקודמים




State machineתרשים )מכונת( מצבים המנתח מכין עבור התוכניתנים:

המצבים השונים של אוביקט מסוים במחזור חיי המערכת

לעתים תוך ציון הערכים של התכונות האירועים המשפיעים על מצבו

סדר האירועים התנהגות סדרתית של האוביקט

מצבים מיוחדים: לא ניתן להגיע אליו

מבוי סתום, אי אפשר לצאת ממנו




Activity Diagramתרשים פעילויות

Business בשלב האפיון או העיצוב, להמחשה של ה←Logic

דומה לתזרים זרימה



התרשימיםUse case Diagramחלוקת המערכת לפונקציונאליות לצורך הגדרת הדרישות

Use case Description

החוקים העסקיים, ללא פירוט התכונות ↔ התנהגות בעולם הלקוח ברצף הזמן↔

Use Case לפי הפונקציונאליות של ה←SDו← CDשילוב של ↔מצבי האוביקט במחזור החיים ↔

Class DiagramSequence Diagram

Collaboration DiagramState Chart Diagram

Activity Diagramהפעילויות במערכת בחלוקה לתחומי אחריות ↔

Component Diagramהרכיבים

Deployment Diagramתרשים תלויות ← פריסה לוגית, גיאוגרפית/ע"ג החומרה

Object Diagramתרשים האוביקטים



שימוש בתרשימיםERDUse case Diagram או DFDאת תיאור המצב הקיים תיארנו

Use case Descriptionאפיון

דרישות החוקים העסקיים, ללא פירוט התכונות ↔ הפונקציונאליות, עץ המסכים↔

תיאור התהליכים באמצעות המודל הדינמילהתחיל שלבי פריסה ומימוש

והסוגים של Entityבסיס הנתונים ← הגדרת התכונות

Class DiagramSequence Diagram

אם צריך:Object DiagramCollaboration DiagramState Chart Diagram

ניתוח

+

עיצוב לוגי

התייחסות לטכנולוגיה:← פירוט של כול תרשימי האפיון

← פירוט כול תהליך/אירוע כולל רמת האבטחה

Class Diagram← הוספה של המסכים ל←Controllersשגרות דרך הגדרת השיטות וה← ← או עברית מבנית Activity Diagram באמצעות

←Classהופך לטבלה

Class DiagramSequence DiagramActivity Diagram

עיצוב

בנייה של קבצים, הוספה של תרשים המרכיבים

Component Diagramמימוש

פריסהDeployment Diagramתלויות ← פריסה גיאוגרפית/ע"ג החומרה



MVC - Data Model View Controller

Class Diagram חלוקה של ה← Entityמחלקות מידע ← מאגר נתונים Boundryמחלקות תצוגה: מסכים, דוחות Controller:מחלקות ניהול

השולפות מהתצוגה, מעבדות ושומרות שולפות ממאגר הנתונים, מעבדות ושומרות

כול מסך הוא אוביקט, הקשר הוא על ידי עץ המסכים



CASE - Computer Aided Software Engineering

כלי אשר:UML אליו מגדירים את ה←

Upper Caseניהול האפיון, העיצוב, הבדיקות ← Lower Case :מפתח את

בסיס הנתונים התוכנה



58

שאלות ?

http://www.smartdraw.com/tutorials/software/uml/tutorial_01.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm

UMLתרשימי

Documents

אפיון ועיצוב מערכות מוכוון עצמים - לפי UML -