Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Unified Modeling Language Introduction to the Unified Modeling Language CS/SWE 421 Introduction to Software Engineering (Slides adapted from Dan Fleck and Dr. Stephen Clyde with permission)

Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Last week n Introduction to software engineering –How is it different from traditional engineering? n Introduction to the project lifecycle –What are the five phases?

Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body This week n The design and modeling phase –UML diagrams –Why did I skip requirements (for now)? Give you a chance to think about your projects before talking about requirements UML diagramming is closely related (the precursor) to coding, which you have done a lot of already

Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Project planning n What sort of planning activities do you/have you engaged in your classes so far? n Do you read the specs and simply jump into coding? n Do you think your projects would have benefited from planning? n Assuming you were able to capture requirements perfectly, what is (or should be) the most difficult part of the development lifecycle?

Coming up: History Unified Modeling Language n UML is an object-oriented modeling language –semi-formal –process independent UML can be used with a variety software development process models –Customizable and extensible –Model structure (static) and behavioral (dynamic) aspects of a system n UML is a communication tool – for the team, and other stakeholders –A standard way to create a visual model

Coming up: Modeling Elements and Diagrams History n In the 90s many people creating OO diagramming languages n Three different ones created by Grady Booch, Ivar Jacobson, James Rumbaugh n Joined forces with Rational (company) to create Unified Modeling Langauge (UML) Booch, Jacobson, Rumbaugh

Coming up: UML Diagrams Modeling Elements and Diagrams n Diagrams represent chunks of information that need to be communicated as part of a conceptual description. –It usually requires many diagrams to describe a system –Each diagram should focus on a single thought or a small set of tightly related thoughts n Diagrams are like paragraphs in a section of well-structured text

Coming up: UML Diagrams – we’ll use in class UML Diagrams n Use Case Diagrams n Class Diagrams n Object Diagrams n Interaction Diagrams –Sequence Diagrams –Communication Diagrams n State Charts (enhanced State Machines) n Component Diagrams n Deployment Diagrams

Two types of diagrams n Structural –Class –Component –Object –… n Behavioral –Activity –Use case –Interaction –State machine

Coming up: Three Software-Engineering Modeling Perspectives UML Diagrams – we’ll use in class n Use Case Diagrams n Class Diagrams n Object Diagrams n Interaction Diagrams –Sequence Diagrams –Communication Diagrams n State Charts (enhanced State Machines) n Component Diagrams n Deployment Diagrams

Structural: Class diagrams n Describes a system by showing the structure of its classes –Includes attributes –Documents relationship among classes

Structural: component diagram n Shows how the software is split into components –Wired together by connections

Structural: deployment diagram n Describes hardware used in the system

Structural: object diagram n Shows a view of the system at a specific point in time n Shows objects (instances) of classes n Used in conjunction with class diagrams

Behavioral: Activity diagram n Describes workflows in a system

Behavioral: state machine n Similar to a finite state machine

Behavioral: use case diagram n Actors, goals, and dependencies

Behavioral: sequence diagrams n Messages between processes/objects n Includes lifespans

UML diagram summary

Coming up: Perspectives Three Software-Engineering Modeling Perspectives n Analysis – for understanding –The objects represented in the models are real-world objects –Models focus on problem-domains concepts –They describe the real-world problem n Specification – for scoping and planning –The models include both real-world and software objects –The models describe logically what the system is to become n Implementation – for designing / building –The objects in the models are mostly software objects –The models focus on solution-oriented concepts –The models describe what the software system is or will be

Perspectives Student name major GPA standing interests -- The set of students known to the registration system Student name: String major: String GPA: real standing: Scode add(Course) drop(Course) -- Software representation of students; support registration in courses Student -name: String -major: String -GPA: Real -standing: String +add(Course) +drop(Course) -- Handle a registration in courses CourseList -- Display a dynamic list courses SpecificationImplementationAnalysis Increasing Detail Real World DomainSoftware Implementation

In the analysis perspective will I need a loop counter? n A. Yes if you have a loop n B. No n C. It depends (be able to say on what if you choose this )

Coming up: More UML Modeling Questions Some Interesting UML Modeling Questions n How do we discover objects or classes? n When should we focus on problem-domain objects, solution-domain objects, or environment objects? n Should each perspective be captured by a different model or can they all be managed in one model? n How much detail should you put in a diagram, a view, or a model?

Coming up: More UML Modeling Questions More UML Modeling Questions n How should you distribute responsibilities among classes? –What happens when classes get too big, i.e. inadequate distribution? –What happens when classes are too small, i.e. too fine of grain distribution? –What happens when there are a lot of dependency relationships between classes, i.e., inappropriate or ad hoc distribution?